Support modonewire from vanilla MicroPython

[amotl]

Dear Pycom team,

first things first: Thank you so much for your hard work on bringing this hardware and software ecosystem to the world and congratulations to four years of Pycom by the way.

Coming from [1] and [2], we are interested to get more stable readings from some DS18B20 sensors we have attached to one of our FiPy devices by bringing in the 1-Wire driver from the upstream vanilla MicroPython [3].

In order to get started with that, we added this PR which enables the respective extmod at compile time and would be happy to get further support on that.

With kind regards,
Andreas.

[1] https://community.hiveeyes.org/t/untersuchung-und-verbesserung-des-timings-bei-der-ansteuerung-der-ds18b20-sensoren-unter-micropython/2309
[2] https://forum.pycom.io/topic/5330/onewire-py-problem
[3] https://docs.micropython.org/en/latest/esp32/quickref.html#onewire-driver

[amotl]

Hi again,

however, when trying it out, it panics right away when invoking the "reset" operation on the 1-Wire bus, like

import machine
import _onewire

pin = machine.Pin('P11')
_onewire.reset(pin)

Maybe someone interested within Pycom or from the community can figure out what might go wrong here. We have attached the decoded coredump below.

Thanks already for looking into this!

With kind regards,
Andreas.

---

#0  0x402107f3 in mp_virtual_pin_write (pin=0x3ffbfec0 <pin_GPIO22>, value=0) at ../extmod/virtpin.c:38
#1  0x4010ff41 in onewire_bus_reset (pin=0x3ffbfec0 <pin_GPIO22>) at ../extmod/modonewire.c:47
#2  onewire_reset (pin_in=0x3ffbfec0 <pin_GPIO22>) at ../extmod/modonewire.c:88
#3  0x401015ec in fun_builtin_1_call (self_in=0x3f413864 <onewire_reset_obj>, n_args=1, n_kw=0, args=0x3ffd9420) at ../py/objfun.c:70
#4  0x400fda34 in mp_call_function_n_kw (fun_in=0x3f413864 <onewire_reset_obj>, n_args=1, n_kw=0, args=0x3ffd9420) at ../py/runtime.c:624
#5  0x400fdaa0 in mp_call_method_n_kw (n_args=1, n_kw=0, args=0x3ffd9418) at ../py/runtime.c:640
#6  0x40109a46 in mp_execute_bytecode (code_state=0x3ffd9400, inject_exc=0x0) at ../py/vm.c:1002
#7  0x401016ff in fun_bc_call (self_in=<optimized out>, n_args=<optimized out>, n_kw=0, args=0x0) at ../py/objfun.c:287
#8  0x400fda34 in mp_call_function_n_kw (fun_in=0x3f94f920, n_args=0, n_kw=0, args=0x0) at ../py/runtime.c:624
#9  0x400fda61 in mp_call_function_0 (fun=0x3f94f920) at ../py/runtime.c:598
#10 0x400e1ad4 in parse_compile_execute (source=0x3ffd9550, input_kind=MP_PARSE_SINGLE_INPUT, exec_flags=22) at ../lib/utils/pyexec.c:102
#11 0x400e1d4b in pyexec_friendly_repl () at ../lib/utils/pyexec.c:536
#12 0x400e07e4 in TASK_Micropython (pvParameters=<optimized out>) at mptask.c:332```

[amotl]

After redefining mp_hal_pin_write and mp_hal_pin_read to use the Pycom-specific pin_set_value and pin_get_value functions, we have been able to get one step further.

While we haven't been able to test it on real hardware yet, invoking the _onewire.reset and _onewire.{read,write}{bit,byte} primitives no longer trigger any core panics.

[amotl]

We are now able to confirm this also works on real hardware [1] using the drivers from Genuine MicroPython [2].

[1] https://community.hiveeyes.org/t/testing-the-custom-dragonfly-builds-on-pycom-devices/2746/6
[2] https://github.com/micropython/micropython/tree/master/drivers/onewire

[amotl]

In case anyone is aiming at using the C-level 1-wire module without having to rebuild the firmware, we are following the Pycom releases to build custom firmware images on top, see Squirrel firmware for Pycom/ESP32. Please read the installation instructions carefully.

[amotl]

Dear @peter-pycom, @salal-m and @Xykon,

do you see any chance to get this into v1.20.2.rc10?

With kind regards,
Andreas.

cc @robert-hh

[amotl]

Dear @peter-pycom, @salal-m and @Xykon,

do you see any chance to get this into v1.20.2.rc11?

With kind regards,
Andreas.

[amotl]

Dear @geza-pycom and @peter-pycom,

as you are currently looking into the integration of #483, can I humbly ask whether you could also take some minutes to look into this one as well?

I still believe it is pretty important to get stable readings from DS18B20 sensors as outlined through my links in the initial post. We have been running this in production for a quite a while now and are pretty satisfied with the results on this end.

Thanks already and with kind regards,
Andreas.

[amotl]

Dear @geza-pycom, @peter-pycom and @Xykon,

a user of our custom builds recently reported about a flaw at [1] after upgrading to one of the more recent official builds.

Given the reasonable non-invasive character of this patch, may I humbly ask if you might consider integrating it? It will probably save many people reading DS18B20 sensors more solid than with the pure-Python implementation, so it would be nice to see that upstream.

With kind regards,
Andreas.

[1] https://community.hiveeyes.org/t/ds18b20-no-module-named-onewire/3955

[jakehh]

Hello again, as this issue still persists: is there any chance for the proposed fix to be implemented anytime soon? This is highly anticipated!
Thanks and kind regards! Jan