ROMfoolery

“I spy, with my little eye, a ROM address beginning with the sequence 0001010000011001…”

I’ve recently been playing with DS18B20 One-Wire digital temperature sensors (from Sparkfun — big surprise there). They’re fun little devices — accurate and cheap. They’re also insanely easy to wire up, having only three leads (they look just like 2N2222 transistors).

When Maxim says “one wire,” they mean it (not counting ground); you can even power it using the data line if you’re careful about timings and provide a strong pull-up when needed. Developing microcontroller code to drive them is nontrivial, though (various layers include bit timings, commands and ROM codes etc), but once it’s working, they’re very reliable.

Temperature A-to-D conversion takes up to 750ms, but you can issue a broadcast command to get all devices on the line to start a conversion at once, then read the results back at your leisure.

Here’s the first interesting part.

With a one-wire interface, timing and coordination of reliable two-way communications gets tricky. There’s no synchronization line — and from the description in the datasheet, the timing accuracy of these sensors isn’t all that wonderful, anyway. The scheme that Maxim worked out was that a short low pulse represents a one, and a longer low pulse represents a zero. A really long (more than 480 microseconds long) pulse resets the bus altogether.

But wait, there’s more.

The interface is specified so that multiple slave devices (I.E. multiple sensors) can share the bus. This takes not only coordination, but implementing the bus with an open-drain configuration (in other words, you use a fairly weak resistor to put 5V on the bus — and devices are only allowed to short the bus to ground, not pull it high.) This keeps communication collisions between devices on the bus from causing short circuits and burning up output transistors — but it also complicates timings and the basic communications protocol.

Now for the really interesting part.

Each sensor has a unique 64-bit serial number, which you need to know in order to interface with it. It’s not marked on the package (too small) or in the literature you get when you order the part (that would make too much sense), so Maxim provides a “Search ROM” feature, which uses a bizarre take on Manchester coding to send the address back. Two bits are read out at a time for each bit position in the 64-digit ROM code. 01 means the bit is a 0; 10 means it’s a 1; 00 means a conflict (someone on the bus sent a 1 and someone else — maybe a lot of someone elses — sent a 0); and 11 means that nobody is listening (check the circuit?). By going through bit by bit (with a lot of backtracking, if addressing a lot of these on one line), you can eventually determine the ROM codes for all devices on the line. It’s very Byzantine — but when you think about it, that’s really a result of the one-wire interface.

Here’s an example of how it would work with simpler devices that only had 4-bit ROM codes.

Suppose you had three devices on the bus, with ROM codes 0110, 1110, and 0101.

The least-significant bit is sent first; this comes back in two-bit Manchester coding as an “00.” (I.E. there’s at least one of each variety.)

The master (microcontroller) makes a decision at this point, and sends a one or zero. Any devices which match this bit in the first position keep listening; all others go idle and wait for a bus reset. In this case, we’ll default to zeros first. The master notes a conflict here, and sends a zero.

Sensor 0101 reads the zero and goes idle. Sensors 0110 and 1110 read the zero and continue, since it matches the least-significant bit in their ROM code.

The master then continues with reading the second bit. This comes back as a “10” — apparently all remaining devices agree that there is a “1” here. The master records a “1” and continues.

The master reads a third bit, which comes back as another 10. Another “1” is recorded and transmitted.

The master reads a fourth bit, which reads “00”. (Another conflict.) The master sends a zero; device 1110 goes idle, while 0110 is made active (having passed all the way through its ROM code). The master records 0110 as the ROM code of one of the devices on the bus — and records 1110, since it can deduce that; this being the last bit, that’s the only possibility.

The master then resets the bus, starts the ROM search process again, but sends a “1” this time when it reaches the conflict in the first bit. Device 0101 remains active this time while 1110 and 0110 go idle. The master then continues with the process; since 0101 is the only device left on the bus, no more conflicts occur.

Think of this process, expanded to 64 bits, and you have an idea of the situation. And not only that — you then have to figure out which sensor is which, if they are in different positions!

The amazing part is, once the code for this is written, it’s all over in a few milliseconds, and the ROM codes appear on the LCD…