White Paper 5: Using 1-Wire APIs for Data Sheet Commands

Abstract

All 1-Wire^® device data sheets describe two sets of commands. The first set referred to as ROM Function Commands are used for device identification and selection. The second set is often called Memory Function Commands but may contain other non-memory operations. A ROM Function Command must be completed each time a device is selected to get it ready for a Memory Function Command. The 1-Wire APIs created by Analog Devices utilize these commands to do operations with 1-Wire devices. Sometimes it is not always obvious what commands are being named. This document maps the commands presented in the data sheets to the API functions. Where specific API functions are not available, a technique is presented to translate the commands using the generic communications API functions.

Introduction

All 1-Wire device data sheets describe two sets of commands. The first set referred to as ROM Function Commands are used for device identification and selection. The second set is often called Memory Function Commands but may contain other non-memory operations. A ROM Function Command must be completed each time a device is selected to get it ready for a Memory Function Command. The 1-Wire APIs created by Analog Devices utilize these commands to do operations with 1-Wire devices. Sometimes it is not always obvious what commands are being named. This document maps the commands presented in the data sheets to the API functions. Where specific API functions are not available, a technique is presented to translate the commands using the generic communications API functions.

See application note 155, "1-Wire Software Resource Guide Device Description" for a detailed description of the various APIs including the abbreviations discussed in this document (PD, TMEX, OWAPI, OWCOM). (Special terms, commands, or codes are shown in italics for clarity.)

ROM Function Commands

The ROM Function Commands are used to either discover the ROM ID or use the ROM ID to select a device in various modes. The ROM ID is a unique 64-bit number that contains a family code, serialization field, and a cyclic redundancy check (CRC). The 1-Wire master transmits one of these functions after it has issued a 1-Wire reset and received a presence.

The Read ROM command reads the ROM ID directly. It can only be used on a 1-Wire network where there is only one device attached. With networks of more than one device, the ROM ID must be discovered with the Search ROM command. This search algorithm is discussed in detail in application note 187, "1-Wire Search Algorithm." The Conditional Search ROM command works the same as Search ROM except only 1-Wire devices that are in some kind of alarm state respond. This is used to discover only devices that need attention.

The Skip ROM command is used to select all devices regardless of ROM ID. This could be used to gang program memory devices provided there is sufficient energy. The Overdrive Skip command is similar but it not only selects all devices it also puts those devices at the Overdrive communication rate. This is most often used to move all capable 1-Wire devices to Overdrive speed. After the devices are communicating in Overdrive, the ROM IDs can be discovered using the conventional Search ROM sequence.

The Match ROM command selects a specific device by broadcasting a selected ROM ID. The Overdrive Match is similar but it also switches the device to the Overdrive communication speed. The Resume Command is used to reselect the last device that was selected. This is a shortcut command when repeatedly accessing the same device.

Table 1 maps the APIs to a particular ROM Function Command. Note that since the various 1-Wire APIs are designed with the idea of multiple 1-Wire devices on a network, the commands that require or are most useful in a single device network are not supported directly. However any command can be constructed using the basic communication functions as discussed later in Custom Commands.

Memory Function Commands

The Memory Function Commands vary slightly from one device type to another. However, their primary objective is the same, which is to read and write the memory areas of the device. To deal with these diverse command structures, the 1-Wire APIs were constructed to abstract out these differences. For example, a generic write memory API may use a Write Scratchpad, Read Scratchpad, and Copy Scatchpad sequence or it may use an EPROM Write Memory sequence. To the API user, it looks the same.

There are three levels of memory commands in most of the APIs. The first allows reading and writing to the memory without any structure (raw). The second uses a packet structure called the Universal Data Packet (UDP). The third type combines multiple UDP structures into a file structure. See application note 114, "1-Wire File Structure" for a description of the UDP and file structure. Table 2 maps the APIs to the three types of memory operations.

Some of the commands that are included under Memory Function Commands in data sheets are actually custom device commands. See the following section for a guide on how to deal with these commands.

Custom Commands

Almost all of the custom commands can be derived by first selecting the device with a Match ROM equivalent API and then send a bidirectional block of data to the 1-Wire network. The block is constructed by putting in the write commands that are required into the block and putting in FF (hex) bytes into the block that are reads from the 1-Wire device. For example, the DS1922L has a memory-mapped real-time clock (RTC) register that can be accessed with the Read Memory command. Figure 1 is taken from the DS1922L's data sheet.

As the DS1922L data sheet specifies, the RTC register is five bytes long starting at address 0219(hex). The memory command flow as seen in Figure 1 starts after the device has been selected with a ROM Function Command like Match ROM.

Table 3 lists the sixteen bytes that make up a block of bidirectional data to be sent to the 1-Wire bus based on the flow chart. While this data could be sent a byte at a time, it is often more efficient to create a block and send it all at once.

Figure 2 is a 'C' example written for the 1-Wire Public Domain (PD) API that uses the block outlined in Table 3 to read the RTC of the DS1922L.

Figure 2. PD Example Reading RTC

   unsigned char datablock[] = { 0xF0,0x19,0x02,0xFF,0xFF,0xFF,0xFF,
  0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF };
   int portnum=0;

   // select the current device (Match ROM)
   if (owAccess(portnum))
   {
         // send the read memory command and address, receive the RTC value
         if (owBlock(portnum, 1, datablock, 16))
         {
         // RTC is now in bytes 11-15 of datablock
         ...
         }
   }

Table 4 shows the bidirectional block commands for each of the APIs. For completeness, the single byte and bit commands are also included.

By looking at the data sheet for each 1-Wire device type, it is possible to do any of the functions by constructing the appropriate block and using the generic 1-Wire I/O functions. Some of the 1-Wire devices require special power delivery constraints or program pulses that are addressed by the special API functions in Table 5.