some wonders about delayMicroseconds, how fast digital read / write mode is set, etc [note: core v1]

[jerabaul29]

I am using the core v1.

I have had quite a few difficulties getting the DS18B20 to work reliably (see #409 ). I finally took my courage together and started experimenting with / tweaking around the delayMicrosecond values in the OneWire protocl library from Paul Stoffegren. After some tweaking and experimenting, it seems that I can get a reliable DS18B20 communication.

It looks like reducing the delayMicrosecond values was key to getting ok communication. I went from the OneWire default values (which were about in the middle of what the OneWire spec says) to shorter delays (close to the lower / faster limit), and things seem to work. Unfortunately, I do not have a logical bus analyzer / oscilloscope, so I cannot look in real details, but a few thoughts, and in case someone else wants to look at it:

• I would be curious to know how much the overhead / delay induced by the different digital gpio pins arduino commands is. For example, when doing some pinMode, digitalRead, digitalWrite, are there / could we have together with the functions some estimates of 1) time to execute and change the pin state, 2) jitter?
• It looks like the thing that was doing most was really to reduce the value of the delayMicroseconds. It looks like the typical cutoff value was around 4 times shorter delays compared with what the OneWire speccing says. Wonder if this is a coincidence (possible of course :) ), or if there is some prefactor missing / wrong somewhere.

Anyways, only way to know would be if someone with more equipment than I looks at it :) .

[paulvha]

I did a project couple of weeks ago around this topic. Timing is extremely sensitive and I got it to work on V1, but had to apply an alternative approach for V2. I have included timing traces and my analyses in the document. It is all posted on https://github.com/paulvha/apollo3/tree/master/OneWire_on_uart

regards,
Paulvha

[jerabaul29]

@paulvha cannot thank you enough, this is amazing, super helpful :) .

Core v2 is not for me anyways, but thanks for confirming that things are at the very limit with core v1 by default. I guess this is why I was having many issues (sometimes intermittent), and in particular when using many DS18B20...

I had applied a "poor man's fix" of reducing the delays in the OneWire library by hand, but your "native macros" approach is much better :) . Could you issue a pull request to the OneWire library, so that the "custom macros mode" becomes available to all? That may save a lot of time to many other users who like me are bumping into problems otherwise :) .

[jerabaul29]

(really amazing how much overhead MBedOS adds; one would believe that 'things go fast anyways' when running the CPU at 48MHz, but clearly not... Would be curious to see if the overhead halves when using 96MHz burst mode ^^ ).