How does the 1-Wire Search ROM algorithm find multiple devices on one bus?

Search ROM is a binary-search algorithm that exploits how 1-Wire read slots work: when multiple devices respond simultaneously, the bus master reads each ROM bit twice — once as the true bit, once as its complement. If every device on the bus agrees on that bit (all 0 or all 1), both reads differ normally. If devices disagree (a 'discrepancy'), both reads come back 0, which the master detects. On the first pass, the master resolves every discrepancy by choosing 0, walks through all 64 bits, and records the position of the last (most significant) discrepancy. On the next pass, it repeats the walk but forces a 1 at that recorded discrepancy position, splitting the device population in two, and records the next discrepancy for the following pass. Repeating this until no discrepancies remain enumerates every unique ROM code on the bus, one at a time, in a number of passes bounded by the number of connected devices.

What is the maximum number of devices and cable length on a 1-Wire bus?

There is no protocol-level device limit — the 64-bit ROM code space is large enough that address collisions are not a practical concern, and the Search ROM algorithm scales to however many devices are physically present. In practice, the limiting factors are electrical: bus capacitance from long cables or many parasitic-powered devices slows edge rates and can violate the 1-Wire timing budget, and the pull-up resistor's drive strength must supply enough current for every device that transitions state simultaneously. Datasheets for 1-Wire master ICs typically quote guidance such as up to a few tens of devices and roughly 100 m of cable for standard speed, but bench-validate any design pushing toward those limits — the datasheet figures are typical, not guaranteed, for a given cable type and device mix.

Do I need a hardware 1-Wire peripheral or can I bit-bang it?

Almost no microcontroller has a dedicated 1-Wire hardware peripheral, so nearly every 1-Wire implementation is either bit-banged on a GPIO pin with microsecond-accurate delays, or driven through a dedicated 1-Wire bridge/master IC (such as the DS2482 I2C-to-1-Wire bridge) that handles the bit- and byte-level timing in hardware. A common middle ground on MCUs with a UART peripheral is to reconfigure the UART to a nonstandard baud rate and byte pattern that reproduces 1-Wire reset and bit timing, offloading the timing-critical work from the CPU. See [What Is Bit Banging?](/questions/what-is-bit-banging) for the general trade-offs of a software-timed protocol versus a hardware peripheral.

Communications

What Is 1-Wire?

Last updated 4 July 2026 · 8 min read

Direct Answer

1-Wire is a serial communication protocol developed by Dallas Semiconductor (now Analog Devices) that carries both data and, optionally, device power over a single conductor plus ground. Every 1-Wire device is factory-programmed with a unique 64-bit ROM code — an 8-bit family code, a 48-bit serial number, and an 8-bit CRC — which lets a bus master individually address any number of devices sharing the same wire. A binary-search algorithm called Search ROM lets the master discover every device's ROM code without knowing it in advance, and an optional parasitic power mode lets a device draw its operating current from the data line itself, eliminating the separate power wire.

Detailed Explanation

1-Wire shares one important trait with I2C: both let multiple devices share a bus by addressing them individually rather than needing a dedicated wire per device. Where I2C spends two wires (SDA and SCL) to do this, 1-Wire does it with a single data conductor plus ground — and, in its parasitic power mode, drops the need for a separate power wire entirely. This makes it a common choice for long, thin cable runs to simple sensors, most visibly the DS18B20 digital temperature sensor (see interfacing a digital temperature sensor for a full DS18B20 wiring and firmware walkthrough) and iButton-style identification/authentication devices.

Bus Topology and Signalling

The 1-Wire bus is open-drain, just like I2C: every device can only pull the line low, and a single pull-up resistor (typically 4.7 kΩ) returns it to the idle-high state. The bus master (the microcontroller) always initiates communication; devices only ever respond within a slot the master opens.

Every transaction begins with a reset sequence:

Phase	Master action	Device action	Typical duration
Reset pulse	Pulls line low	—	480–960 µs
Presence detect	Releases line	Pulls line low if present	Device pulls low 60–240 µs after release
Idle	Line returns high	—	—

If the master sees a low pulse during the presence-detect window, at least one device is present and ready to receive a ROM command. Bit-level read and write slots each last approximately 60 µs and use the position of a brief master-initiated low pulse within that window to encode a 0 or a 1 — the same style of precise, microsecond-scale timing used by the DS18B20's protocol layer.

The 64-Bit ROM Code

Every 1-Wire device is laser-programmed at manufacture with a globally unique 64-bit ROM code, structured as three fields:

Bits	Field	Purpose
0–7	Family code	Identifies the device type (e.g. 0x28 for the DS18B20, 0x01 for basic iButton serial-number devices)
8–55	Serial number	A 48-bit unique identifier assigned at manufacture
56–63	CRC	An 8-bit CRC of bits 0–55, used to detect a corrupted ROM code read

