1 Wire App-note

8/3/2019 1 Wire App-note

1/36

APPLICATION NOTE 148

Guidelines for Reliable Long Line 1-Wire

NetworksAbstract: The 1-Wire protocol was originally designed to facilitate communication with nearbydevices on a short connection. 1-Wire was also a way to add auxiliary memory on a single

microprocessor port pin. Methods were later developed to extend the 1-Wire protocol to network

applications well beyond the size of a circuit board. This document discusses various aspects of1-Wire networks and provides design guidelines for their reliable operation. Several appendices

address fine-tuning the 1-Wire bus interface and illustrate 1-Wire communication waveforms in

various conditions.

Introduction

The 1-Wire protocol was originally designed for communication with nearby devices on a short

connection, such as adding auxiliary memory on a single microprocessor port pin. As the use of1-Wire devices increased, methods were developed to extend the 1-Wire protocol to networked

applications well beyond the size of a circuit board. A 1-Wire network is a complex arrangement

of 1-Wire devices, communication lines, and connections. Every 1-Wire network is different,often both in topology (layout) and hardware.

A proper match among network components (i.e., master, network cabling, and 1-Wire slave

devices, "slaves") is the precondition for reliable 1-Wire operation. When bus masters areimproperly designed or implemented, or when masters intended for short-line use are pressed

into service with greatly extended communication lines, then satisfactory performance cannotalways be expected.

This application note presents the results of a project to characterize the operation of 1-Wire

networks of various forms, sizes, and populations. It also provides working parameters forreliable network operation. Some of the aspects discussed here are not critical in short-line

applications, e.g. networks of less than 1 meter. For a discussion of embedded 1-Wire

applications, refer to application note 4206, "Choosing the Right 1-Wire Master for Embedded

Applications." Appendices A through D address fine-tuning the 1-Wire bus interface andillustrate 1-Wire communication waveforms in various conditions.

Network Description

The scope of this document is limited to 1-Wire networks that use Category 5, twisted-pair

copper wire and have 5V bus power supplied by the master. (Most 1-Wire slaves will operate atlower bus voltages, but large networks often have too much loss to perform well under low-

voltage conditions.)


2/36

This document does not address the requirements for programming EPROM-type slave devices.

It is generally not recommended that EPROM programming be performed at any appreciable

distance from the master-end interface. This article also does not discuss overdrive speedoperation of 1-Wire devices. The overdrive speed is intended for use only on very short

connections and is never suitable for use in 1-Wired networks.

There are countless combinations of wire types and topologies that can be used with 1-Wire

devices. This application note attempts only to describe the most general and typical applications

associated with the 1-Wire network. Operating a 1-Wire network beyond the limits ordisregarding advice given in this document may result in unreliable network performance.

1-Wire Network Terminology

Two simple terms describe measurements that are critical to 1-Wire network performance: radius

and weight.

The radius of a network is the wire distance from the master end to the most distant slave.It is measured in meters.

The weight of a network is the total amount of connected wire in the network. It is alsomeasured in meters.

For example, a star network configuration with three branches of 10m, 20m, and 30m would

have a radius of 30m (i.e., the distance from 1-Wire master to the furthest slave) and a weight of

60m (i.e., the total length of wire in the network, 10m + 20m + 30m).

In general, the weight of the network limits the rise time on the cable, while the radius

establishes the timing of the slowest signal reflections.

Slave Device Weight

The weight that can be supported in a network is limited, and depends on the driver (1-Wiremaster interface). In simple terms, the weight can consist of many slaves on very little cable, or

very few slaves on a lot of cable.

Slave devices (iButtons and other 1-Wire devices) add equivalent weight to a network. Each

device adds weight similar to that of a small length of wire, so devices can be rated in terms of

their equivalent wire weight. Consequently, when a network is designed, the weight of the

devices must be considered. A slave in iButton form usually contributes more weight than aslave packaged as a soldered-in component. iButtons add a weight of about 1m, and non-iButton

slaves add a weight of about 0.5m. Consider the implications of this for an example network.

Connecting 100 iButton devices increases the total network weight by 100m, which in turn,requires the total amount of wire to be reduced by 100m to keep the network functioning.

Circuit-board traces, connectors, and ESD protection devices also add weight to a network.


3/36

Although weight is influenced by many factors, capacitance is clearly the largest single

contributor. As a general rule, the weight contribution of ESD circuits and PC-board traces can

be related to their capacitance by a factor of about 24pF/m. A circuit-board trace or device thatexhibits 24pF across the 1-Wire bus will add a weight of about 0.5m.

1-Wire Network Topologies

Although 1-Wire networks are often quite "free form" in structure, they usually fit into a few

generalized categories, based on the distribution of the 1-Wire slaves and the organization of theinterconnecting wires.

1. Linear topology. The 1-Wire bus is a single pair, starting from the master and extendingto the farthest slave device. Other slaves are attached to the 1-Wire bus with insignificant

(< 3m) branches or "stubs."

2. Stubbed topology. The 1-Wire bus is a single main line, starting at the master andextending to the farthest slave. Other slaves are attached to the main line through

branches or stubs 3m or more in length.

3. Star topology: The 1-Wire bus is split at or near the master end and extends in multiplebranches of varying lengths. There are slave devices along, or at the ends of, the

branches.


4/36

When different topologies are intermixed, it becomes much more difficult to determine the

effective limitations for the network. As a rule, the designer should apply the most conservative

of the criteria in these cases.

Precautions with Star Topologies

