← index #8325PR #13171
Related · high · value 3.018
QUERY · ISSUE

MicroPython OneWire protocol BUG?

openby beyonloopened 2022-02-18updated 2024-09-08
enhancement

Hello!

I'm using the onewire CI DS28E05 (https://datasheets.maximintegrated.com/en/ds/DS28E05.pdf) but Micropython ow.scan() show nothing. That is a onewire chip, so it use/works with the onewire protocol, of course. Well, if it is onewire protocol, the CI address need to be shown on the ow.scan() right?

>>> os.uname()
(sysname='esp32', nodename='esp32', release='1.18.0', version='v1.18 on 2022-01-17', machine='ESP32 module (spiram) with ESP32')
>>> from machine import Pin
>>> import onewire
>>> ow = onewire.OneWire(Pin(25))
>>> ow.scan()
[]
>>>

Just to you know that onewire pin are working, if I use another onewire chip, the DS18b20 CI, it shows the address on the ow.scan() as follow bellow:


>>> os.uname()
(sysname='esp32', nodename='esp32', release='1.18.0', version='v1.18 on 2022-01-17', machine='ESP32 module (spiram) with ESP32')
>>> from machine import Pin
>>> import onewire
>>> ow = onewire.OneWire(Pin(25))
>>> ow.scan()
[bytearray(b'(\xa7I\xf0\x0c\x00\x00\x17')]
>>>

Any idea what is wrong? Is it a MicroPython OneWire protocol BUG or what I need to do to works the ow.scan()?

Thank you in advance.

CANDIDATE · PULL REQUEST

extmod/modonewire.c reliable timings for onewire.

mergedby eliaswimmeropened 2023-12-10updated 2023-12-15
extmod

When using long cables for sensors on onewire e.g. ds18b20,
the current default timings might be to optimistic.
Thus leading to bus failures and CRC errors.

Timings given by https://www.analog.com/en/technical-articles/1wire-communication-through-software.html give stable results.

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied