1-Wire Line and Power

The 1-Wire protocol was designed for communication with low-data content devices like temperature sensors. It provides for low-cost remote sensing by supplying power over the same wire used for data communications. Each sensor can accept power from the data line while the data line is in the high state (which is also the line’s idle state). The small amount of power that is siphoned off charges the chip’s internal capacitor (usually about 800 pF).¹⁵

When the data line is active (going low), the sensor chips continue to run off of their internal capacitor (in parasitic mode). Data communications cause the data line to fluctuate between low and high. Whenever the line level returns high again, even for a brief instant, the capacitor recharges.

The device also provides an optional V_DD pin, allowing power to be supplied to it directly. This is sometimes used when parasitic mode doesn’t work well enough. This, of course, requires an additional wire, adding to the cost. This chapter will focus on the parasitic mode where V_DD is connected to the ground.

Line Driving

The data line is driven by open drain transistors in the master and slave devices. The line is held high by a pull-up resistor when the transistors are all in the Off state. To initiate a signal, one transistor turns on and pulls the line down to ground potential.

Figure 14-1 shows a simplified schematic of the master (GPIO) attached to the bus. Some voltage V (typically, +5 V) is applied to the 1-Wire bus through the pull-up resistor R_pullup. When the open drain transistor M₂ is in the Off state, the voltage on the bus remains high because of the pull-up resistor. When the master device activates transistor M₂, current will flow from the bus to the ground, acting like a signal short-circuit. Slave devices attached to the bus will see a voltage near zero.

Likewise, when a slave is signaled to respond, the master listens to the bus while the slave activates its driving transistor. Whenever all driving transistors are off, the bus returns to the high idle state.

The master can request that all slave devices reset. After the master has made this request, it relinquishes the bus and allows it to return high. All slave devices that are connected to the bus respond by bringing the line low after a short pause. Multiple slaves will bring the line low at the same time, but this is permitted. This informs the master that at least one slave device is attached to the bus. Additionally, this procedure puts all slave devices into a known reset state.

Master and Slave

The master device is always in control of the 1-Wire bus. Slaves speak only to the master when requested. There is never slave-to-slave device communication.

If the master finds that communication becomes difficult for some reason, it may force a bus reset. This corrects for an errant slave device that might be jabbering on the line.

Protocol

This section presents an introduction to the 1-Wire communication protocol. Knowing something about how the signaling works is not only interesting but may be helpful for troubleshooting. More information is available on the Internet.¹⁶

Reset

Figure 14-2 provides a simplified timing diagram of the reset procedure for the 1-Wire protocol. When the master driver begins, it resets the 1-Wire bus to put all the slave devices into a known state.

For reset, the bus is brought low and held there for approximately 480 μs. Then the bus is released, and the pull-up resistor brings it high again. After a short time, slave devices connected to the bus start responding by bringing the line low and holding it for a time. Several slaves can participate in this at the same time. The master samples the bus at around 70 μs after it releases the bus. If it finds the line low, it knows that there is at least one slave connected and responding.

Soon after the master sampling point, all slaves release the bus again and go into a listening state. They do not respond again until the master specifically addresses a slave device. For simplicity, we’ll omit the discovery protocol used.

Note

Each slave has a guaranteed unique address.

Data I/O

The data protocol is shown in Figure 14-3. Whether writing a 0 or 1 bit, the sending device brings the bus line low. This announces the start of a data bit.

When a 0 is being transmitted, the line is held low for approximately 60 μs. Then the bus is released and allowed to return high. When a 1 bit is being transmitted, the line is held low for only about 6 μs before releasing the bus. Another data bit is not begun until 70 μs after the start of the previous bit. This leaves a guard time of 10 μs between bits. The receiver then has ample time to process the bit and gain some signal noise immunity.

The receiver notices a data bit is coming when the line drops low. It then starts a timer and samples the bus at approximately 15 μs. If the bus is still in the low state, a 0 data bit is registered. Otherwise, the data bit is interpreted as a 1. Having registered a data bit, the receiver then waits further until the line returns high (in the case of a 0 bit).

The receiver remains idle until it notices the line going low again, announcing the start of the next bit.

The sender can be either the master or the slave, but the master always controls who can speak next. Slaves do not write to the bus unless the master requested it.

Slave Support

Configuration

The parameter gpiopin=4 specifies that the 1-Wire bus is on GPIO4. This used to be hard-coded in the driver but now permits you to choose differently. It is still the default if the parameter is not specified.

Parameter pullup=on is normally required for successful operation. Even though I had attached a 4.7 kohm resistor to +3.3 V for the bus, I could not get my devices to operate in parasitic mode. I recommend that you provide this parameter. Once you have edited the file, reboot for it to take effect.

The referenced README file also contains an entry named w1-gpio-pullup, which you should probably avoid unless you know why you are using it. It will require one additional GPIO to be used to pull up the bus (by default GPIO5).

Reading Temperature

Having not found the pathname /sys/bus/w1, we have confirmation that the device driver is not loaded.

The pseudo file names 28-00000478d75e and 28-0000047931b5 are device entries for the author’s two DS18B20 devices. Don’t worry if you don’t see your entries immediately, since it takes time for the discovery protocol to find them.

Slave Devices

Figure 14-4 shows the pin-out of the Dallas DS18B20 slave device. This temperature sensor is typical of many 1-wire slave devices.

Slave devices are identified by a pair of digits representing the product family, followed by a hyphen and serial number in hexadecimal. The ID 28-00000478d75e is an example. You might also want to try different devices, like the similar DS18S20. Figure 14-5 illustrates the DS18B20 attached to the Raspberry Pi GPIO.

When things are working correctly, the bus master detects slave devices automatically as part of its periodic scan. When your device(s) are discovered, they will appear in the devices subdirectory with names like 28-0000028f6667.

The following example shows how two DS18B20 temperature sensors show up on the 1-Wire bus:

$ cd /sys/bus/w1/devices

$ ls

28−00000478d75e 28−0000047931b5 w1_bus_master1

$

Figure 14-6 illustrates the breadboard setup used by the author.

Summary

In this chapter, the 1-Wire Linux support was put to use to read the Dallas Semiconductor DS18B20 temperature sensor. Table 14-1 lists several other types of 1-wire sensors that you may be able to use. Having driver support makes using sensors like these a breeze.