Introduction

There are several methods available for interfacing 1-Wire devices such as the DS18B20, DS18S20, or DS1822 to a microcontroller. These methods range from simple software solutions, to using a Serial Interface chip such as the DS2480B, to incorporating Maxim's VHDL 1-Wire Master Controller in a custom ASIC. This article introduces the user to the simplest possible software solution for basic 1-Wire communication between a microcontroller and any number of DS18x20 or DS1822 temperature sensors.

Detailed timing and operational information for the DS18B20, DS18S20 and DS1822 is available in their respective datasheets, which can be obtained from the Maxim website.

Hardware Configuration

The block diagram in Figure 1 illustrates the simplicity of the hardware configuration when using multiple 1-Wire temperature sensors. A single-wire bus provides both communication access and power to all devices. Power to the bus is provided through the 4.7kΩ pullup resistor from a 3V to 5.5V supply rail. An almost unlimited number of 1-Wire devices can be connected to the bus because each device has a unique 64-bit ROM code identifier.

Figure 1. Host microcontroller interface.

Interface Timing

Communication with the DS18x20/DS1822 is achieved through the use of "time slots", which allow data to be transmitted over the 1-Wire bus. Every communication cycle begins with a reset pulse from the microcontroller followed by a presence pulse from the DS18x20/DS1822 as shown in Figure 2.

A write time slot is initiated when the bus master pulls the 1-Wire bus from logic high (inactive) to logic low. All write time slots must be 60µs to 120µs in duration with a 1µs minimum recovery time between cycles. Write "0" and write "1" time slots are illustrated in Figure 3. During the write "0" time slot, the host microcontroller pulls the line low for the duration of the time slot. However, during the write "1" time slot, the microcontroller pulls the line low and then releases the line within 15µs after the start of the time slot.

A read time slot is initiated when the microcontroller pulls the bus low for 1µs then releases it so the DS18x20/DS1822 can take control of the line and present valid data (high or low). All read time slots must be 60µs to 120µs in duration with a minimum 1µs recovery time between cycles (see Figure 3).

Figure 2. Reset pulse and presence pulse.

Figure 3. Write and read time slots.

Software Control

In order to accurately control the special timing requirements of the 1-Wire interface, certain key functions must first be established. The first function created must be the "delay" function which is integral to all read and write control. This function is entirely dependent on the speed of the microcontroller. For the purpose of this article, the DS5000 (8051 compatible) microcontroller is used, which runs at 11.059MHz. The example to the right illustrates the "C" prototype function for creating the timing delay.

Delay Example

Since each communication cycle must begin with a reset from the microcontroller, the "reset" function is the next most important function to be implemented. The reset time slot is 480µs. By setting a delay of "3", followed by "25" (see the example below), the reset pulse will last for the required duration. Following the reset, the microcontroller must release so the DS18x20/DS1822 can indicate its "presence" by pulling the line low. Note that if multiple temperature sensors are on the bus, they will all respond simultaneously with a presence pulse.

The Search ROM Algorithm

To take full advantage of the 1-Wire net concept, the microcontroller must be able to communicate with any number of devices connected to the net. In order to do this, the microcontroller must learn the unique 64-bit ROM identification code for each device on the bus using the "Search ROM" algorithm illustrated in Figure 4. The example following Figure 4 explains a Search ROM routine for a bus with four slave devices. Sample code for a Search ROM routine is also shown. Once all the ROM codes have been identified, the "Match ROM" command can be used to communicate with any specific device on the net.

Figure 4. Search ROM algorithm.

ROM Search Example

During the ROM search process, the bus master must repeat a simple three-step routine: 1) read a ROM code bit from the slave devices, 2) read the complement of the bit, 3) write the selected value for that bit. The bus master must perform this three-step routine 64 times—once for each ROM code bit. After one complete pass, the bus master will know the ROM code for one slave device on the bus. The remaining devices and their ROM codes can be identified though additional passes.

The ROM Search process is illustrated by the following example that assumes four different devices are connected to the same 1-Wire bus. The ROM codes of the four devices are as shown:

Each device will respond to the Search ROM command by placing the value of the first bit of their respective ROM codes onto the 1-Wire bus. The master will then read the bus value. In this case, ROM1 and ROM4 will place a 0 onto the 1-Wire bus, i.e., they will pull it low. ROM2 and ROM3 will place a 1 onto the 1-Wire bus by allowing the line to stay high. The result is the logical AND of all devices on the line; therefore, the bus master will read a 0. All of the devices on the 1-Wire bus will respond to this read by placing the complement of the first bit of their ROM codes onto the 1-Wire bus: ROM1 and ROM4 will place a 1 onto the 1-Wire bus, allowing the line to stay high, and ROM2 and ROM3 will place a 0 onto the bus, pulling it low. The bus master will now read the bus again and will again read a 0.

