[solved] Onewire DS18X20 reading not stable with LoPy4 (no problem with LoPy)

[livius]

@robert-hh
This result is on clear boards or on some extension board? And same sensor module?
Because it looks strange.

[robert-hh]

@livius This is on a plain board, nothing else started after boot expect for connecting the WiFi to an AP.
The FiPy was sitting on an expansion board, the LoPy on a breadboard, Firmware 1.14.0.b1. No sensor module attached, just the output on P11.
Besides that, from similar test, like IRQ latency, the results are NOT surprising. Making timing precise on chips with serial flash (and serial RAM) requires a lot of consideration.

[affoltep]

@robert-hh, @livius I included a gc.collect() in the reset, read_bit and write_bit functions of the onewire lib.
Of course it takes now ages to get a temperature value (~15s) but it seems a little bit more reliable. There are still missreadings, but it seems indeed a little bit better. Will do some tests over night to proof...

Any other ideas to get a workaround? Would it be possible to solve this issue by firmware?

[robert-hh]

@affoltep It should be sufficient to put it at the start of read_bytes() and write_bytes().

[robert-hh]

@affoltep Looking at the example code for readbit(), both sleep_us(1) are obsolete, since the shortest effective distance I have seen between a pin(x) and pin(y) is 3 µs, and the call of sleep_us() alone takes at least 3-4 µs.

    def read_bit(self):
        sleep_us = time.sleep_us
        enable_irq = machine.enable_irq
        pin = self.pin

        pin(1) # half of the devices don't match CRC without this line
        i = machine.disable_irq()
        pin(0)
        sleep_us(1) # should be deleted
        pin(1)
        sleep_us(1) # should be deleted
        value = pin()
        enable_irq(i)
        sleep_us(40)
        return value

write_bit() is less critical, although the sleep_us(1) may also not be needed.

[robert-hh]

@affoltep I made another test, rebuilding just the initial part of write_bit(1) (which is similar to read_bit()). It shows the Initial low period with and w/o the sleep_us(1) lines.
Timing with sleep_us(1)

Timing without sleep_us(1)

With the sleep_us(1) call, this initial period can extend to about 30 µs, effectively writing a 0 or missing the read window at 15µs. Without that sleep, the initial pulse time is still sometimes extend, but much more seldom and shorter than 10µs, being still in the safe range.

[affoltep]

@robert-hh Wow, this could mess up the whole communication at the beginning. I have done now all modifications, including the gc.collect() command in the beginning of read_bytes and write_bytes.
I will let the device run during night to check, whether the communication is more stable. Will let you know more tomorrow.

BTW. Your support is incredible! Many thanks

[affoltep]

@robert-hh @livius It works! Removing the sleep_us(1) in the code did the trick. Measurements are now stable like with LoPy.
I will place a pull request for the onewire lib.

Thanks again for all the help, you made my day

[livius]

@affoltep
not be too fast.
This is braking change for e.g. Wipy2.
The second wait is critical here and must stay.

Then i suppose parameter like addWait is required here
default=True and for LoPy4 set to False.

[affoltep]

@livius Hm, but LoPy, which is from architecture view similar to Wipy2 can as well not generate a 1us break. Is it really needed?
I tested the new lib as well on Lopy and it did work without the seleep_us(1)

[robert-hh]

@livius I agree about the second sleep, but even on WiPy2 it should work without the first sleep. Did you try that it fails? The D18B20 requires a minimum low time of 1µs. On my LoPy, the pin(0)/pin(1) sequence creates a low pulse of ~2 µs. Changing that to:

        addWait = False
        pin(0)
        if addWait:
            sleep_us(1)
        pin(1)

changes the pulse to ~3µs on the LoPy, sometimes extended to 4 µs.
On the FiPy with that change the basic pulse width is too 3 µs, but pulses are more frequently extended and up to more than 15 µs, breaking the communication with the DS18B20.
And @affoltep could try the variant w/o sleep with his LoPy too. I have no DS18B20 here, otherwise I would have tried that already.

[robert-hh]

@livius @affoltep Just tried the same code on the LOLIN32 pro, which should be similar to a WiPy3. That devices behaves the same way as the FiPy (not surprising).
Next attempt on a Wemos LOLIN32 lite, which is closest to the WiPy2 I can get, which shows the same figures as the LoPy.
All tested with the "if addWait" addition.
(sorry @daniel and @jmarcelino, that I do not have the full set of Pycom modules here)

[affoltep]

@robert-hh @livius Ok, just do a short summary:

• I removed the 4 sleep_us(1) from the actual onewire.py lib (2 from read_bit() and 2 from write_bit()
• Tested both LoPy4 and LoPy with the new onewire.py lib
• LoPy runs similar stable as with the "old" onewire.py lib (including sleep_us(1))
• LoPy4 runs much more stable with the new onewire.py lib, no missreadings anymore

From my point of view no sleep_us(1) is needed for Lopy.

I just have done tests with a DS18X20 (no other onewire devices)

[robert-hh]

@affoltep Looking at the data sheet, that seems OK. Faster is better. For reading, it says:
"Output data from
the DS18B20 is valid for 15μs after the falling edge that
initiated the read time slot. Therefore, the master must
release the bus and then sample the bus state within
15μs from the start of the slot."

[livius]

@robert-hh
WIthout second sleep it fail for me on my Wipy2 and Lolion32.
Without first sleep it work ok

[robert-hh]

@livius Then it's better to keep the second sleep_us(1)'s in both the read_bit() and write_bit(). In the latter, it does not hurt anyhow. It just ensure a minimum time between two write_bit() events.
For read_bit() it also depends on the rise time of the output. You could try if the figure changes if you add a smaller pull-up resistor, like 4k7 Ohm.

[livius]

@robert-hh
Yes, it looks like better choise.

You could try if the figure changes if you add a smaller pull-up resistor, like 4k7 Ohm.

I use already 4k7.