Testing has shown that unswitched star-type network topologies (i.e., those with several

branches diverging at the master) are the most difficult to make reliable. The junction of various

branches presents highly mismatched impedances; reflections from the end of one branch cantravel distances equal to nearly the weight of the network (rather than the radius) and cause data

errors. For this reason, the unswitched star topology is not recommended, and no guarantees can

be made about its performance.

Switched Networks

To allow networks to grow in complexity without growing in weight and radius, the network isdivided into sections that are electronically switched on one at a time. Using low-impedance,

single-supply analog switches, the network canphysically resemble one topology, but

electrically resemble another. This means that a star configuration with a switch on each branchwould actually resemble a lineartopology. In this case, only one branch is active at any time.


5/36

The example above appears like a star topology network with a radius of 150m and a weight of

450m. However, when each switched path is considered individually, the network is actually alinear topology and the weight is only 150m.

As a rule, our discussion of nonswitched networks can be applied to each segment of a switchednetwork.

1-Wire Network Limitations

Several factors determine the maximum radius and weight of a network. Some of these factors

can be controlled and some cannot.

The master-end interface greatly influences the allowable size of a 1-Wire network. The interface

must provide sufficient drive current to overcome the weight of the cable and slaves. It must also

generate the 1-Wire waveform with timings that are within specification and optimized for the

charge and discharge times of the network. Finally, the interface must provide a suitableimpedance match to the network, so that signals are not reflected back down the line to interfere

with other network slaves.

When the network is small, very simple master-end interfaces are acceptable. Capacitance is low,

reflected energies arrive too soon to pose a problem, and cable losses are minimal. A simpleactive (FET) pulldown and passive (resistor) pullup are sufficient. But, when lines lengthen and

more devices are connected, complex forces come into play. Now the master-end interface must

be able to handle them all.

The network radius is limited by several factors: the timing of waveform reflections, the time

delay produced by the cable, the resistance of the cable, and the degradation of signal levels. Thetypical signal propagation speed in a phone cable is about 2/3 of the speed of light. In a 750mcable, for example, the roundtrip delay is 7.5s. If the master pulls the line low for 7.5s to start

a read time slot, then the end of the master's low pulse (i.e., after a roundtrip) coincides with the

instant at which a near-end fast slave may stop pulling the line low. Consequently, the roundtripdelay of such a long cable makes it impossible for the master to communicate with that near-end

slave.

Network weight is limited by the ability of the cable to be charged and discharged quicklyenough to satisfy the 1-Wire protocol. A simple resistor pullup has a weight limitation of about

200m. Sophisticated 1-Wire master designs have overcome this limitation by using active

pullups, that provide higher currents under logic control and have extended the maximumsupportable weight to over 500m. See application note 244, "Advanced 1-Wire Network Driver."

Parasite Powering Issues

The 1-Wire waveform must not only be sufficient for communication, but also provide operating

power for the slaves. Each slave "robs" power from the bus when the voltage on the bus is


6/36

greater than the voltage on its internal energy storage capacitor. When the weight of the network

becomes excessive, the current delivered by the master may not be sufficient to maintain

operating voltage in the slaves.

The worst-case scenario forparasite poweris a very long sequence of zero bits issued by the

master. When this occurs, the line spends most of its time in the low state, and there is very littleopportunity to recharge the slaves. If the bus reaches a sufficient voltage during the recovery

time between bits and if the recovery time is long enough, there is no problem. As the internal

operating voltage in each slave drops, the slave's ability to drive the bus to make zero bits isreduced, and the timing of the slave changes. Eventually, when the parasite voltage drops below

a critical level, the slave enters a reset state and stops responding. Then, when the slave again

receives sufficient operating voltage, it will issue a presence pulse and may corrupt other bus

activity in doing so. When a network has insufficient energy to maintain operating power in theslaves, failures will be data-dependent and intermittent.

Distributed Impedance Matching

The strengths of 1-Wire bus designs are minimalism and simplicity (ultimately, also resulting in

low cost). Other than the slaves themselves, the use of components distributed out into thenetwork has always been avoided.

When a stub is connected to a 1-Wire bus, there is an impedance mismatch at the branch point.Reflections from the end of the stub return to the main trunk, delayed only by the time it takes

for the signal to travel the length of the stub. These reflections can then cause problems for other

slaves on the network. A resistor in series with the stub will reduce the severity of the mismatch

and the amplitude of the reflected energy. That resistor mitigates adverse effects from stub-generated reflections on the main trunk.

The most successful implementation of this concept uses 150 resistors at each point where a

stub is connected to the main trunk. This value reduces the mismatch at the connection point byabout 20%, and attenuates the resulting stub reflections by about 40%. However, the added

resistance also degrades noise immunity by about 80%, so caution must be observed. Tests have

also shown good performance using 100 resistor values, which do not degrade noise immunityquite as much.

Note: The DS2480BSerial 1-Wire Line Driver, the DS2490USB to 1-Wire Bridge, and the

DS2482 device family are 1-Wire masters with an active pullup that is adversely affected by this


7/36

added resistance. The above method is not compatible with these 1-Wire drivers. Successful

application of the distributed resistor method has always been done using a custom master end

driver with an elevated data-input threshold.

Master-End Interface Devices

There are a wide variety of methods to interface 1-Wire networks to microcontrollers and

personal computers. Each 1-Wire master is, moreover, designed with a different intended use,

and is not always reliable when pressed into alternative service. Finally, the master-end hardwareis a critical factor in determining the limitations of a 1-Wire network design. Simple hardware

