Putting 1-Wire Protocol into Action

Power and Control Share a Link

The 1-Wire protocol enables control and power to be accomplished through a single I/O pin. In this project article, Jeff shares the history and evolution of Maxim Integrated’s 1-Wire scheme and how he discovered that special steps need to be taken to ensure you get sufficient power delivery using this technology.

The Dallas Semi brand began with communications and mixed-signal products introduced in the 1980s. My first exposure was with the iButton. Manufactured in a tin can the size of a large Li-Ion coin cell, the iButton used a 1-Wire protocol for communication via a single I/O pin. The communication identified any iButton as a specific, 48-bit ID number. Like fingerprint identification, iButtons (Figure 1) were built into rings, tags and other personal items that could be carried around and used to identify a particular person or item. Once the technology was proven, the usefulness expanded to include data storage, temperature sensing and other functions. The iButton could be used to store cash for small transactions, such as transit systems, parking lots and vending machines. Unfortunately, the public was not ready for cashless transactions. As a result, the iButton was never really accepted.

Maxim Integrated acquired Dallas Semi in 2001, and those 1-Wire devices continue to be produced today with their familiar “DS” part number prefix. In July 2020, Analog Devices acquired Maxim Integrated, and we’ve yet to see where that will go.

1-Wire devices are typically manufactured in TO-92 (plastic transistor case) and assorted surface-mount parts. I recently purchased some sealed temperature sensors (Figure 2) that are suitable for wet environments for an agricultural project. A couple of years ago, I did a project using the ESP8266 from Espressif Systems, and that circuit was perfect for this project (Figure 3). That device can easily do MQTT communications for data logging purposes. My Raspberry Pi running an MQTT server will collect this data, but I digress. Even with limited I/O on Espressif’s ESP-01, the 1-Wire interface is no problem. This project is about communications with multiple DS18B20 temperature sensors using the 1-Wire protocol.

Terminology note: Although the terms “master” and “slave” have long be used in the electronics industry, those terms currently are discouraged for obvious and valid social reasons. The industry as a whole has not yet come to any agreement on replacement terms. For this article we’re using the term “controller” to replace “master,” and “remote” to replace “slave.”

• Figure 1
• Figure 2
• Figure 3

POWER AND COMMUNICATIONS

The 1-Wire protocol is an open collector bus controlled one controller that initiates (most) transmissions. iButton devices were often connected and disconnected from a contact port by a user who would need to identify him/herself to the equipment to authenticate identification. This ability required a way for a controller to notice that a device had been connected. The remote device shorts the 1-Wire bus to ground for 480µs to signal the controller to search for new devices. While this is not required when devices are permanently connected to a 1-Wire bus, the “presence pulse,” as it is called, can still be monitored. In fact, all devices do this when they first receive power from the 1-Wire bus and when a controller asserts a reset pulse. Let’s begin with a look at a controller’s reset pulse.

The open-collector bus is typically pulled up to V_CC (minimum of 3.0V) with a 4.7kΩ resistor. The bus is considered idle when no device (controller or remote) is pulling the bus to ground, and therefore, it will be at a logic 1 state, at or near V_CC. When any device pulls the bus to ground, it will be in a logic 0 state. During idle time, all remotes will see V_CC and an internal diode allows an internal capacitor to be charged up to V_CC. This internal diode/capacitor creates a parasitic power supply to allow the device to operate even when the 1-Wire bus is pulled to ground.

Of course, if the bus remains low for too long, eventually the remote device will use up this parasitic power and cease to function. The tiny power requirements of remote devices allow them to remain powered as long as the bus returns to idle within a reasonable time. The transmission protocol timing always assures that this will happen. Bus power is not available periodically when the bus is at a logic-low state.

When a controller wants to communicate, it asserts a reset pulse on the bus, which will remain low for 480µs. Besides the internal parasitic power circuit, all remote devices have a single open-collector I/O port connected to the bus to monitor the bus state (as an input) and pull the bus to ground (as an output) when required. All data is based on the time the bus remains in a logic 0 state, so remote devices must begin a timer on a falling edge of the 1-Wire bus. Remote devices don’t have to do anything until they see a logic low for 480µs. At this point, they must respond with a 480µs (presence) pulse.