This structure is why any number of otherwise-identical devices — a string of DS18B20 sensors, for example — can share one bus without an address-configuration pin: the serial number is baked into silicon and guaranteed unique, unlike an I2C device's fixed or pin-selected address, which frequently collides between identical parts on the same bus.

ROM Commands

After a successful reset/presence cycle, the master issues one of four ROM commands to select which device(s) will respond to the function commands that follow:

Read ROM (0x33) — valid only when exactly one device is on the bus; the device transmits its 64-bit ROM code directly, skipping the need to search for it.
Match ROM (0x55) — the master transmits a specific 64-bit ROM code; only the device with that exact code responds to subsequent commands. This is how an individual sensor is addressed once its ROM code is known.
Skip ROM (0xCC) — broadcasts the following command to every device on the bus simultaneously, with no addressing. Useful for triggering a temperature conversion on every DS18B20 at once, but only safe for commands where a collided response doesn't matter (a single-device bus, or a write-only broadcast).
Search ROM (0xF0) — the discovery command described below, used to enumerate every device's ROM code when it isn't already known.

The Search ROM Algorithm

Search ROM solves a problem I2C doesn't have to: unlike I2C, where the master already knows or configures each device's address in advance, a 1-Wire master frequently has no prior knowledge of which — or how many — devices are on the bus. Search ROM is a binary-search algorithm that resolves this by exploiting a property of the 1-Wire read slot.

When the master reads a ROM bit, every responding device transmits that bit's true value, then its complement, in two consecutive read slots. If all devices agree on the bit, the master reads a normal 1-then-0 or 0-then-1 pair. If devices disagree — some have a 0 in that bit position, others a 1 — the two reads collide and the master reads 0 in both slots, an unambiguous signal called a discrepancy.

The algorithm proceeds:

Walk all 64 bits, resolving every discrepancy by choosing the 0 branch and writing that choice back to the bus (so only devices matching that branch continue responding). Record the bit position of the last (most significant) discrepancy encountered.
On the next full pass, repeat the walk, but force the 1 branch at that recorded discrepancy position instead of the default 0. This directs the search down the previously unexplored branch, discovering a second device's ROM code. Record the new last-discrepancy position for the following pass.
Repeat, each pass exploring one more previously-unresolved branch, until a pass completes with no discrepancies at all — meaning every device's unique ROM code has been discovered.

