OneWire.py problem

[kjm]

@crumble It's a real shame. The idea of a python capable micro with integrated 4G looked so good in the advert.

[crumble]

@kjm

Pycom ran into this damn ESP 32 trap.

Don't expect that Itell you, that the actual firmware solved my problems. I did that too many times and a few hours later everything crashed. But it seems that I2C is now as reliable as the old one core version of the firmware.

[andreas]

Dear @kjm, @crumble and @robert-hh,

@andreas said in OneWire.py problem:

I was too quick on that detail. After getting into the MicroPython code, I see that porting/enabling the modonewire.c from Genuine MicroPython on Pycom MicroPython will require more efforts than I will be able to dedicate to this topic for now.

Finally, we have been able to add support for the native 1-Wire/DS18X20 driver on Pycom MicroPython and published respective firmware images called 1.20.1.r1-0.7.0-vanilla-dragonfly-onewire. See also Inofficial firmware bakery for Pycom/ESP32 devices.

Please be aware that you will have to use a set of different Python drivers to access the lowlevel API available through https://github.com/micropython/micropython/tree/master/drivers/onewire.

• FiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire.tar.gz
• GPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire.tar.gz
• LoPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire.tar.gz
• LoPy4-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire.tar.gz
• SiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire.tar.gz
• WiPy-1.20.1.r1-0.7.0-vanilla-dragonfly-onewire.tar.gz

If you are willing to test this, we will be happy to hear about the outcome for you.

With kind regards,
Andreas.

[John Baird]

Jumping in a bit late, but FWIIW - I've been running DS18B20 sensors in many devices that regularly go to deepsleep for months now. They work very well, with few (if any) missed reads. I think the difference here is that our application is very power sensitive, so the DS180B20 is powered from a supply that turns off every time the module goes into deepsleep. Perhaps you could try parasitic power? That would also turn off the sensor during deepsleep.

[robert-hh]

@John-Baird Parasitic power is not easy, because it has to be supported by the driver. For using it, the data line has to switched to a string pull-up aka Vcc when the temp conversion takes place. This strong pullup has to be set within 10µs after sending the start conversion command. That is not possible at app level, but must be done at the bit level driver. I know it because I just have implemented it yesterday.
And it does not solve the problem that sometimes the sensors do not respond. A full powercycle helps, including pulling the data line to 0. If the data line stays high, then the devices stay powered, and that could be the problem here.
b.t.w.: The driver is here: https://github.com/robert-hh/Onewire_DS18X20. It follows the API of the micropython.org version.

[andreas]

@robert-hh said in OneWire.py problem:

The [refurbished] driver is here: https://github.com/robert-hh/Onewire_DS18X20. It follows the API of the native MicroPython driver.

Taking this chance, we want to thank @robert-hh so much for taking care of all the details regarding this driver. It was a real pleasure to work together with you getting this a real home and - to top it all off - big thanks that you also made its API match the one of the native driver, so people can swap them in and out. We have been doing this through [1] already and are very happy about it.

[1] https://github.com/hiveeyes/hiveeyes-micropython-firmware/commit/2a23af47