When a controller has finished its reset pulse, it monitors the bus for a falling edge, just like a remote. If no remotes are on the bus, then no one will reply, and the 1-Wire bus remains high. If it sees a 480µs (presence) pulse, it will know that some device is on the bus. Note that 1-Wire devices don’t come with any indication of the 48-bit unique ID each has been assigned, but each type of device has an 8-bit family code associated with it. For the DS18B20 temperature device, that family code is 0x12. This family code is the first byte of the 64-bit ROM code programmed into each remote device. The family code (1 byte) is followed by the unique 48-bit ID (6 bytes) and a 1-byte CRC (cyclic redundancy check) value.

We need to take a break here to discuss how data are sent and retrieved. First, check out the sidebar “Data-Bit Protocol” below. A controller can send a 1-byte command to a remote once it has sent a reset pulse and it sees a presence pulse. All 1-byte commands are followed by a unique 64-bit device code. All remotes will respond to all commands where the 64-bit device code requested matches their ROM code. If a remote sees a request for a 64-bit code that does not match its ROM code, it will remain silent until the next reset pulse.

WHO ARE YOU?

You can see that if a controller requests a response from an address that doesn’t match any device, no one will respond. So how do we know what addresses to request, if we have no documentation to identify the device you have, other than the 1-byte family code?

We could try every one of the possible 48-bit codes. The would be 281,474,976,710,656 possible requests. While this certainly would be possible, it is not practical. But there is a way to determine which devices are here by using a tree search. This short cut is possible thanks to the Search command. This command works differently from all other commands. It requests all remotes to place their ROM codes on the bus 1 bit at a time in a controlled process. This process consists of 64 requests, one for each bit of the 64-bit ROM code. After receiving the Search command, each remote will begin with bit 1 and place its bit state on the bus, and then this bit’s complement on the bus. This action requires the controller to send two read “slots” and receive 2 bits from all the remotes. Upon a reset, all the remotes are active and will respond at the same time.

As discussed before, this creates chaos, but ordered chaos, since there are four possible outcomes. If all active devices have a logic 1 in this bit position, they will all respond with a logic 1 data bit and then a logic 0 data bit. All is good. If all active devices have a logic 0 in this bit position, they will all respond with a logic 0 data bit and then a logic 1 data bit. Again, all is good. If no device is active, the controller will see two logic 1 data bits, because no one is there to pull down the bus to a logic 0 state.

Now comes the issue: If any two devices have opposite data bits, the one with a data “0” will pull the bus down during the first bit, and the one with a data “1” will pull the bus low during the second bit. The controller will see two logic 0 states and know that there is a conflict at this bit position. At this point, the controller must choose which path it will take at this fork in the road. It will make this decision based on these bits and the preferred direction. It will choose the logic 1 direction, choosing the “1” path first. Table 1 shows the controller’s path choice based on the corresponding remote replies.

Based on these replies shown in Table 1, the controller selects a path and responds with a write “slot” by sending the chosen logic state. At this point, assuming we have devices responding, those that match the controller’s reply will stay active, and remotes that do not match will go to sleep until they’ve seen a reset pulse. So, you can see that by repeating this process with the remaining 63 bits, eventually only one will remain active by the end of the process. We’ve just identified one of the devices!

We can now begin a search again, taking a different branch this time, until there are no devices left active, in which case we’ve found them all. This search algorithm requires keeping track of a few things so we know where we’ve been and where we’re going, but it is fairly efficient. You can read more about the search algorithm at [1].

I KNOW WHO YOU ARE!

Now that we’ve found all the devices on the bus and looked at their ROM codes, we can determine in which devices we are interested. In reality, I only put DS18B20 temperature devices on the bus, but this is a general statement pertaining to a black box of devices of unknown types.

The 64-bit ROM code is divided into 8 bytes, the first of which is the family code, in this case 0x12. The last byte is a CRC of the first 7 bytes. It can be used to check the validity of the ROM code (or any transmission). It uses the polynomial X⁶ + X⁵ + X⁴ + 1. You can learn more about how to calculate this CRC this in Maxim’s app note at [2].

