31 Wired Communication Fundamentals
31.1 Start With Why a Wire Is Still Useful
Wireless links are convenient, but wires still solve hard IoT problems: predictable timing, power delivery, noise control, security boundaries, and simple commissioning. The choice is not old versus new; it is which physical path gives the system enough trust.
Use this chapter to compare wired options by job. UART, I2C, SPI, Ethernet, and industrial wiring each make different promises about distance, speed, topology, timing, and evidence.
Overview: Wired Links Are Local Design Contracts
Wired communication connects a microcontroller to nearby sensors, displays, storage, modems, and other boards through electrical signals. The wire is only the medium. The protocol defines who may talk, how bits are framed, which clock is trusted, how devices are selected, and what electrical limits must be respected.
For IoT boards, the common beginner decision is between UART, I2C, and SPI. UART is simple point-to-point asynchronous serial. I2C shares a clocked two-wire bus across addressed peripherals. SPI uses a shared clock and data wires plus device-select lines for higher-throughput peripherals. The right choice is the one whose wiring, timing, device count, distance, and validation evidence fit the peripheral requirement.
The local link becomes a design contract because a peripheral failure often looks like a cloud or software fault later. A bad pull-up, long cable, weak ground reference, wrong voltage level, or overloaded shared bus can create missing readings, repeated resets, corrupted display frames, or values that are accepted by the application as if they were real measurements. The board review must prove the signal before blaming the network.
That proof starts with the physical context: whether the devices are on the same PCB, across a short harness, inside a noisy enclosure, or across a field cable. Same-board sensors can usually use short low-voltage buses. Cable runs near motors, relays, pumps, or separate power domains need stronger evidence: shielding, differential signaling, isolation, termination, service connectors, and a way to probe the bus during failures.
On switched wired networks, neighbor-discovery evidence belongs at this same link boundary. Link Layer Discovery Protocol (LLDP) frames, or vendor equivalents such as Cisco Discovery Protocol (CDP), let adjacent switches, gateways, and controllers advertise chassis identity, port identity, management address, and similar type-length-value records. Those records do not prove the application is healthy, but they are useful when an IoT gateway is plugged into the wrong switch port, a PoE run has been moved, or an operations team needs to reconcile the physical cable map with the logical network inventory.
The first design win is knowing which evidence belongs at the wire.
UART
Best for simple two-device links such as debug consoles, GPS modules, and legacy serial peripherals.
I2C
Best for many low-speed peripherals on the same board when pin count matters and each device can be addressed.
SPI
Best for displays, storage, converters, and other peripherals that need higher throughput or deterministic clocked transfers.
Industrial Serial
Use differential or isolated wired links when cable length, noise, or different power domains make board-level buses unsafe.
Design question: pick the wired protocol from peripheral constraints, not from a blanket rule that the fastest bus is always best.
Signal Encoding Still Matters
Before UART, I2C, or SPI can be trusted, the receiver has to decide where each bit begins and what voltage level counts as a 0 or 1. Lower logic swings can save power, but they leave less noise margin. Higher swings and familiar 3.3 V or 5 V domains can be easier to debug, but every connected device still needs compatible input thresholds, a shared reference, and protection from overvoltage.
A plain data wire can also hide timing problems. Long runs of the same bit value give the receiver few transitions to resynchronise against, while cable resistance, capacitance, loss, noise, and dispersion can round or shift edges until a clean square wave at the transmitter becomes ambiguous at the receiver. That is why board evidence should include the actual waveform or logic-analyser decode when timing is tight, not only the bytes printed by firmware.
Some links solve this by adding a clock line, as SPI and I2C do locally. Others make the data stream self-clocking or more balanced. Asynchronous serial adds start and stop bits around each character so the receiver can resynchronise on short messages. Manchester-style encodings force transitions but spend extra bandwidth. Block encodings such as 4B/5B choose five-bit codewords for four data bits so there are enough transitions and fewer long runs of zeros or ones; variants of that idea appear in faster wired links when clock recovery and DC balance matter more than raw coding efficiency.
Practitioner: Select the Bus from a Peripheral Evidence Record
A practical wired-protocol choice starts by listing the peripherals and their hard constraints. Some parts support only one bus. Others support several buses, but the application does not benefit from the faster one. The record should separate required throughput from advertised maximum speed, then check pin budget, cable length, pull-ups, grounding, noise, and test access.
Older wired-standards tables often mix RS-232, RS-422, RS-485, I2C, SPI, Microwire, 1-Wire, and USB rows. Read those rows as evidence prompts, not rankings: record whether the link is synchronous or asynchronous, point-to-point, multi-drop, or multi-point, full or half duplex, how many devices can share it, the credible distance, and how many pins or conductors the final connector must carry. RS-485 may win a noisy long bus; USB may win for a local high-speed peripheral; 1-Wire may fit a very slow pin-limited sensor chain. The selection still belongs to the installed boundary, not to the largest speed number in the table.
Greenhouse Controller Pattern
For a greenhouse controller with several slow environmental sensors, a display, and a storage device, the clean design is often mixed: I2C for slow sensors that share two wires, SPI for the display or storage device that needs higher throughput, and UART for a debug console or serial module. The review should prove that each bus has enough pins, timing margin, electrical margin, and test points.
Under the Hood: Timing, Edges, and Electrical Limits Decide Reliability
Under the hood, a wired protocol is a timed electrical agreement. Devices must agree on voltage thresholds, clocking, framing, bus ownership, pull-up behavior, and when a signal is valid. A wire can still fail because of ringing, weak pull-ups, excessive capacitance, ground offsets, connector damage, cable length, or crosstalk from faster nearby traces.
UART tolerates simple point-to-point wiring because both ends agree on baud rate, start bit, data bits, optional parity, and stop bits, but it has little built-in help if the clocks drift too far or the voltage levels are mismatched. I2C uses open-drain lines and pull-up resistors, so bus capacitance and pull-up strength shape the rise time. SPI pushes an explicit clock and chip-select lines, so routing, edge rate, and simultaneous switching near other traces can dominate reliability.
The timing budget is not only a datasheet number. It includes firmware interrupt latency, sensor clock stretching, display refresh bursts, DMA transfers, connector resistance, cable capacitance, level shifters, and ground noise during actuator switching. A bench test with short jumper wires can pass while the installed enclosure fails because the waveform is slower, noisier, or referenced to a different ground.
Line coding is another part of that agreement. The Signal Encoding section earlier explains why long runs of the same value threaten clock recovery and DC balance, and how schemes such as Manchester, NRZI, and 4B/5B spend transitions or extra bits to prevent it. At review time the question is narrower: does this specific link actually need that transition density, and is the coding overhead recorded in the timing budget alongside the other entries above?
A useful under-the-hood review keeps captures or scope notes at the real operating speed and real cable length. It records clock frequency, logic voltage, pull-up values, measured rise and fall shape, error counters, retry behavior, and the nearby events that coincide with corruption. That evidence turns "the bus is flaky" into a concrete fix such as lowering bus speed, changing pull-ups, separating traces, adding termination, improving grounding, or moving a noisy peripheral to another interface.
Clocking
Synchronous buses depend on a shared clock edge. Asynchronous UART-style links depend on agreed baud rate and framing.
Bus Ownership
A controller, address, chip-select line, or higher-layer rule must prevent two devices from driving the same wire incorrectly.
Signal Integrity
Trace length, pull-ups, capacitance, termination, grounding, and nearby switching edges decide whether bits arrive as intended.
Field Evidence
Validate with real cable length, connectors, operating current, noise sources, temperature range, and service access, not only a desk prototype.
Failure mode: a continuity tester says the wire is connected, but the bus still fails because the waveform, timing, grounding, or noise margin is wrong.
Phoebe’s Why
I2C is open-drain: a device only pulls the line low, so it is the pull-up resistor that drags the line back up to \(V_{DD}\), fighting the bus’s own parasitic capacitance the whole way. That fight is a textbook RC charging circuit – Ohm’s law plus a capacitor – so the rising edge is not instant, it is an exponential. A small pull-up resistor charges that capacitance fast but sinks more current when a device pulls low, which needs a stronger output driver. A large pull-up saves current but slows the edge until the receiver can no longer tell where one bit ends and the next begins. The “right” pull-up is not one number; it is the narrow window between an output-current floor and a rise-time ceiling.
The Derivation
Sink-current floor from Ohm’s law, using the low-level output voltage \(V_{OL}\) and the guaranteed sink current \(I_{OL}\):
\[R_{min} = \frac{V_{DD} - V_{OL}}{I_{OL}}\]
Charging through the pull-up into bus capacitance \(C_b\) is \(i = C_b \frac{dV}{dt} = \frac{V_{DD}-V}{R}\), which integrates to
\[V(t) = V_{DD}\left(1 - e^{-t/RC_b}\right)\]
The 10%-90% rise time follows from that exponential:
\[t_r = R C_b \ln(9) \approx 2.2\,R C_b\]
Rearranged, the rise-time budget sets a ceiling on the same resistor:
\[R_{max} = \frac{t_{r,max}}{C_b \ln(9)}\]
Worked Numbers: This Chapter’s I2C Bus
This chapter names 3.3 V and 5 V logic domains and says bus capacitance and pull-up strength shape the rise time, without giving component values, so the worked numbers use the I2C-bus specification’s catalog-typical figures: \(V_{DD}=3.3\) V, \(V_{OL,max}=0.4\) V, \(I_{OL,max}=3\) mA, and a fully loaded bus at \(C_b=400\) pF.
- Sink-current floor: \(R_{min} = (3.3-0.4)/0.003 = 967\ \Omega\)
- Standard-mode ceiling (100 kHz, \(t_{r,max}=1000\) ns): \(R_{max} = 1000\text{ns}/(400\text{pF}\times\ln 9) = 1140\ \Omega\) – a window of only \(967\)-\(1140\ \Omega\) at full bus loading
- Fast-mode ceiling (400 kHz, \(t_{r,max}=300\) ns): \(R_{max} = 300\text{ns}/(400\text{pF}\times\ln 9) = 341\ \Omega\) – below \(R_{min}\), so a fully loaded 400 pF bus cannot run Fast-mode with standard sink current at all
- Why 4.7 k\(\Omega\) still works on the greenhouse board above: at the same 400 pF, \(\tau = 4700\,\Omega\times400\text{pF} = 1.88\ \mu\text{s}\), so \(t_r = 2.2\tau = 4.13\ \mu\text{s}\) – over four times the Standard-mode budget. A common 4.7 k\(\Omega\) pull-up is only safe because a short board-level bus with a few slow sensors carries far less than 400 pF, not because the value is universally correct.
The lesson for the selection record above: a pull-up value copied from a reference design is only valid for that design’s bus capacitance and target speed. A longer cable or more devices raises \(C_b\) and can push the same resistor past its rise-time ceiling even though continuity and pull-up presence both look fine on a meter.
31.2 Summary
Wired communication is the local contract between an IoT controller and nearby peripherals. UART, I2C, SPI, and longer-distance serial standards differ in clocking, topology, pin count, throughput, bus ownership, and electrical limits. The right choice depends on the peripheral’s supported interfaces, required data movement, available pins, distance, grounding, noise, and validation evidence.
31.3 Key Takeaway
Choose a wired protocol from evidence: supported interfaces, traffic need, topology, pin budget, timing margin, and electrical reliability. A wire is not automatically reliable until the signal, grounding, and field conditions have been tested.
31.4 See Also
31.4.1 UART and RS-232
Study asynchronous point-to-point serial links, framing, voltage levels, and debugging.
31.4.2 I2C Protocol
Review two-wire addressing, pull-ups, bus loading, and shared sensor buses.
31.4.3 SPI Protocol
Explore clocked high-throughput peripheral links, chip select, and full-duplex transfers.
31.4.4 Wired Access: Ethernet
Connect board-level wired thinking to LAN-scale Ethernet, switching, and PoE.