interfaces intended for short wires and nearby iButton probes do not perform well when

connected to larger networks and complex wiring schemes. Sophisticated drivers intended for

very long lines can perform poorly when used with short- and medium-length networks.

The master-end hardware interfaces in most common use today are listed below:

1. Microprocessor port-pin attachments2. Microcontroller with built-in 1-Wire master3. Synthesizable 1-Wire bus master (DS1WM)4. Serial-interface protocol conversions (DS2480B, DS2482-100, DS2482-800, DS2490)

These interfaces are discussed in application note 4206 noted above.

For long line applications, modifications are necessary. Appendix A shows a variant of the

microprocessor port-pin attachments, i e., a FET driver with slew-rate control and a 1k pullupresistor. A radius of up to 200m and a weight of up to 200m can be reliably supported using this

interface.

The DS2480B is designed for efficient short to medium line-length operation. A simple R-C

circuit applied between the DS2480B and the network will greatly improve medium-length

network performance and reliability. (See Appendix B.) Using the filter, this master can reliablysupport a network with a radius or weight of up to 200m. It is important to note that the

DS2480B interface device has variable timings that can also be used to improve 1-Wire network

reliability and performance. These timings are set to optimum values by some software (like the1-Wire Drivers for Windows), but may not be adjusted by all software. (See Appendix C and

application note 4104, "Understanding and Configuring the 1-Wire Timing of the DS2480B.")

The recommended circuit for long line applications is the microcontroller with advanced bus

interface, as discussed in application note 244 discussed above. This master-end interface circuituses impedance matching (of both the high and low drivers) and "intelligent" (software-

controlled) active pullup. The pullup is turned on whenever the 1-Wire protocol determines thatthe bus should be at a high level, and during reads after the bus has been sampled and found to

be at a high level. This interface works with large and small 1-Wire networks equally well, and

can reliably operate a network with high weight and radius values up to 500m.


8/36

What Makes a Reliable 1-Wire Network?

When a 1-Wire network fails, the failure often manifests itself as a mysterious "loss" of a devicewhen the searching algorithm is performed. See application note 187, "1-Wire Search

Algorithm" for more information. Devices that are physically present can appear and disappear

in the search results. Sometimes, a seemingly minor change in the network or devices will have aradical effect on the outcome of device searches. Why does this happen?

Of all the activity that occurs on a 1-Wire bus, device searches are the most complex and the

most difficult to perform in the presence of bus problems. Searches are the only time (with theexception of presence pulses) when all slaves may drive the bus low at the same time. This

means that bus conditions during searches are much different from normal communications with

a single selected slave. If any of many slaves misses an edge or fails to discriminate a pulse, thenit will become unsynchronized with the search algorithm and will cause errors in subsequent bits

of the search. This means that the search will fail if: a bus problem causes a glitch on the rising

edge of the waveform; the waveform fails to reach a valid low level; or any device is starved for

power during the search. Most search algorithms handle a search failure by terminating thesearch algorithm and starting over, at which point yet undiscovered slaves will seem to drop

from the search. Despite the fact that the failure occurred in one bit of one slave device, any

number of slaves can then be affected.

Searching algorithms typically assume that devices may be missed due to noise. In networks

with touch-contact iButtons, the arrival of new iButtons to the network can introduce momentaryshort circuits in the form of a presence pulse from the newly arrived device. Depending on the

timing of these events, those presence pulses will interfere with search activity. The search

algorithms manage such problems by removing slaves from their list of discovered slaves only

after the devices have been observed missing for a "debounce" period of time.

The causes of search failures vary widely. Among the most common are starvation of parasite

power (with large radius, heavy networks); reflections on waveform edges (with small- andmedium-radius, lightweight networks); and false triggering of the active pullup in the DS2480B-

or DS2490-based interfaces due to ringing in the waveform's falling edges. If enabled, the active

pullup of the DS2482 is also susceptible to false triggering.

Search failures often appear to be highly sensitive to minor variations in the network; the slaves

connected on the network; or "the phase of the moon," as some frustrated designers have beenknown to say. This sensitivity is because the network under scrutiny is in a borderline state, and

very small network variations can cause searches to succeed or fail. Simply put, a network that

appears to be successful because all the devices are reliably found in the search algorithm, canactually be near failure. Minor degradation can suddenly produce seemingly catastrophicfailuresall it takes is one faulty bit to make a search stop, and parts disappear. Consequently, it

is critical that the user adhere to published specifications and guidelines to assure reliable

networks with good safety margins and tolerance of variations in cable, devices, andconnections.


9/36

A network that reliably and consistently performs searches can generally perform any other 1-

Wire function reliably.

Incorrect 1-Wire Timing

When software (firmware) is used to generate 1-Wire waveforms (sometimes called "bit-banging" the waveform), it is easy to make mistakes that do not become apparent immediately.

By far the most common mistake made in programming the 1-Wire master is sampling data fromslaves too late after the leading (falling) edge of the time slot. Slaves can vary in their timing

over a wide range just as temperature and voltage vary. Slaves can also change from batch-to-

batch due to process variations. A design in which the waveform is sampled at 30s might pass

lab tests and even go into production, committing the improper timing to shipped products.Later, when batch or network conditions change and the slaves move from 32s to 29s, this

master-end interface fails. It is therefore critical that waveform parameters be verified by the

specifications, despite seemingly perfect system operations in laboratory environments.

Conclusions

As with any electronic component, supporting electronic systems must meet the device

specifications under all conditions of use to assure reliable operation. A proper match amongnetwork components (i.e., master, network cabling, and 1-Wire slaves) is essential for reliable 1-

