1-Wire

In some device scenarios, the first engineering pain is not throughput, and not even many high-speed peripherals. It is that wiring itself is too expensive. Temperature probes may be spread out, a chassis may only tolerate a few wires, and a single controller may need to drive a few simple sensors. In that situation, even I2C’s two signal lines can feel like too many, let alone a dedicated chip-select line for each device.

1-Wire solves exactly that kind of “the device is simple, the data is small, but wiring and connection cost matter a lot” problem. It optimizes first for extreme wire savings, unique device identification, low-cost access, and in some cases even saving a separate power wire.

The most stable first mental model is this: 1-Wire is a bus where a single pulled-up shared data line uses strict timing slots to distinguish reset, presence detection, read/write bits, and device addressing, so the master can name, enumerate, and access multiple slaves at extremely low wiring cost. reset, presence pulse, ROM code, read/write time slot, and parasite power all exist to support that.

How Can One Wire Still Communicate

The most obvious feature of 1-Wire is right in the name: the bus usually shares only one effective signal line, DQ.

The electrical logic is somewhat similar to I2C and also depends on pull-up behavior:

• when the bus is idle, a pull-up resistor keeps DQ high
• master and slave devices mostly express action by pulling the line low
• the final line level is determined by whether anyone is pulling low

That gives direct benefits:

• wiring is extremely sparse
• multiple devices can be tied to the same line
• board and harness cost stay low

The cost is also clear:

• bandwidth is low and communication depends heavily on precise timing
• line capacitance, wire length, and pull-up strength directly affect the waveform
• because the line is shared, many functions cannot rely on dedicated control wires and must be encoded in timing

So 1-Wire is not “I2C with one fewer wire.” It takes another path: first compress the hardware connection to the minimum, then accept stronger protocol and timing constraints as the price.

How the Master Knows There Is a Device on the Line

The first problem on a single-wire shared bus is not “what data should we send?” It is “is there a device on the line, and are they ready?”

The entry point for 1-Wire is not address broadcast. It is a reset and presence-detect sequence:

1. The master drives a reset pulse by pulling the line low
2. The master releases the bus so it can return high
3. Any device that is present and ready responds within the defined window by pulling the line low again, generating a presence pulse

That one sequence answers two things at once:

• the master is saying “a new transaction starts now”
• the slave is saying “I am online, and I heard you”

When reading waveforms, reset plus presence is the first thing to restore. If that does not work, the rest of the command bytes, device search, and data access usually have no meaningful explanation yet.

Time Slots Are the Real Bus Order

With two-wire buses, you can still separate clock and data a little. 1-Wire does not have that option. Because there is no dedicated clock line, whether a bit means 0 or 1 and who is driving the bus must all be defined by time slots.

The three most important actions are:

• write 1
• write 0
• read bit

They all happen inside master-initiated fixed time slots, and the length of the low pulse and the release point determine the meaning of the slot.

The first-layer model only needs one idea:

• the master always opens the slot by pulling the bus low
• the difference between writing 0 and 1 is mainly how long the line stays low
• during a read slot, the master briefly pulls low and then releases; if the slave wants to return 0, it pulls low again inside the sampling window, and if it wants to return 1, it stays off the line

So the true shared order in 1-Wire is not a byte stream. It is a set of timing rules with very strict expectations for low-pulse width and sampling moment. That is also the easiest place for real-world systems to fail: not because the field names were read wrong, but because the waveform never landed in the right window.

Why 1-Wire Is Naturally Good for Many Small Devices

Once there is only one shared line, the master still has to answer “who exactly am I talking to this time?” The 1-Wire answer is not a short address or an external chip select. It gives each device a factory-unique ROM code.

A typical 64-bit ROM code can be thought of as three parts:

• family code: the device family type
• a unique serial number
• CRC

That matters a lot because it ties device identity directly to bus access:

• multiple identical devices can share one wire
• the master does not need to manually assign addresses in advance
• after power-up, the system can enumerate devices first and then map them into business logic

This is very different from I2C. I2C addresses are usually short and often collide in default configurations. 1-Wire instead puts uniqueness into the device manufacturing identity itself, at the cost of a slower and search-heavy discovery process.

How the Master Selects One Device on the Shared Wire

1-Wire usually starts with a ROM command that decides whether the transaction is for all devices or for one specific device. Common patterns include:

• Read ROM: when only one device is on the bus, read its ROM number directly
• Match ROM: the master provides the full ROM number and selects only that device
• Skip ROM: skip point-to-point selection and let all devices accept the following function command
• Search ROM: the master enumerates devices on the bus by walking the bit-level search tree

The most representative mechanism is not Match ROM. It is Search ROM. The special thing about 1-Wire is not “it has unique IDs.” It is that it can discover those IDs with all devices tied to one line, no dedicated chip select, and no preconfigured addresses.

What Search ROM Is Solving

If several devices are on the bus, each with its own 64-bit unique number, how does the master learn what IDs are present?

1-Wire solves that by searching bit by bit instead of letting each device speak a full ID at once. You can think of it as walking a binary tree over the ROM number space.

The engineering model only needs this:

• the master initiates the search one bit at a time
• each device participates depending on whether its current bit is 0 or 1
• if both 0 and 1 exist at a position, the master knows there is a branch there
• the master chooses one branch in a search pass and returns later for the other