Depending on the slave device ROM codes, there are four possible data combinations that the bus master can obtain from the two reads. These combinations can be interpreted as follows:

00

There are devices connected to the bus which have conflicting bits in the current ROM code bit position.

01

All devices connected to the bus have a 0 in this bit position.

10

All devices connected to the bus have a 1 in this bit position.

11

There are no devices connected to the 1-Wire bus.

In this example, bus master has read a 0 during each read, which tells it that there are some devices on the 1-Wire bus that have a 0 in the first ROM code position and others that have a 1.

In response to the previous data, the bus master writes a 0 onto the bus. This deselects ROM2 and ROM3 for the remainder of this search pass, leaving only ROM1 and ROM4 "connected" to the 1-Wire bus.

The bus master performs two more reads and receives a 0 followed by a 1. This indicates that all devices still connected to the bus have 0s as their second ROM data bit.

The bus master then writes a 0 to keep both ROM1 and ROM4 connected to the bus.

The bus master again executes two reads and receives two 0s. This indicates to the master that one of the devices on the 1-Wire bus has a 0 in the third ROM code position and the other has a 1.

The bus master writes a 0 onto the bus, which deselects ROM1 and leaves ROM4 as the only device still connected.

The bus master reads the remainder of the ROM bits from ROM4 and continues to access the ROM4 device if desired. This completes the first ROM search pass; the bus master has now uniquely identified one slave (ROM4) on the 1-Wire bus by learning its ROM code.

The bus master starts a new ROM search sequence by repeating steps 1 through 7.

The bus master now writes a 1 onto the bus (instead of a 0, as was done in step 8). This decouples ROM4, leaving only ROM1 still connected.

The bus master now reads the remainder of the ROM bits from ROM1 and can communicate with the ROM1 device if desired. This completes the second ROM search pass, and the master has now identified another slave device (ROM1).

The bus master starts a new ROM search by repeating steps 1 through 3.

The bus master now writes a 1 onto the bus (instead of a 0, as was done in step 4). This deselects ROM1 and ROM4 for the remainder of this search pass, leaving only ROM2 and ROM3 coupled to the bus.

The bus master executes two reads and receives two 0s.

The bus master writes a 0 onto the bus, which decouples ROM3, leaving only ROM2 connected to the bus.

The bus master reads the remainder of the ROM bits from ROM2 and communicates with the ROM2 device if desired. This completes the third ROM search pass, and the master has now identified the ROM2 slave device.

The bus master starts a fourth and final ROM search by repeating steps 13 through 15.

The bus master writes a 1 onto the bus (instead of a 0, as was done in step 16), which decouples ROM2, leaving only ROM3 connected to the bus.

The bus master reads the remainder of the ROM bits from ROM3 and communicates with the ROM3 device if desired. This completes the fourth ROM search pass, during which the master identified the ROM3 device. At this point the master has identified all the slave devices on the bus, and from this point on the bus master can individually address any of the devices using their ROM codes.

Note: The bus master learns the unique ROM code of one 1-Wire device during each ROM search pass. The time required to learn one ROM code is:

960µs + (8 + 3 × 64) 61µs = 13.16m

The bus master is therefore capable of identifying 75 different 1-Wire slave devices per second.

Search ROM Code Examples

As shown in the prototype function below, the "Find Devices" function begins with a 1-Wire reset to determine if any devices are on the net, and if so, to wake them up. The "First" function is then called, to keep track of the discrepancy bits and return to "Next", which finds each unique device on the net.

The "Next" function is quite extensive and does most of the work in finding each unique 64-bit ROM code identifier for each device on the net.

// FIRST
// The First function resets the current state of a ROM search and calls
// Next to find the first device on the 1-Wire bus.
//
unsigned char First(void)
{
lastDiscrep = 0; // reset the rom search last discrepancy global
doneFlag = FALSE;
return Next(); // call Next and return its return value
}

Reading Device Temperature

If there is a single device on the net, then the "Read Temperature" function can be used directly as shown below. However, if multiple devices are on the net, in order to avoid data collisions, the "Match ROM" function must be used to select a specific device.

The code example below was written specifically for use with the DS18S20 temperature sensor. To use this code with the DS18B20 or DS1822, it must be modified slightly due to differences in the temperature register format. Refer to the respective datasheet for temperature register format information.

Reading the Scratch Pad Memory

The Scratch Pad memory provides the user with all the necessary device data including temperature, TH and TL programmable thermometer settings, as well as the Count Remain and Count Per C data used in fractional temperature measurements. The CRC byte is also included in Scratch Pad memory.

Alert

Thank You for interest in Maxim Integrated. Our free samples program limits the quantities that we can provide to each customer per calendar year.If you feel that you have received this message in error, please contact samples-admin@maximintegrated.com. Please click here to place an order.