Download - 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.)
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
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
-
8/3/2019 1 Wire App-note
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
-
8/3/2019 1 Wire App-note
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/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
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
-
8/3/2019 1 Wire App-note
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:
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
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
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
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
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
22/36
Figure 2. Search Flow.
-
8/3/2019 1 Wire App-note
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.
-
8/3/2019 1 Wire App-note
24/36
-
8/3/2019 1 Wire App-note
25/36
-
8/3/2019 1 Wire App-note
26/36
Figure 3. Search Example.
Advanced Search Variations
-
8/3/2019 1 Wire App-note
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
-
8/3/2019 1 Wire App-note
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);
-
8/3/2019 1 Wire App-note
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;
-
8/3/2019 1 Wire App-note
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;}
}
-
8/3/2019 1 Wire App-note
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
-
8/3/2019 1 Wire App-note
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;
-
8/3/2019 1 Wire App-note
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){
// platform specific
// TMEX API TEST BUILD
-
8/3/2019 1 Wire App-note
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(){
// platform specific
// 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;
-
8/3/2019 1 Wire App-note
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--)
printf("%02X", ROM_NO[i]);printf(" %d\n",++cnt);
}
// 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) ||
-
8/3/2019 1 Wire App-note
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--)
printf("%02X", ROM_NO[i]);printf(" %d\n",++cnt);
}
rslt = OWNext();}
// TMEX API CLEANUP// release the sessionTMEndSession(session_handle);// END TMEX API CLEANUP
}