Go Down

Topic: OneWire 2.2 preview (Read 7015 times) previous topic - next topic


I'm getting ready to release OneWire 2.2.  Here's a preview copy:


If anyone has any feedback about OneWire, please speak up ASAP (or wait approx 1 year for version 2.3)....

Coding Badly

A very minor thing and a question born purely out of curiosity...

There is a mix of tabs and spaces used to indent in OneWire.cpp.  I truly don't care.  But there are zealots who do and who are likely to complain (but they are also unlikely to find the perceived faux pas).  Just thought I'd mention it.

The timing in the OneWire library is a bit different than the timing called for by Maxim.  Was that done deliberately?  Have you found the results to be better with the different timing?


The timing in the OneWire library is a bit different than the timing called for by Maxim.

OneWire tries to be within Maxim's recommended timing, but towards the end of each recommended sampling period, to allow for long wires with extra capacitance.

Could you be more specific on the places with OneWire varies from Maxim's recommendations?

Coding Badly

Could you be more specific on the places with OneWire varies from Maxim's recommendations?

I can and I will but it will take a few days (day-job interference).

Coding Badly

Bugger.  I missed a newer document describing the timing... http://www.maximintegrated.com/app-notes/index.mvp/id/74

This is the one I've been using... http://www.maximintegrated.com/app-notes/index.mvp/id/126

I'll report back after I've dug through the newer one.

Coding Badly

As far as I can tell, the Maxim folks still recommend... http://www.maximintegrated.com/app-notes/index.mvp/id/126 ...for things like the OneWire Library.

The differences between that document and the library are small...

         Write 1   Write 0      Read         Reset
         -------   -------   ----------   ------------

Maxim     6, 64    60, 10     6,  9, 55   480, 70, 410

Library  10, 55    65,  5     3, 10, 53   480, 70, 410

The rules in table 2 here... http://www.maximintegrated.com/app-notes/index.mvp/id/74 ...are supposed to be used for networks with "new" and "old" devices.  But I think Maxim is trying to achieve greater reliability over longer distances.  I don't think that's within the scope of a general purpose Arduino library.


Yes, that's a good point.

I've mainly used the DS18*20 datasheets for timing info.  This page is somewhat different.  The main difference is they give a minimum of 5us for parameter A.  In the datasheet has a minimum of 1us.  That concerns me.  Here's the info I've been using for OneWire:

OneWire's read timing is intentionally a couple us short to allow for a couple extra microseconds of delay for the slowness of 8 MHz AVR executing the other instructions.  The DS18B20 datasheet also shows the sampling must occur before 15 us, and seems to indicate that sampling at exactly 15 us risks reading at the first instant the voltage might start rising.  That's why I have a total of 13 us before sampling the bit.

Given 1us minimum pulse width, and 13 total (at least in delayMicroseconds, probably pushing to 14 on 8 MHz AVR), I wanted to allow as much time for the pullup resistor as possible, but not risk making the pulse too narrow.  3X the minimum (at least the minimum in the datasheet) seemed like a good idea, stealing only 2 of the 12 possible microseconds for the pullup to charge the line's capacitance.

The other interesting thing about this app note is parameter A is used for both read and write.  The worksheet says A's range is 5 to 15 us, which makes perfect sense for a write.  But if A is also used for the read, as shown in the diagram (and they have no separate parameter for the beginning of a read), the upper end of that range obviously can not be correct.  It really makes me doubt this page is the best possible advice about 1-wire timings.

Also, OneWire cheats somewhat for writing.  It drives the line high, rather than using the pullup resistor.  The timing can be somewhat longer because the uncertainty of the pullup is not a factor.  That's utterly incompatible with a multi-master bus, but OneWire is a master-only library.  But it does give really predictable timing for writes, which are most of the bus time, and have no CRC checking.  Most devices send a CRC at the end of their data while reading.

For writing, the worksheet's range for A is 5 to 15 us, and OneWire drives 10 us.  I really believe that is a good approach, to use a longer time for A while writing, and a shorter time while reading.

However, I'm not saying the timings in OneWire are absolutely the best possible numbers.  I'm going to think on this more over the next couple days, and try experimenting a bit.  Maybe adjusting slightly makes sense....

Thanks for bringing this up.  :)


Hi, I did some work on 1-wire protocols (Master and Slave) for the Arduino in my Cosa project. The original code from Maxim is over complicated and may be made much simpler and smaller. Also the potential of C++ can be used to improve device driver writing. Please see https://github.com/mikaelpatel/Cosa/blob/master/Cosa/OWI.hh and OWI.cpp and the device driver directory (Cosa/OWI).

From your work I believe I will have to go back and adjust some of the timing. Thanks for the preview.

Best regards

Go Up