search

pstolarz / OneWireNg

Arduino 1-wire service library. OneWire compatible. Dallas thermometers support.
BSD 2-Clause "Simplified" License
89 stars 20 forks source link

Proposal for evolution #31

Closed abusr closed 2 years ago

abusr commented 2 years ago

I'm looking at the bitbang driver and how it is constructed. In order to work it needs to utilize critical sections with other interrupts shut off as well as precise us class timing. I propose to consider adding some sort of interrupt based alternative in the future. I've seen implementations of onewire based upon serial ports for example or you could use your own timer interrupt with a light state machine behind it.

I'm writing all these because in a complex project with many components, if each of them was shutting the ints off to achieve precise timing, the ints will fatally begin to lag and other things shall start to fail..

pstolarz commented 2 years ago

The problem with interrupt based timings is a short period of pulse required by the 1-wire protocol. For example plenty of timings are 5-8 us in length (even 1-2 us for OD mode). I don't see effective implementation of such timings in this way. For example take a Linux platform with jiffie freq 1000Hz, where the clock interrupt is fired every 1ms. In this context only HRTs are capable to provide usec resolution. Similarly in this case I don't see proper solution of this issue w/o HW supported timers or timing capabilities.

On the other hand, the longest period of time the library freezes in the no-interrupt state is 60-70 us (in 3 cases: write-0-low, reset-sample, reset-od-low). I believe, overall 1-wire stability would not be drastically compromised if these cases have been moved outside of the time critical (no interrupt) section. In this case only 5-8 us pulses would be protected by no-interrupt state. I think this could provide a trade-off between platform vs 1-wire service stability.

abusr commented 2 years ago

Hello Piotr, thanks for answering. These time critical protocols can be hard when you have just the mcu with no assisting hw. Because a bare single core mcu can do one thing at time, more than one time critical tasks are not guarranteed to coexist (if they can not somehow be offloaded to assisting hw). Having written my own stack for microlans a decade+ ago (pic assembly), and having other work to do on the mcu side, I finally took the decision to spare a small pic per microlan to terminate the microlans there rather than at my main mcu.