The number of passes required equals the number of devices with at least one bit position where they diverge from all previously found devices — in practice, the number of devices on the bus. This is the mechanism behind the "enumerate all sensors" step referenced in the DS18B20 multi-sensor FAQ; most MCU 1-Wire libraries (Arduino's OneWire library, for example) implement this exact algorithm and simply return a list of discovered ROM codes.

Parasitic Power Mode

1-Wire's most distinctive feature is parasitic power: a device's VDD pin is tied to ground, and the device instead draws its operating current from the data line itself during the portions of a transaction when the line is held high, storing charge in an internal capacitor to bridge the gaps when the line is pulled low for signalling. This reduces the bus to two wires total (data and ground) rather than three.

The trade-off is a hard current budget. A parasitic-powered device typically needs a small holding current (tens of microamps) most of the time, but can require a much larger current — the DS18B20, for instance, draws up to 1.5 mA during a temperature conversion — for a sustained period. A standard passive pull-up resistor cannot supply this without the bus voltage sagging enough to reset the device, so parasitic-powered operations that need high current require the master to actively drive the line high with a low-impedance "strong pull-up" (typically a GPIO or MOSFET switch to VCC) for the duration of that operation, rather than relying on the passive resistor.

Design Considerations

Choose parasitic power only when the wire count genuinely matters. A dedicated VDD wire eliminates strong pull-up timing entirely and is more reliable for multi-device buses — reserve parasitic power for cases where the two-wire simplicity (long cable runs, minimal connector pin count) outweighs its added firmware complexity.
Size the pull-up for your bus, not the datasheet default. 4.7 kΩ is the common nominal value, but longer cables and more parasitic-powered devices increase bus capacitance and total current draw; verify signal integrity with an oscilloscope on the actual cable length and device count used in your design, not just on a bench with a single device on a short lead.
Validate the ROM CRC on every read. The 8-bit CRC field exists specifically because long, unshielded 1-Wire cable runs are more exposed to noise than a short PCB trace; always check it and retry a corrupted transaction rather than trusting an unvalidated ROM code or data read.
Prefer a dedicated 1-Wire bridge IC for many devices or tight timing budgets. A hardware bridge such as the DS2482 offloads reset, bit-timing, and even Search ROM sequencing from the MCU over an I2C interface — worth considering once bit-banging 1-Wire timing starts competing for CPU time with other real-time firmware work.

Common Mistakes

Treating 1-Wire like I2C's addressing model. Unlike I2C, where addresses are typically known in advance or set via address-select pins, 1-Wire ROM codes are unknown until discovered — firmware that hardcodes an expected ROM code will silently fail the moment a device is swapped for a replacement with a different serial number, unless the design deliberately re-runs Search ROM or uses Skip ROM for single-device buses.
Using parasitic power with multiple devices and a weak pull-up. Several parasitic-powered devices performing a high-current operation (a Convert T command sent via Skip ROM, for example) can collectively demand more current than the strong pull-up circuit can supply, causing intermittent conversion failures that only appear once more than one or two sensors are added.
Ignoring reset/presence timing tolerances. 1-Wire's timing windows are specified as ranges (e.g. a 480–960 µs reset pulse), not fixed values; a bit-banged implementation using unnecessarily tight delays can work reliably on the bench and fail intermittently on a different MCU clock speed or under interrupt jitter. Validate against a logic analyser rather than trusting delay-loop code alone.
Assuming Skip ROM is always safe. Skip ROM broadcasts to every device on the bus. For a write-only broadcast (starting all DS18B20 sensors' conversions simultaneously) this is fine; issuing a Skip ROM followed by a read command with more than one device present causes every device to try to drive the bus simultaneously, corrupting the response.

Frequently Asked Questions

How does the 1-Wire Search ROM algorithm find multiple devices on one bus?: Search ROM is a binary-search algorithm that exploits how 1-Wire read slots work: when multiple devices respond simultaneously, the bus master reads each ROM bit twice — once as the true bit, once as its complement. If every device on the bus agrees on that bit (all 0 or all 1), both reads differ normally. If devices disagree (a 'discrepancy'), both reads come back 0, which the master detects. On the first pass, the master resolves every discrepancy by choosing 0, walks through all 64 bits, and records the position of the last (most significant) discrepancy. On the next pass, it repeats the walk but forces a 1 at that recorded discrepancy position, splitting the device population in two, and records the next discrepancy for the following pass. Repeating this until no discrepancies remain enumerates every unique ROM code on the bus, one at a time, in a number of passes bounded by the number of connected devices.
What is the maximum number of devices and cable length on a 1-Wire bus?: There is no protocol-level device limit — the 64-bit ROM code space is large enough that address collisions are not a practical concern, and the Search ROM algorithm scales to however many devices are physically present. In practice, the limiting factors are electrical: bus capacitance from long cables or many parasitic-powered devices slows edge rates and can violate the 1-Wire timing budget, and the pull-up resistor's drive strength must supply enough current for every device that transitions state simultaneously. Datasheets for 1-Wire master ICs typically quote guidance such as up to a few tens of devices and roughly 100 m of cable for standard speed, but bench-validate any design pushing toward those limits — the datasheet figures are typical, not guaranteed, for a given cable type and device mix.
Do I need a hardware 1-Wire peripheral or can I bit-bang it?: Almost no microcontroller has a dedicated 1-Wire hardware peripheral, so nearly every 1-Wire implementation is either bit-banged on a GPIO pin with microsecond-accurate delays, or driven through a dedicated 1-Wire bridge/master IC (such as the DS2482 I2C-to-1-Wire bridge) that handles the bit- and byte-level timing in hardware. A common middle ground on MCUs with a UART peripheral is to reconfigure the UART to a nonstandard baud rate and byte pattern that reproduces 1-Wire reset and bit timing, offloading the timing-critical work from the CPU. See [What Is Bit Banging?](/questions/what-is-bit-banging) for the general trade-offs of a software-timed protocol versus a hardware peripheral.

References

Related Forum Discussions

I2C bus completely dead after unplugging a sensor live — SDA stuck low, no NACK, nothing

We've got a shared I2C bus with four sensors on it (temperature, humidity, an IMU, and a current sense IC), all on the same bus off one MCU.

STM32F401 UART printing garbage after switching to 84 MHz PLL — same 115200 baud in CubeMX and PuTTY

Got a WeAct Black Pill (STM32F401CCU6) project that's been running happily on the default HSI clock at 16 MHz. Using USART1 on PA9/PA10 thro

SPI reads all returning 0xFF — logic analyser shows MISO activity, W25Q32 not responding to commands

Been staring at this one for a day and a half. I'm trying to read the JEDEC ID from a W25Q32JV SPI flash chip on a custom STM32L432 board. T

I2C bus scan finding nothing — NACK on every address despite pull-ups

Working through my first proper I2C project — hooking up a BME280 temp/humidity sensor to an ESP32 devkit. Wired SDA to GPIO21 and SCL to GP