Using the search algorithm is a project in itself. Once you’ve conquered this one, the remaining standard commands are simple. Here is a list of these commands:

0xF0 — Search ROM—for all 1-Wire devices on the bus
0x33 — Read ROM—can be used to retrieve data without using a ROM address (useful when only one device is on the bus)
0x55 — Match ROM—addresses a specific ROM code to put all other devices to sleep
0xCC — Skip ROM—can be used to make a request to all devices without using a ROM address
0xEC — Alarm Search ROM—similar to Search ROM but only 1-Wire devices with pending alarms will respond

For this project, we’ll need only two commands—Search ROM to find all devices, and Match ROM to communicate with them. Ah, I see you thought “that’s it!” Well, no, because once we can talk to a single device, we need to use one of the memory commands to get any data required. We’re now into the easy stuff, so don’t sweat it. Let’s see just what makes up a DS18B20 device.

DS18B20

The block diagram in Figure 4 shows how the parasitic power is developed from the 1-Wire bus (or an alternate third connection, V_CC). The circuitry powered by this capacitor C_PP includes the 64-bit ROM code and a memory access port. We’ve previously discussed how you can’t even get to the memory without knowing and matching the correct ROM code—which is unique to each device. The memory is a group of eight registers called the scratchpad, and a group of three registers called the EEPROM (Figure 5). The first two registers hold the resultant 9- to 12-bit converted temperature. The next three registers are user programmable, in that any data you write to them can be permanently stored in the corresponding EEPROM register, via a Memory command.

• Figure 4
• Figure 5

The first two registers consist of ALARM values for the low and high conditions, which are compared to every temperature conversion and would trigger an ALARM. An ALARM is only useful if you use the Skip ROM and Convert command to initiate all devices to do a conversion, and then use the Alarm Search ROM command to look for devices in an alarm condition. There is no other way to retrieve the result of an internally recognized alarm condition. You can of course do this externally by reading the temperature and doing your own compares for a low or high alarm condition.

The configuration register is used to set how many significant bits are used in the temperature conversion 9 to 12 (default is 12). A lower bit resolution requires less conversion time (12 = 750ms and 9 = 94ms). The upper registers are reserved except for the last, which is a CRC of the first seven registers. I previously discussed how to get a device’s attention (by putting all others to sleep), so you could access the memory. Now we have these sub commands available:

0x44 — Convert T—remote converts current temperature and writes to Scratchpad (device sends a logic ‘0’ state while busy, if NOT using parasitic power)
0x4E — Write Scratchpad—remote receives Scratchpad registers from controller
0xBE — Read Scratchpad—remote sends Scratchpad registers to controller
0x48 — Copy Scratchpad—remote writes Scratchpad registers to EEPROM
0xB8 — Recall EEPROM—remote writes EEPROM registers to Scratchpad
0xB4 — Read Power Supply—device sends a logic ‘0’ state if using parasitic power.

Not every memory command requires additional data to be sent or received. Any action associated with the EEPROM is all internal and requires no data. Converting and reading the supply requires the controller to read one bit, a status. Reading from or writing to the Scratchpad has 8 bytes of data associated with each command. Here’s the kicker! Conversion and EEPROM activities require more current than normal, and unless you are powering all devices with V_CC, which defeats the purpose of 1-Wire simplicity, you must do something else—which is counter to the open-collector arrangement normally associated with the 1-Wire bus.

Remember the conversion time mentioned earlier? You must “force feed” the 1-Wire bus for a minimum of that conversion time as soon as you finish the (Convert T) command. By force feed, I mean the controller must replace the open-collector output with a driven output to offer devices a larger current source! During this time, no communication can take place on the bus, because you would be attempting to short V_CC to ground. While devices are current limited, this is not good practice.

In this project I know I am using parasitic power but not any alarms, so I can forgo any memory commands except Convert T and Read Scratchpad. However, let’s look at the 1-Wire bus routines before we put this all together and actually convert some temperatures.

1-WIRE BUS CONTROL

