MIPI display glitching with GPIO one_wire

ESPHome
1

I have a Waveshare ESP32-P4 4″ Wi-Fi 6 touch panel. I’ve tried to use one_wire via GPIO and have noticed that about 50% of the time when it’s reading a sensor, the screen flashes.

I understand that the GPIO one_wire implementation is bit banging and I assume that this is messing up the screen updates.

one_wire:
  - platform: gpio
    pin: GPIO46

sensor:
  - platform: dallas_temp
    id: outside_temperature
    icon: "mdi:home-thermometer-outline"
    name: Outside temperature
    update_interval: 10s
    address: 0x0300000123451234
    filters:
     - filter_out: nan

Perhaps unrelated, but the 1-wire readings are also very unreliable, hence the filter out “nan”.

2

Probably yes.
Anyway, try some other gpios to see if it makes any difference.

Make sure you have solid wiring. Add 4k7 pullup resistor .

3

Thanks for the reply. I’ve tried a different GPIO but the screen issue remains.

I have however fixed the reliability issue: ESPHome’s GPIO one_wire implementation is quite badly broken.

The code is driving the bus high, which is the one thing you should never do. Aside from risking hardware damage, it means that the voltages are out-of-spec.

The ESP32 datasheets say that GPIO output voltage is VDD * 0.8, which on a 3.3V supply is 2.64V. The DS18B20 datasheet says that the minimum pull-up supply voltage is 3V. If the controller is driving the bus high, it’ll be 2.64V, rather than being pulled-up to 3.3V.

In my case I was seeing a supply voltage of 3.4V and a bus voltage of 3.0V which is obvious enough to make it marginal.

It looks like the problem was introduced by this commit back in May 2025.

I’ll raise an issue and PR.

4

Please explain. Why would the gpio voltage be so low if you draw current within specs?

Are you using the sensor on parasitic power mode?

5

Which part of the datasheet are you looking at?

Are you using parasitic power (I don’t recommend this) or are you actually powering the sensor (at 5V or 3V3)?

You should use an external resistor for pull-up to the 3V3 line.

The data sheet I read says the minimum value for an input high is 2V2 for externally powered devices.

The datasheet does suggest that the bus master release the bus (to let the pull-up do its thing)

To generate a Write 1 time slot, after pulling the 1-Wire bus low, the bus master must release the 1-Wire
bus within 15µs. When the bus is released, the 5kΩ pullup resistor will pull the bus high. To generate a
Write 0 time slot, after pulling the 1-Wire bus low, the bus master must continue to hold the bus low for
the duration of the time slot (at least 60µs)

But that does not appear to be an actual requirement.

6

I’m not sure, but I’m seeing 0.88 VDD which is comfortably above the datasheet minimum of 0.8 VDD with a high impedance load, so it’s well within spec.

Page 2 of https://www.analog.com/media/en/technical-documentation/data-sheets/ds18b20.pdf

“Pullup supply voltage” which is listed as a minimum of 3V, even if locally powered.

Yes. It’s not clear to me how those two interact. VPU is the voltage supplied to the 4K7 pull-up, but in this case, the pull-up isn’t actually doing anything most of the time because the data line is being driven at a lower voltage, not pulled up.

Powered at 3V3.

I am, but it’s not pulling it up to 3V3 when it’s being driven high at a lower voltage.

“must release” seems clear to me. It’s an open-drain system. If a component drives the bus low while the master is driving it high, it’s effectively shorting the GPIO output. Obviously protocol timing means that this shouldn’t happen in normal use.

7

Then you have something wrong.
If your sensor is powered from 3.3V rail and pulled up with 4k7, you should never see a voltage 0.88x3.3V on your gpio pin. It should be 3.3V or <0.5V.
Maybe you try to measure with multimeter which averages high and low stages…

8

That is the voltage on the high side of the pull-up resistor.

This is what is required on the other side of the resistor.

Input Logic-High VIH
Local power: (min) +2.2, (max) VDD + 0.3V
(Notes 1,6)

What matters is that the voltage that the DS18B20 sees (when it checks) is greater than the minimum (which you have confirmed that it is).

The pull-up is there so the DS18B20 can talk back to the bus master. When the bus master is talking it can use a strong pull-up (this is actually required for parasite power, but sometimes they will mostly work without it).

Must is a funny word. Who/what is enforcing that and what are the consequences of not doing that?

Look here: OneWire/OneWire.cpp at 800f26f3ee6eb446a72e013785cac3700e54cc13 · PaulStoffregen/OneWire · GitHub

This is a well respected library for OneWire (the underlying protocol). Look at lines 213-235 of write_bit(). It definitely drives the bus high, when it is writing bits. It doesn’t do this for the reset, but that is because after a reset it is often going to listen and it doesn’t need to actually drive the bus high (since the pull-up will do it automatically).

If you haven’t read about fake DS18B20 chips, you probably should do some research on that. Most of what you see today are fake. I have some real ones from a decade and a half ago that have been incredibly reliable. I have had mixed results with the fakes I have bought in the last decade. Most have worked reasonably well, but some have not.

There are application notes on bus length and topology that are important to understand unless you have very short (1 meter or so) cable lengths.

If you are having problems getting the DS18B20 to be reliable, I would suggest trying a test setup where you have only that (to minimize the number of differences you have from what others have done). It is possible there is an issue with the screen updates messing up the timing.

1 Like