That is how all devices on the line can eventually be enumerated.

What it solves is clear:

• no manual address setup
• no extra chip-select wire
• the master can discover topology changes at runtime

The cost is also clear:

• the search is slow and not meant for frequent use
• the driver must maintain branch state and search order correctly
• bad waveform quality can create very strange failures, because the search is highly sensitive to bit-level timing and collision observation

So Search ROM is one of the most important 1-Wire mechanisms to understand. It exists so that device discovery remains possible under single-wire sharing.

Function Commands Are Where the Real Business Happens

Once the ROM command is complete, the master moves on to the actual device function. A common temperature-sensor flow looks like this:

1. reset
2. wait for presence
3. send Match ROM or Skip ROM
4. send a function command, such as starting a temperature conversion
5. wait for the conversion to finish
6. reset again
7. select the target device again
8. read the scratchpad or other data area

That reveals one important layer split:

• ROM command answers “who are we talking to?”
• function commands answer “what do we want it to do?”

Many documents mix all the commands into one list, but in engineering terms it is more important to keep these two layers separate. Otherwise it is easy to confuse “the device was not selected correctly” with “the device function command failed.”

Why Parasite Power Makes 1-Wire Feel Like an Engineering Tradeoff Bus

One of the special things about 1-Wire is that some devices support parasite power. That means the device may not have a separate power pin; instead, it stores energy from the high level on DQ to keep working.

The appeal is obvious:

• remote probes can save one power wire
• wiring and connectors become simpler
• it is a very good fit for temperature probes and other ultra-low-power identity chips

But it is not free. Parasite power binds data communication and power delivery much more tightly:

• a high level on the bus is not only logic 1, but also recharge time for the device
• during some higher-power operations, the master may need a stronger pull-up
• line length, pull-up strength, voltage drop, and load variation all affect whether the device works stably

That is why 1-Wire is hard to understand only from protocol bytes. More than many buses, it forces you to think about electrical behavior and protocol behavior together, because the same wire carries both communication and power meaning.

Why Most 1-Wire Accesses Keep Involving Wait Time

Take a temperature sensor as an example. The first time people use 1-Wire, they often assume the result should be readable immediately after the command is sent. In reality, that is often not the case, because the device needs time for internal action.

A common flow looks like this:

1. select the device
2. issue a conversion command
3. wait for the device to finish its internal sampling or calculation
4. select the device again
5. read the result register or scratchpad

Two mistakes happen here often.

First, “the bus accepted the command” is mistaken for “the device has already finished the internal action.” 1-Wire does not hide that business-level waiting for you.

Second, “I cannot read the result” is blamed immediately on the protocol link. In practice, the most common causes are not enough wait time, insufficient power, missing strong pull-up handling, or the previous conversion still being in progress.

So 1-Wire debugging cannot stop at “did bytes go back and forth?” You also have to check whether the device’s internal operation time was respected.

What 1-Wire Is Most Easily Mistaken For

1-Wire is often mistaken for “just a slower, smaller-wiring serial port” or “a simplified bus with only one data line.” Both readings are unstable.

It is not like UART because:

• it is not a point-to-point byte stream
• it has no separate clock, but it also does not continuously stream based on a fixed baud rate
• it depends on reset, presence detection, bit time slots, and device search as bus-level rules

It is not just a smaller I2C because:

• it has no separate clock line
• addressing is built on a unique ROM and search flow instead of short-address broadcast
• some devices also fold power delivery into the same line

The more accurate view is: 1-Wire is a single-wire bus designed for ultra-low wiring cost and simple device access. It accepts low speed, strong timing dependence, and heavier electrical constraints as the price for saving wires.

What To Check First in Engineering

When implementing, capturing, or debugging 1-Wire, the most informative checks are usually not the full command table. Start with these points:

First, check whether reset and presence pulse are working. If there is no presence pulse, first look at pull-up, power, wiring, timing width, and whether the device is actually online.

Second, check whether the master’s read/write time slots are landing correctly. Many “occasional errors” are not state machine bugs at all. They are low-pulse width, release timing, or sampling-point drift.

Third, if device search is unstable, suspect waveform quality and line loading before suspecting the ROM algorithm. Search ROM is very sensitive to bit-level collision observation, and long wires, bad pull-ups, or slow edges will magnify issues quickly.

Fourth, when parasite-powered devices are involved, do not treat the issue as only a communication failure. Check the high-level hold time, strong pull-up requirements, conversion current, and line voltage drop together.

Fifth, separate protocol-layer results from device internal state. A command being written does not mean conversion is complete, and a successful ROM match does not mean the next function access is automatically valid.

When It Fits and When It Does Not

1-Wire is a good fit for:

• sensors or identity devices with very small data volumes and low access rates
• scenarios where wiring is expensive and the harness is pin-constrained
• simple networks with one master and many slaves where each device should have its own unique identity

1-Wire is not a good fit for:

• high-throughput communication
• control links with stronger latency and real-time requirements
• long wires, heavy loads, and systems that do not want to deal carefully with waveform and power details
• systems with many devices that need frequent polling

So choosing 1-Wire is not because it is “the simplest.” It is because, for one class of problem, it is very cost-effective: devices are simple, data is small, wiring is expensive, and you want the fewest conductors possible to handle identification, access, and sometimes power together.

Further Reading

• I2C
• SPI
• UART