The 1-Wire protocol uses a single wire for data transfer, and sometimes power. Data is transferred in time-sensitive ‘slots’ because there isn’t a separate clock to delineate bit periods.

Bus Pirate

DS1822

SDA

DQ

+5volts

Vdd

Ground

GND

The DS1822 connections are shown in the table. We used the Bus Pirate’s 5volt supply to power the DS1822, but it also works at 3.3volts. A resistor (R1, ~5K) holds the bus high.

All 1-Wire commands start with a reset procedure, followed by one of five ROM commands.

Command

Description

0x33

READ ROM. Read single device address.

0x55

MATCH ROM. Match device address, followed by 64bit address.

0xCC

SKIP ROM. Address all devices together.

0xEC

ALARM SEARCH. Search for alarm condition.

0xF0

SEARCH ROM. Part of address enumeration procedure.

ROM commands are described on page 10 of the datasheet. All ROM commands are available as macros in the Bus Pirate 1-Wire library, see (0) for a menu. ROM command macros include the 1-Wire bus reset procedure.

Single device

All 1-Wire devices have a unique 64bit (8 byte) address, and some 1-Wire devices are used exclusively to give electronics a unique tracking number. When a single device is connected to a 1-Wire bus, the READ ROM command will extract its address.

The READ SCRATCHPAD command (0xBE, datasheet page 11) returns 9 bytes. We only care about the first two bytes, the rest can be decoded according the the table on page 7 of the datasheet. Temperature is calculated according to page 4 of the datasheet: 0x0171 HEX=369 DEC, 369*0.0625=23C (74F).

Multiple devices

When multiple 1-Wire devices share a bus it’s more difficult to determine all the addresses. The fastest way to find attached devices is with the SEARCH ROM command (0xF0) and a binary branching procedure. The Bus Pirate automates this with macro (240).

The SEARCH ROM command shows the devices it found, and the type according to the family code.

We think typing 8 byte 1-Wire addresses is really tedious, so the first 10 device addresses are stored in memory and can be accessed with the macros (1)…(10). A buffer for up to 50 device addresses can be defined in the 1-Wire library at compile time. Ideally, this data will be stored in a global scratch buffer shared by all modules in a future firmware update.

(85) is a shortcut for a bus reset and MATCH ROM command. (1) is the device address macro, and 0x44 is the command to begin a temperature conversion. Retrieving the reading involves the same macros, but substitutes the command to read the device (0xBE) and grabs 9 bytes (r:9). The temperature is 0x0181, or 24C next to the PC fan.

Taking it further

We used the Bus Pirate to give a visual demonstration of the 1-Wire protocol, but the real challenge is integrating it into your own design. Maxim provides example code, Microchip has an app note (PDF), and you can check out the example code we used.

17 thoughts on “Parts: 1-Wire temperature sensor (DS1822)”

These sensors are great and there’s lots of software for using them. Even better, Dallas/Maxim will send out “samples” for free – two each of up to four parts. Then all you need to do is wire them up. Don’t forget the USB adaptor (DS9490R).

What makes these things a giant PITA is that if you install 2 on the line, now you have to know their serial numbers in order to read them. If you are building a simple one off project, this is not a big deal, if you are building something that you intend to manufacture, now things are a world of hurt. you need a bigger processor and nvram so that upon power up it can read all 1wire serial numbers and ask you, “is this #1? is this #2?” and so on.

A single device you can use the generic read function. so in a 16 pin pic, you want to read 5 sensors? design it with 5 1wire busses and put 1 device per bus on it.

1wire parts are very cool but as soon as you scale up past 1 part they become a major PITA when dealing with tiny pic processors.

I used this sensor with a pic18f4520 to create an automatic water control system. I used this to monitor the temperature of the water, and two stepper motors to adjust the water flow to keep the temperature at whatever the user put in.

malvolio, I’d suspect that it would not be interesting to duplicate this project on the AVR, if you’ve just developed it for the PIC. Someone else would have to want to do the AVR project for fun.
-Cheers

A onewire network running 16 DS18B20 (DS1822 equiv) is monitoring my water lines for freezing and via X10 turning on the heat tapes. Network distance is over 70 feet. Runs on Aruduino and Sanguino. Full CRC checking is in use. One serious note: See Dallas app note 4255 which tells you to use 1500 ohms instead of 4700 for the pullup resistor with these devices because they need 1.5 ma during conversion. Made whole network become totally reliable. Addresses are hardcoded into the software.

Yep, the one-wire addressing scheme is stupid for real production. I have no idea how it’s actually supposed to be used without reading each device in the factory and hardcoding it. Even if you get them to enumerate themselves, how are you to know which one is where?

However, for a personal project, the ability to chain a ton of them on a 2-wire bus is pretty useful. And the bus pirate will make collecting the rom ids easy (to hardcode into my pic – heh)

scotty, your project is a perfect example of how to use these things. how did you deal with the romid issue? did you hard code it too?

There is enough code space in the Arduino, and 4X more in the Sanguino, to incorporate the identify, store, and assign routine needed to introduce new devices in the field. In manufacturing engineering, which I’ve many years experience with, several methods come to mind immediately and the problem is more of which to select for efficiency rather than if it can be done well enough to bother, even with a PIC. As for my single prototype two separate programs were created. One obtains the romid that is then hardcoded into the other program by hand. Debugging additonal code for discovery of just 16 devices would not have been efficient. There is enough space for it though. Oh yes.. I’m running the network in parasitic power mode, hence the need for the 1500 ohms. Powered would do fine with the 4700 ohm.

Hello!
As Scotty has noted it will work doing things that we people types do not want to consider.

And from personal experience, using the devices does require knowing each one’s serial number, point of fact, that is what happens when you order a batch, you get completely unique serial numbers, and are expected to know what ones you are using.

In addition the adapter used by the computer host during testing also has one installed to add to the confusing.

To all those above concerned about access to multiple devices: it is perfectly possible to connect whatever number of those on the same bus and access them individually without knowing their IDs up front. It uses a very simple and smart detection mechanism. I ordered one and looking forward to it :)