Wire operation.

Appendix A. Improved CPU Bus Interface

Appendix B. R-C Filter Helps DS2480B Interfaces on Shortto Medium Networks


10/36

This simple R-C filter improves DS2480B operation on medium-length lines with weights up to200m. This filter should be used on networks between 10m and 100m when using DS2480B-

based master-end interfaces. Note that the 4700pF capacitor is equivalent to a weight of 100m, a

significant load for the DS2480B. Depending on the weight of the other components in thenetwork, it may be necessary to reduce the capacitor to 470pF. Note also that the DS2480B is

used inside the DS9097U Serial Adapter, but can also be used as an embedded device.

Appendix C. Optimized DS2480B Timings

The DS2480B Serial-to-1-Wire Converter has default 1-Wire timings optimized for small

networks. These settings will not always perform well with medium or larger networks.

The timing and slew-rate settings in the DS2480B can be adjusted under software control.

Indeed, the 1-Wire Drivers for Windows adjust these values as a matter of practice when usedwith this interface. Programmers should be aware that DS2480B interfaces should always be

placed in "flex mode" and timing values adjusted for reliable performance. (See the DS2480B

data sheet for detailed information on flex-mode settings.)

Settings that can be adjusted in the DS2480B include the following:

Pulldown Slew-Rate ControlThis is the rate at which the bus is pulled from a high to a low level. Excessively fast fall

times (high slew rates) cause ringing, which interferes with valid data waveforms.

Excessively slow rise and fall times may not meet timing requirements, and may exposethe transition period to the effects of noise and reflections

Write-One Low TimeThis is the length of the low-going pulse that begins each time slot. If this pulse is toonarrow, the master end of a long line may never reach valid low levels before the pulse is

ended.

Data Sample Offset/Recovery TimeThis parameter defines when the data from slaves will be sampled. If this parameter is toosmall, the line may not have sufficient time to rise to a valid high level before the sample

occurs. If this time is too long, then slaves operating near the fast end of their range maybe misread. This parameter also defines the time between bits, during which time the

parasite capacitors in the slaves must recharge.

Testing with long and short bus lines has shown that the optimum timings for all networks are as

follows:


11/36

Pulldown Slew Rate: 1.37V/s Write One Low Time: 11s Data Sample Offset/Recovery: 10s

These timings provide the latest possible sample time (21s*) and the longest possible recovery

time (10s) along with a well-controlled slew rate. According to application note 4104, a slightlyfaster timing with a Write-One Low Time of 8s and a Data Sample Offset/Recovery of 9s is

an alternative to consider, because these values accommodate 1-Wire slaves in the speed range

of 15s to 54s.

*These timings apply only to networks where the pullup voltage is between 4.5V and 5.5V.

Appendix D. Waveform Examples

The following oscilloscope images depict various types of 1-Wire network waveforms in

different situations. Please refer to the text and reference materials for detailed explanations of

these waveforms and effects.

This image shows a bus reset and presence-detect sequence. More importantly, it shows the

difference between a slew-rate-controlled edge (master) and an edge without slew-rate control

(slave). The falling edge created by the master is clean and does not undershoot or ring. The

falling edge created by the slave causes ringing and undershoot on the bus.


12/36

This image also shows a bus reset/presence-detect sequence. The master pulls the bus low for480s; all the devices on the bus recognize this as a reset operation. Slaves respond to a bus reset

by issuing a presence pulse. Multiple slaves generate their presence pulses during the same

period, and the pulses overlap to form a single pulse. (Note that the time base is 200s per

division.)

This image shows a Read One or Write One time slot. The master pulls the bus low for about

10s and then releases it. Note the slew-rate-controlled fall time. The time slot lasts for about

70s, after which another time slot occurs. Note that the time base is changed to 10s per

division.


13/36

This image shows a Write Zero time slot. The master pulls the bus low for 60s and thenreleases it for about 10s before another time slot begins.

This image shows a Read Zero time slot. The master pulls the bus low for about 10s and then

releases it. However, a slave is returning a zero bit by holding the bus low for a longer time. The

slave's time base can vary between 15s and 60s.


14/36

This image shows the effect of excessive weight when using a master with resistor pullup only.The network radius in this example is 300m, and there are 30 devices at the far end of the

network. The reflections from the end of the network can be clearly seen, as can the very slow

rise time. Note that although this is a Read One time slot, the data level at the sample time is

borderline and could be misread by the master.

When rise time is slow, the recovery time (the period between time slots) may not be long

enough to allow the bus to reach a voltage level sufficient to recharge the slaves. In the image

above, the slave's internal operating voltage has become dangerously low. Slaves may reset due

to power starvation, especially during long strings of Write Zero time slots.


15/36

A more advanced network bus driver uses impedance matching and active pullup to overcomethe added weight of the long network and slave devices. This waveform shows a Read One or

Write One time slot and the action of the active pullup.

Here is the same active pullup operation in a Read Zero time slot.


16/36

During bus-reset sequences, the active pullup is used to overcome the network weight after thereset pulse, and then again after the end of the presence pulse(s). In this image, the overlap of

near- and far-end presence pulses can be observed. The added resistance of the cable between the

master and the far-end slave causes the low level to be higher for far-end devices than for near-

end devices.

This image shows the resulting chaos that occurs when the active pullup is falsely triggered by

reflections on the cable due to stubs and branches. This is a Read Zero time slot, although the

reflection has caused the active pullup to activate and collide with the pulldown in the slave

device.

Note: All the preceding waveforms were captured at the master end of the network. Waveforms


17/36

viewed at any other point in the network must use a differential probe so that the oscilloscope

ground does not affect the 1-Wire bus.

More Information

Application note 187, "1-Wire Search Algorithm"

Application note 244, "Advanced 1-Wire Network Driver"

Application note 3829, "Determining the Recovery Time for Multiple-Slave 1-Wire Networks"

Application note 3925, "1-Wire Extended Network Standard"

Application note 4104, "Understanding and Configuring the 1-Wire Timing of the DS2480B"

Application note 4206, "Choosing the Right 1-Wire Master for Embedded Applications"

1-Wire is a registered trademark of Maxim Integrated Products, Inc.

iButton is a registered trademark of Maxim Integrated Products, Inc.

Java is a registered trademark and registered service mark of Oracle and/or its affiliates.

Windows is a registered trademark and registered service mark of Microsoft Corporation.


18/36

APPLICATION NOTE 187

1-Wire Search AlgorithmAbstract: Maxim's 1-Wire devices each have a 64-bit unique registration number in read-only-memory

(ROM) that is used to address them individually by a 1-Wire master in a 1-Wire network. If the ROM

numbers of the slave devices on the 1-Wire network are not known, then using a search algorithm can

discover them. This document explains the search algorithm in detail and provides an example

implementation for rapid integration. This algorithm is valid for all current and future devices that

feature a 1-Wire interface.

Introduction

Maxim's 1-Wire devices each have a 64-bit unique registration number in read-only-memory (ROM) thatis used to address them individually by a 1-Wire master in a 1-Wire network. If the ROM numbers of the

slave devices on the 1-Wire network are not known, then they can be discovered by using a search

algorithm. This document explains the search algorithm in detail and provides an example

implementation for rapid integration. This algorithm is valid for all current and future devices that

feature a 1-Wire interface.

Figure 1. 64-Bit Unique ROM 'Registration' Number.

Search Algorithm

The search algorithm is a binary tree search where branches are followed until a device ROM number, or

leaf, is found. Subsequent searches then take the other branch paths until all of the leaves present are

discovered.

The search algorithm begins with the devices on the 1-Wire being reset using the reset and presence

pulse sequence. If this is successful then the 1-byte search command is sent. The search command

readies the 1-Wire devices to begin the search.

There are two types of search commands. The normal search command (F0 hex) will perform a search

with all devices participating. The alarm or conditional search command (EC hex) will perform a search

with only the devices that are in some sort of alarm state. This reduces the search pool to quickly

respond to devices that need attention.


19/36

Following the search command, the actual search begins with all of the participating devices

simultaneously sending the first bit (least significant) in their ROM number (also called registration

number). (See Figure 1.) As with all 1-Wire communication, the 1-Wire master starts every bit whether it

is data to be read or written to the slave devices. Due to the characteristics of the 1-Wire, when all

devices respond at the same time, the result will be a logical AND of the bits sent. After the devices send

the first bit of their ROM number, the master initiates the next bit and the devices then send the

complement of the first bit. From these two bits, information can be derived about the first bit in the

ROM numbers of the participating devices. (See Table 1.)

Table 1. Bit Search Information

Bit

(true)

Bit

(complement)Information Known

0 0 There are both 0s and 1s in the current bit position of the participating ROMnumbers. This is a discrepancy.

0 1 There are only 0s in the bit of the participating ROM numbers.

1 0 There are only 1s in the bit of the participating ROM numbers.

1 1 No devices participating in search.

According to the search algorithm, the 1-Wire master must then send a bit back to the participating

devices. If the participating device has that bit value, it continues participating. If it does not have the bit

value, it goes into a wait state until the next 1-Wire reset is detected. This 'read two bits' and 'write one

bit' pattern is then repeated for the remaining 63 bits of the ROM number (see Table 2). In this way the

search algorithm forces all but one device to go into this wait state. At the end of one pass, the ROM

number of this last device is known. On subsequent passes of the search, a different path (or branch) is

taken to find the other device ROM numbers. Note that this document refers to the bit position in the

ROM number as bit 1 (least significant) to bit 64 (most significant). This convention was used instead of

bit 0 to bit 63 for convenience to allow initialization of discrepancy counters to 0 for later comparisons.

Table 2. 1-Wire Master and Slave Search Sequence

Master Slave

1-Wire reset stimulus Produce presence pulse

Write search command Each slave readies for search.


20/36

(normal or alarm)

Read 'AND' of bit 1 Each slave sends bit 1 of its ROM number.

Read 'AND' of complement bit

1Each slave sends complement bit 1 of its ROM number.

Write bit 1 direction

(according to algorithm)

Each slave receives the bit written by master, if bit read is not the same

as bit 1 of its ROM number then go into a wait state.

Read 'AND' of bit 64 Each slave sends bit 64 of its ROM number.

Read 'AND' of complement bit

64Each slave sends complement bit 64 of its ROM number.

Write bit 64 direction

(according to algorithm)

Each slave receives the bit written by master, if bit read is not the same

as bit 64 of its ROM number then go into a wait state.

On examination of Table 1, it is obvious that if all of the participating devices have the same value in a

bit position then there is only one choice for the branch path to be taken. The condition where no

devices are participating is an atypical situation that may arise if the device being discovered is removed

from the 1- Wire during the search. If this situation arises then the search should be terminated and a

new search could be done starting with a 1-Wire reset. The condition where there are both 0s and 1s in

the bit position is called a discrepancy and is the key to finding devices in the subsequent searches. The

