1-wire library and pyb.freq()

[JimTal001]

Thank you for the analysis. Looks like I'm stuck at 120 Mhz for awhile.

[manitou]

Here is snapshot of analyzer with ow.write_byte(0xa5)

onewire.png (130.97 KiB) Viewed 6221 times

The critical timing is that writing a 1-bit is supposed to start with a low pulse of < 15 us. At 168mhz, the python low pulse is 15.25us. The spec says the receiver sampling window is 30us, so the one-wire device will read the value sometime between 15us and 30us from the start of the low pulse. At 120mhz, that low pulse expands to 21.35 us. You could remove the udelay(d0) from the 1-bit write in onewire.py, and that drops the low pulse to 11.375us at 168mhz, and then you might be able to run at 84mhz (or lower) , though whether that succeeds could vary from device to device.

You could also rewrite _write_bit() in python assembler to stay under the 15us threshold, or implement the driver in firmware/C. My experiments with Teensy 3.1 and DS18B20 suggests that the DS18B20 is reading data at about 28us after leading edge of low pulse.

EDIT: _read_bit() also has a < 15us threshold, udelay(d0) could be removed or re-write in python assembler or firmware/C. With the analyzer, the read_bit low pulse is 12.125us @168mhz. if you comment out the udelay(d0), pulse width is 8.25us.

The read_bit timing may not be as critical. My observations of DS18B20 are that it holds its low bit value for 28us.

[JimTal001]

Thanks for the analysis, I will try commenting out the delay and get back with results.

[Damien]

Thanks for the analysis, I will try commenting out the delay and get back with results.

We have developed a new 1-wire driver that works with the latest version of the pyboard firmware as well as the WiPy. This new version works down to 54MHz on the pyboard!

You can find the code in the wipy 1-wire topic on this forum, and it will be put in the github repository very soon.

[JimTal001]

Fantastic! Thanks for the great work...

[manitou]

We have developed a new 1-wire driver that works with the latest version of the pyboard firmware as well as the WiPy.

The slimmed-down onewire.py looks good. For visual comparison, here is logic analyzer with new onewire

onewire1.png (138.01 KiB) Viewed 6074 times

The low pulse-width at 168mhz is 5.875us. At 84mhz, the low pulse-width is 10.625us

[pfalcon]

it appears that in addition to pyb.udelay(), the driver is trying to take into account the delay of each micropython statement (say about 5us) in order to arrive at the cumulative delay expected by the protocol. As you slow the system clock, those "statement" timing assumptions will fail, even though udelay() adjusts to the clock frequency ....

That's why we have utime.ticks_us() and utime.ticks_diff() functions - to write properly-timed busy-loops. They obviously won't help if frequency too low to accommodate latency of Python code, but otherwise, they allow to account for such latency.