One of the most critical parts is not missing a remote’s reply. To accomplish this, I use an interrupt on the falling edge of the 1-Wire bus. The interrupt merely sets the state of a bit to a logic 0, if that should occur. When the controller releases the bus, it also sets this bit as a logic 1, waits the proper time and then reads that bit. It will be logic 0 if an interrupt occurs (the remote pulls bus low any point during that time).

I broke the reset operations into simple functions. The first writes an extended (480µs) “zero slot,” and the second writes an extended (480µs) “one slot” (looking for any devices producing a presence pulse). The Controller Reset function writeReset() calls these two functions, Tresetlow() and Tresethigh() (Listing 1).

Listing 1

The Controller Reset function writeReset() calls these two functions, Tresetlow() and Tresethigh().

//----------------------------------------
//  send out a long logic low reset pulse
//----------------------------------------
void Tresetlow()
{
  digitalWrite(oneWire_Pin,0);       // write logic '0' to 1-Wire pin
  pinMode(oneWire_Pin,OUTPUT);       // write 1-Wire pin as an output
  delayMicroseconds(480);            // wait 480µs
  pinMode(oneWire_Pin,INPUT_PULLUP); // write 1-Wire pin as an open collector input
}
//----------------------------------------
//  wait for 480µs to see if any one is out there myBit=0
//----------------------------------------
void Tresethigh()
{
  iState = 1;                 // initialize interrupt state bit as logic '1'
  delayMicroseconds(480);     // wait 480µs   
  myBit = iState;             // get interrupt state bit status
}

Only three additional functions are necessary for 1-Wire communications: the data transmission and reception functions Twritezero() and Twriteone(), and Tread() (Listing 2). The only difference between a Twriteone() and Tread() is that during Tread() the controller is looking for a response.

Listing 2

For 1-Wire communications, only three additional functions are necessary: the data transmission and reception functions Twritezero() and Twriteone(), and Tread().

//----------------------------------------
//  write a logic '0' time slot
//----------------------------------------
void Twritezero()
{
  digitalWrite(oneWire_Pin,0);       // write logic '0' to 1-Wire pin  
  pinMode(oneWire_Pin,OUTPUT);       // write 1-Wire pin as an output
  delayMicroseconds(60);             // wait 60µs
  pinMode(oneWire_Pin,INPUT_PULLUP); // write 1-Wire pin as an open collector input
  delayMicroseconds(1);              // wait 1us to recover  
}
//----------------------------------------
//  write a logic '1' time slot
//----------------------------------------
void Twriteone()
{
  digitalWrite(oneWire_Pin,0);       // write logic '0' to 1-Wire pin  
  pinMode(oneWire_Pin,OUTPUT);       // write 1-Wire pin as an output
  delayMicroseconds(1);              // wait 1us (low pulse minimum)  
  pinMode(oneWire_Pin,INPUT_PULLUP); // write 1-Wire pin as an open collector input
  delayMicroseconds(60);             // wait 60µs
  delayMicroseconds(1);              // wait 1us to recover  
}
//----------------------------------------
//  write a logic '0' time slot and look for a reply
//----------------------------------------
void Tread()
{
  digitalWrite(oneWire_Pin,0);       // write logic '0' to 1-Wire pin  
  pinMode(oneWire_Pin,OUTPUT);       // write 1-Wire pin as an output
  delayMicroseconds(1);              // wait 1us (low pulse minimum)
  pinMode(oneWire_Pin,INPUT_PULLUP); // write 1-Wire pin as an open collector input
  iState = 1;                        // initialize interrupt state bit as logic '1'
  delayMicroseconds(45);             // wait 45µs sample time 
  myBit = iState;                    // get interrupt state bit status
  delayMicroseconds(15);             // wait 15µs release
  delayMicroseconds(1);              // wait 1µs to recover
}

The rest of the work, issuing the ROM and Memory command, are all based on these five routines to control the 1-Wire bus. I’ve sprinkled debugging flags throughout this code. These can be enabled or disabled to show results from many of the functions. This is an aid in the development of the routines to assure the results obtained are what was expected.