search algorithm specifies that on the first pass, when there is a discrepancy (bit/complement = 0/0),

the '0' path is taken. Note that this is arbitrary for this particular algorithm. Another algorithm could be

devised to use the '1' path first. The bit position for the last discrepancy is recorded for use in the next

search. Table 3 describes the paths that are taken on subsequent searches when a discrepancy occurs.

Table 3. Search Path Direction

Search Bit Position vs Last DiscrepancyPath Taken

= take the '1' path

take the '0' path

The search algorithm also keeps track of the last discrepancy that occurs within the first eight bits of the

algorithm. The first eight bits of the 64-bit registration number is a family code. As a result, the devices

discovered during the search are grouped into family types. The last discrepancy within that family code


21/36

can be used to selectively skip whole groups of 1-Wire devices. See the description ofADVANCED

SEARCH VARIATIONS for doing selective searches. The 64-bit ROM number also contains an 8-bit cyclic-

redundancy-check (CRC). This CRC value is verified to ensure that only correct ROM numbers are

discovered. See Figure 1 for the layout of the ROM number.

The DS2480B Serial to 1-Wire Line Driver performs some of this same search algorithm in hardware.

Please see the DS2480B data sheet and Application Note 192, Using the DS2480B Serial 1-Wire Line

Driverfor details. The DS2490 USB to 1-Wire Bridge performs the entire search in hardware.

Figure 2 shows a flow chart of the search sequence. Note the Reference side bar that explains the terms

used in the flow chart. These terms are also used in the source code appendix to this document.


22/36

Figure 2. Search Flow.


23/36

Figure 2. Search Flow part II.

There are two basic types of operations that can be performed by using the search algorithm by

manipulating the LastDiscrepancy, LastFamilyDiscrepancy, LastDeviceFlag, and ROM_NO register values(see Table 4). These operations concern basic discovery of the ROM numbers of 1-Wire devices.

First

The 'FIRST' operation is to search on the 1-Wire for the first device. This is performed by setting

LastDiscrepancy, LastFamilyDiscrepancy, and LastDeviceFlag to zero and then doing the search. The

resulting ROM number can then be read from the ROM_NO register. If no devices are present on the 1-

Wire the reset sequence will not detect a presence and the search is aborted.

Next

The 'NEXT' operation is to search on the 1-Wire for the next device. This search is usually performed

after a 'FIRST' operation or another 'NEXT' operation. It is performed by leaving the state unchanged

from the previous search and performing another search. The resulting ROM number can then be read

from the ROM_NO register. If the previous search was the last device on the 1-Wire then the result will

be FALSE and the condition will be set to execute a 'FIRST' with the next call of the search algorithm.

Figure 3 (a, b, c) goes through a simple search example with three devices. For illustration, this example

assumes devices with a 2-bit ROM number only.


24/36


25/36


26/36

Figure 3. Search Example.

Advanced Search Variations


27/36

There are three advanced search variations using the same state information, namely LastDiscrepancy,

LastFamilyDiscrepancy, LastDeviceFlag, and ROM_NO. These variations allow specific family types to be

targeted or skipped and device present verification (see Table 4).

Verify

The 'VERIFY' operation verifies if a device with a known ROM number is currently connected to the 1-Wire. It is accomplished by supplying the ROM number and doing a targeted search on that number to

verify it is present. First, set the ROM_NO register to the known ROM number. Then set the

LastDiscrepancy to 64 (40 hex) and the LastDeviceFlag to 0. Perform the search operation and then read

the ROM_NO result. If the search was successful and the ROM_NO remains the ROM number that was

being searched for, then the device is currently on the 1-Wire.

Target Setup

The 'TARGET SETUP' operation is a way to preset the search state to first find a particular family type.

Each 1-Wire device has a one bytefamilycode embedded within the ROM number (see Figure 1). This

family code allows the 1-Wire master to know what operations this device is capable of. If there aremultiple devices on the 1-Wire it is common practice to target a search to only the family of devices that

are of interest. To target a particular family, set the desired family code byte into the first byte of the

ROM_NO register and fill the rest of the ROM_NO register with zeros. Then set the LastDiscrepancy to

64 (40 hex) and both LastDeviceFlag and LastFamilyDiscrepancy to 0. When the search algorithm is next

performed the first device of the desired family type will be discovered and placed in the ROM_NO

register. Note that if no devices of the desired family are currently on the 1-Wire, then another type will

be found, so the family code in the resulting ROM_NO must be verified after the search.

Family Skip Setup

The 'FAMILY SKIP SETUP' operation sets the search state to skip all of the devices that have the family

code that was found in the previous search. This operation can only be performed after a search. It is

accomplished by copying the LastFamilyDiscrepancy into the LastDiscrepancy and clearing out the

LastDeviceFlag. The next search will then find devices that come after the current family code. If the

current family code group was the last group in the search then the search will return with the

LastDeviceFlag set.

Table 4. Search Variations State Setup

LastDiscrepancyLastFamily-

DiscrepancyLastDeviceFlag ROM_NO

FIRST 0 0 0 result

NEXT leave unchanged leave unchangedleave

unchangedresult


28/36

VERIFY 64 0 0set with ROM to verify,

check if same after search

TARGET

SETUP64 0 0

set first byte to family code,

set rest to zeros

FAMILY SKIP

SETUP

copy from

LastFamilyDiscrepancy0 0 leave unchanged

Conclusion

The supplied search algorithm allows the discovery of the individually unique ROM numbers from any

