OneWire problems

I just implemented a OneWire interface on a PandaII for a few Dallas thermometers and thought i’d share a couple of small basic problems experienced.

When i implemented the OneWire code from the tutorial example (GHI Electronics – Where Hardware Meets Software) everything worked fine. Wanting to see what would happen when something goes wrong, I first removed the Dallas device and the code worked fine with the ow.Reset() returning false. Then i undid the wire to the sensor and the pull-up resistor and, evidently because the line was not being pulled up, the ow.Reset() returned true and the program hung at the loop while (ow.ReadByte() == 0) ; // wait while busy. I replaced that line of code with Thread.Sleep(750); and the routine returns a temp of 0. I would suggest changing the tutorial example.

I had previously implemented using the PH Anderson one-wire control chip. This worked fine as well except two of the pins on Anderson’s chip were dead on arrival. I emailed Dr. Anderson and asked for a replacement unit and he said no. I don’t blame him too much as shipping to Canada is more expensive then a new unit, but it would have been nice.

Hi Matt,

by definition the pull-up resistor must be fitted somewhere, and somewhere it can’t go “missing” like that, otherwise you do not get the correct bus responses, as you found.

The thread.sleep you have added is a fine work-around for the scenario you are talking about, but it is not a robust solution. The sleep in that case sleeps for the maximum length of time that the conversion should take, but you can shorten that by using a lower resolution, and then your sleep would need to be changed - the code as displayed will work and finish as soon as the chip signals that the conversion is finished. Because you’ve fallen through the reset() check you go into your wait, but then won’t have a valid sensor to read the temperature from anyway.

The example is also somewhat arbitrary and simplistic in that it assumes a single device but it can be extended to implement multiple devices.

So I wouldn’t suggest altering the example as it is less reflective of implementing code in accordance with the datasheet which I feel would be more misleading.

Thanks for the explanation, Brett. It is good to emphasize that the published code is only an example to be expanded upon. And i see that the waiting period can change as the resolution is changed. But given the possibility of a wire losing its pull-up, i prefer to have the routine spend extra time or write code that modifies the sleep period based on the selected resolution and having to deal with an invalid 0 temperature value in trade for the possibility of the routine falling into a black hole with no communication coming out!

On the PH Anderson chip, I should clarify that the two dead pins were two out of the seven I/O pins. The other five, and the power, ground, tx & rx worked fine.


Put the pull up on / close to the Fez, that way it’s more hardwired than “flexible”/“optional” and is less likely to be removed.