While the Search ROM command is initially required to identify devices, if you’ve done this by some other means and labeled them (Figure 6), you could just hard code the ID and save a ton of coding, since the search function is rather lengthy. The search routine here has successfully ID’d the devices, and now we can communicate with each one individually, because the IDs are in the array ROMList[]. For every temperature device family (0x12) in the list, we can perform a temperature conversion and read the results with two commands,  convertT() and readScratchpad().

If you do a readScratchpad() before converting, you will get the previous conversion again. If a conversion has not been done since the last reset, you will get the default value 0x0550 (which corresponds to 85°, so be aware). A conversion is accomplished by writing command 0x44 to the bus (as 8-bit time slots, LSBit (least significant bit) first) and then force feeding the bus to V_CC (temporarily redefining the output as TTL vs. open-collector) for 750ms.

The conversion value can be read using the readScratchpad() command, 0xBE. This command requests the remote to dump its scratchpad memory to the controller. The controller will therefore need to issue up to 64 Tread() slots, to get all the data. The controller can quit requesting additional data early, once it has received what it is looking for. I gather all 8 bytes here. The first 2 bytes contain the conversion data. Up to 12 bits of data are available. The lower nibble (4 bits) of the first byte is a fractional part of the temperature. Each bit is 1/16 of a degree, in increments of 0.0625°C. The upper nibble of the first byte, along with the LS3Bits of the second byte, are the integer portion of the temperature in degrees Celsius.

The MSBits (most significant bits) of the second byte indicate the polarity of the temperature—1 equals negative, and 0 equal positive. So, when the temperature is negative, the value is the two’s complement of the temperature (Figure 7). When you reduce the resolution from 12-bits, you lose the LSBits of data, the fractional portion, so with 9 bits you have a temperature conversion resolution of 0.5°C.

To convert Celsius to Fahrenheit, use the formula:

For a temperature of 24°C we get:

In this application, once the temperatures are gathered, they are sent to my MQTT server. There, they can be saved, displayed and used to make other decisions. I like to use the MAC number of the processor as the message Topic, with messages containing the temperatures formatted in a JSON array, like “Temp1:74.2,”“Temp2:73.0,”“Temp3:81.3” and so on…

UNIQUE

The 1-Wire bus is surely one of the most unique serial communications protocols being used today. Supplying (parasitic) power to its peripherals gives the 1-Wire bus an advantage that might make it useful in one of your own designs. Although neither Maxim Integrated nor Analog Devices have made any additions to this line in a while doesn’t mean it’s dead. The ability to read a unique serial number via a single port pin has continued applications anywhere ID recognition is needed. In addition, access to external data storage, sensors and I/O control have benefits that add to the usefulness of this bus. With some of the new super-low-power processors, it may be possible to add your own peripheral to this bus and take it to the next level.

Too much to ponder, so little time. 

RESOURCES

References:
[1] Application Note 187 – 1-Wire Search Algorithm
https://www.maximintegrated.com/en/design/technical-documents/app-notes/1/187.html
[2] Application Note 27 – Understanding and Using Cyclic Redundancy Checks with Maxim 1-Wire and iButton Products
https://www.maximintegrated.com/en/design/technical-documents/app-notes/2/27.html

Analog Devices | www.analog.com
Espressif Systems | www.espressif.com
Maxim Integrated | www.maximintegrated.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • AUGUST 2021 #373 – Get a PDF of the issue

Jeff Bachiochi

Website | + posts

Jeff Bachiochi (pronounced BAH-key-AH-key) has been writing for Circuit Cellar since 1988. His background includes product design and manufacturing. You can reach him at: jeff.bachiochi@imaginethatnow.com or at: www.imaginethatnow.com.

• Jeff Bachiochi

  https://circuitcellar.com/author/jeff-bachiochi/

  Under Pressure?
• Jeff Bachiochi

  https://circuitcellar.com/author/jeff-bachiochi/

  A Radar Speed Monitor
• Jeff Bachiochi

  https://circuitcellar.com/author/jeff-bachiochi/

  Just How Fast Was I Driving, Officer?
• Jeff Bachiochi

  https://circuitcellar.com/author/jeff-bachiochi/

  Rainbow LEDs