given group of 1-Wire devices. This is essential to any multidrop 1-Wire application. With the ROM

numbers in hand, each 1-Wire device can be selected individually for operations. This document alsodiscussed search variations to find or skip particular 1-Wire device types. SeeAppendixfor a 'C' code

example implementation of the search and all of the search variations.

Appendix

Figure 4 shows a 'C' code implementation of the search algorithm along with a function for each search

variation. The FamilySkipSetup and TargetSetup functions do not actually do a search, they just setup

the search registers so that the next 'Next skips or finds the desired type. Note that the low-level 1-Wire

functions are implemented with calls to the TMEX API. These calls are for test purposes and can be

replaced with platform specific calls. See Application Note 155 for a description of the TMEX API and

other 1-Wire APIs.

The TMEX API test implementation of the following code example can be downloaded from the Maxim

website.

// TMEX API TEST BUILD DECLARATIONS#define TMEXUTIL#include "ibtmexcw.h"long session_handle;// END TMEX API TEST BUILD DECLARATIONS

// definitions#define FALSE 0#define TRUE 1

// method declarationsint OWFirst();int OWNext();int OWVerify();void OWTargetSetup(unsigned char family_code);


29/36

void OWFamilySkipSetup();int OWReset();void OWWriteByte(unsigned char byte_value);void OWWriteBit(unsigned char bit_value);unsigned char OWReadBit();int OWSearch();unsigned char docrc8(unsigned char value);

// global search stateunsigned char ROM_NO[8];int LastDiscrepancy;int LastFamilyDiscrepancy;int LastDeviceFlag;unsigned char crc8;

//--------------------------------------------------------------------------// Find the 'first' devices on the 1-Wire bus// Return TRUE : device found, ROM number in ROM_NO buffer// FALSE : no device present//

int OWFirst(){

// reset the search stateLastDiscrepancy = 0;LastDeviceFlag = FALSE;LastFamilyDiscrepancy = 0;

return OWSearch();}

//--------------------------------------------------------------------------// Find the 'next' devices on the 1-Wire bus// Return TRUE : device found, ROM number in ROM_NO buffer// FALSE : device not found, end of search//int OWNext(){

// leave the search state alonereturn OWSearch();

}

//--------------------------------------------------------------------------// Perform the 1-Wire Search Algorithm on the 1-Wire bus using the existing// search state.// Return TRUE : device found, ROM number in ROM_NO buffer// FALSE : device not found, end of search//

int OWSearch(){

int id_bit_number;int last_zero, rom_byte_number, search_result;int id_bit, cmp_id_bit;unsigned char rom_byte_mask, search_direction;

// initialize for searchid_bit_number = 1;last_zero = 0;


30/36

rom_byte_number = 0;rom_byte_mask = 1;search_result = 0;crc8 = 0;

// if the last call was not the last oneif (!LastDeviceFlag){

// 1-Wire resetif (!OWReset()){

// reset the searchLastDiscrepancy = 0;LastDeviceFlag = FALSE;LastFamilyDiscrepancy = 0;return FALSE;

}

// issue the search commandOWWriteByte(0xF0);

// loop to do the searchdo{

// read a bit and its complementid_bit = OWReadBit();cmp_id_bit = OWReadBit();

// check for no devices on 1-wireif ((id_bit == 1) && (cmp_id_bit == 1))

break;else{

// all devices coupled have 0 or 1if (id_bit != cmp_id_bit)

search_direction = id_bit; // bit write value for searchelse{

// if this discrepancy if before the Last Discrepancy// on a previous next then pick the same as last timeif (id_bit_number < LastDiscrepancy)

search_direction = ((ROM_NO[rom_byte_number] &rom_byte_mask) > 0);

else// if equal to last pick 1, if not then pick 0search_direction = (id_bit_number == LastDiscrepancy);

// if 0 was picked then record its position in LastZeroif (search_direction == 0){

last_zero = id_bit_number;

// check for Last discrepancy in familyif (last_zero < 9)

LastFamilyDiscrepancy = last_zero;}

}


31/36

// set or clear the bit in the ROM byte rom_byte_number// with mask rom_byte_maskif (search_direction == 1)ROM_NO[rom_byte_number] |= rom_byte_mask;

elseROM_NO[rom_byte_number] &= ~rom_byte_mask;

// serial number search direction write bitOWWriteBit(search_direction);

// increment the byte counter id_bit_number// and shift the mask rom_byte_maskid_bit_number++;rom_byte_mask


32/36

// Verify the device with the ROM number in ROM_NO buffer is present.// Return TRUE : device verified present// FALSE : device not present//int OWVerify(){

unsigned char rom_backup[8];int i,rslt,ld_backup,ldf_backup,lfd_backup;

// keep a backup copy of the current statefor (i = 0; i < 8; i++)

rom_backup[i] = ROM_NO[i];ld_backup = LastDiscrepancy;ldf_backup = LastDeviceFlag;lfd_backup = LastFamilyDiscrepancy;

// set search to find the same deviceLastDiscrepancy = 64;LastDeviceFlag = FALSE;

if (OWSearch()){

// check if same device foundrslt = TRUE;for (i = 0; i < 8; i++){

if (rom_backup[i] != ROM_NO[i]){

rslt = FALSE;break;

}}

}elserslt = FALSE;

// restore the search statefor (i = 0; i < 8; i++)

ROM_NO[i] = rom_backup[i];LastDiscrepancy = ld_backup;LastDeviceFlag = ldf_backup;LastFamilyDiscrepancy = lfd_backup;

// return the result of the verifyreturn rslt;

}

//--------------------------------------------------------------------------// Setup the search to find the device type 'family_code' on the next call// to OWNext() if it is present.//void OWTargetSetup(unsigned char family_code){

int i;

// set the search state to find SearchFamily type devicesROM_NO[0] = family_code;


33/36

for (i = 1; i < 8; i++)ROM_NO[i] = 0;

LastDiscrepancy = 64;LastFamilyDiscrepancy = 0;LastDeviceFlag = FALSE;

}

//--------------------------------------------------------------------------// Setup the search to skip the current device type on the next call// to OWNext().//void OWFamilySkipSetup(){

// set the Last discrepancy to last family discrepancyLastDiscrepancy = LastFamilyDiscrepancy;LastFamilyDiscrepancy = 0;

// check for end of listif (LastDiscrepancy == 0)

LastDeviceFlag = TRUE;

}

//--------------------------------------------------------------------------// 1-Wire Functions to be implemented for a particular platform//--------------------------------------------------------------------------

//--------------------------------------------------------------------------// Reset the 1-Wire bus and return the presence of any device// Return TRUE : device present// FALSE : no device present//int OWReset(){

// platform specific// TMEX API TEST BUILDreturn (TMTouchReset(session_handle) == 1);

}

//--------------------------------------------------------------------------// Send 8 bits of data to the 1-Wire bus//void OWWriteByte(unsigned char byte_value){

// platform specific

// TMEX API TEST BUILDTMTouchByte(session_handle,byte_value);

}

//--------------------------------------------------------------------------// Send 1 bit of data to teh 1-Wire bus//void OWWriteBit(unsigned char bit_value){


// TMEX API TEST BUILD


34/36

TMTouchBit(session_handle,(short)bit_value);}

//--------------------------------------------------------------------------// Read 1 bit of data from the 1-Wire bus// Return 1 : bit read is 1// 0 : bit read is 0//unsigned char OWReadBit(){


// TMEX API TEST BUILDreturn (unsigned char)TMTouchBit(session_handle,0x01);

}

// TEST BUILDstatic unsigned char dscrc_table[] = {

0, 94,188,226, 97, 63,221,131,194,156,126, 32,163,253, 31, 65,

157,195, 33,127,252,162, 64, 30, 95, 1,227,189, 62, 96,130,220,35,125,159,193, 66, 28,254,160,225,191, 93, 3,128,222, 60, 98,

190,224, 2, 92,223,129, 99, 61,124, 34,192,158, 29, 67,161,255,70, 24,250,164, 39,121,155,197,132,218, 56,102,229,187, 89, 7,

219,133,103, 57,186,228, 6, 88, 25, 71,165,251,120, 38,196,154,101, 59,217,135, 4, 90,184,230,167,249, 27, 69,198,152,122, 36,248,166, 68, 26,153,199, 37,123, 58,100,134,216, 91, 5,231,185,140,210, 48,110,237,179, 81, 15, 78, 16,242,172, 47,113,147,205,17, 79,173,243,112, 46,204,146,211,141,111, 49,178,236, 14, 80,

175,241, 19, 77,206,144,114, 44,109, 51,209,143, 12, 82,176,238,50,108,142,208, 83, 13,239,177,240,174, 76, 18,145,207, 45,115,

202,148,118, 40,171,245, 23, 73, 8, 86,180,234,105, 55,213,139,87, 9,235,181, 54,104,138,212,149,203, 41,119,244,170, 72, 22,

233,183, 85, 11,136,214, 52,106, 43,117,151,201, 74, 20,246,168,116, 42,200,150, 21, 75,169,247,182,232, 10, 84,215,137,107, 53};

//--------------------------------------------------------------------------// Calculate the CRC8 of the byte value provided with the current// global 'crc8' value.// Returns current global crc8 value//unsigned char docrc8(unsigned char value){

// See Application Note 27

// TEST BUILDcrc8 = dscrc_table[crc8 ^ value];

return crc8;}

//--------------------------------------------------------------------------// TEST BUILD MAIN//int main(short argc, char **argv){

short PortType=5,PortNum=1;int rslt,i,cnt;


35/36

// TMEX API SETUP// get a sessionsession_handle = TMExtendedStartSession(PortNum,PortType,NULL);if (session_handle = 0; i--)

printf("%02X", ROM_NO[i]);printf(" %d\n",++cnt);

rslt = OWNext();}

// find only 0x1Aprintf("\nFIND ONLY 0x1A\n");cnt = 0;OWTargetSetup(0x1A);while (OWNext()){

// check for incorrect typeif (ROM_NO[0] != 0x1A)

break;

// print device foundfor (i = 7; i >= 0; i--)


}

// find all but 0x04, 0x1A, 0x23, and 0x01printf("\nFIND ALL EXCEPT 0x10, 0x04, 0x0A, 0x1A, 0x23, 0x01\n");cnt = 0;rslt = OWFirst();while (rslt){

// check for incorrect typeif ((ROM_NO[0] == 0x04) || (ROM_NO[0] == 0x1A) ||


36/36

(ROM_NO[0] == 0x01) || (ROM_NO[0] == 0x23) ||(ROM_NO[0] == 0x0A) || (ROM_NO[0] == 0x10))OWFamilySkipSetup();

else{

// print device foundfor (i = 7; i >= 0; i--)


}

rslt = OWNext();}

// TMEX API CLEANUP// release the sessionTMEndSession(session_handle);// END TMEX API CLEANUP

}

Documents

1 Wire App-note