28 Wired Communication Fundamentals
A controller reads a slow temperature probe while refreshing a display and printing debug records. All three peripherals are wired, but they do not need the same interface. Compare their traffic and electrical assumptions before choosing a bus for convenience.
28.1 Start With Why a Wire Is Still Useful
28.1.1 Choose the Wire by the Job
A microcontroller is a small computer that reads devices and controls local work. A protocol is an agreed set of exchange rules. Universal asynchronous receiver-transmitter (UART), inter-integrated circuit (I2C), and serial peripheral interface (SPI) are three common ways to connect nearby parts.
Picture a controller with a debug socket, two sensors, and a fast display. The debug link needs simple point-to-point access. The sensors can share a short addressed bus. The display needs fast transfers and a separate select line. One wire choice does not fit all three jobs.
For each link, record distance, voltage, clock owner, device count, required speed, connector, and likely noise. Disconnect one device, slow the clock, disturb the ground, and restart the controller. Check whether the fault stays local and whether a technician can see it with a meter or logic trace.
These checks do not prove that data is true after it leaves the board. They prove the local signal contract. The deeper sections explain framing, addressing, pull-ups, timing, discovery, and stronger links for long or noisy cable runs.
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.
28.2 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.
Before overview: wired links are local design contracts, inspect Figure 28.1: Microcontroller Peripheral Connections must be considered with UART. That visual pairing grounds local wired protocols connect board-level peripherals before traffic ever reaches an ip network in named evidence.
Use UART to test Microcontroller Peripheral Connections in the diagram at Figure 28.1. Then inspect I2C bus as the final qualifier on local wired protocols connect board-level peripherals before traffic ever reaches an ip network. That sequence keeps overview: wired links are local design contracts tied to what is visibly labelled.
The visual evidence for overview: wired links are local design contracts sits in Figure 28.2. Find Wired Protocol Trade-offs beside Speed vs Wire Complexity before interpreting more wires can buy throughput or simpler timing, but the extra pins and routing still need to be justified.
Within the diagram, Wired Protocol Trade-offs opens Figure 28.2; Speed vs Wire Complexity provides the counterpoint, and SPEED closes the inspection. This reading constrains more wires can buy throughput or simpler timing, but the extra pins and routing still need to be justified and supplies the visual evidence for overview: wired links are local design contracts.
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.
GPIO
Best for simple on/off signals -- switches, buttons, motion sensors, relays, and single-actuator control -- where there is no protocol at all, only a threshold voltage and a toggle rate that tops out around 1 kHz.
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.
28.2.1 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.
Ground practitioner: select the bus from a peripheral evidence record with the visual at Figure 28.3. Start from Wired Communication Standards, but keep Common Cable Connector Types visible while evaluating board-level serial buses and longer-distance wired standards solve different problems.
Compare Wired Communication Standards with Common Cable Connector Types inside the visual at Figure 28.3. Next find DB-9, which completes the scope of board-level serial buses and longer-distance wired standards solve different problems. The decision in practitioner: select the bus from a peripheral evidence record must preserve that labelled boundary.
The visual evidence for practitioner: select the bus from a peripheral evidence record sits in Figure 28.4. Find Wired Interface Selection beside Two devices? before interpreting the selection route should reject buses that do not meet physical or traffic constraints.
Trace the visual from Wired Interface Selection to Two devices? in Figure 28.4; verify UART is simplest before concluding. Together those labels make the selection route should reject buses that do not meet physical or traffic constraints testable. Apply their boundary when working through practitioner: select the bus from a peripheral evidence record.
Pause at Figure 28.5 before carrying practitioner: select the bus from a peripheral evidence record forward. Its visual vocabulary joins UART, I2C, and SPI Topologies to Point-to-Point, Multi-Drop, Multi-Point, which frames topology drives both wiring effort and fault behavior.
At UART, I2C, and SPI Topologies in Figure 28.5, compare the diagram with Point-to-Point, Multi-Drop, Multi-Point; then locate UART. That labelled check bounds topology drives both wiring effort and fault behavior. For practitioner: select the bus from a peripheral evidence record, retain UART as evidence for the resulting choice.
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.
28.2.1.1 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.
The next claim about under the hood: timing, edges, and electrical limits decide reliability depends on Figure 28.6. Its diagram makes Synchronous vs Asynchronous and Shared Clock vs Start/Stop Bits explicit within synchronous buses move data against an explicit clock; asynchronous links recover timing from the frame.
At Synchronous vs Asynchronous in Figure 28.6, compare the diagram with Shared Clock vs Start/Stop Bits; then locate SYNCHRONOUS. That labelled check bounds synchronous buses move data against an explicit clock; asynchronous links recover timing from the frame. For under the hood: timing, edges, and electrical limits decide reliability, retain SYNCHRONOUS as evidence for the resulting choice.
Before under the hood: timing, edges, and electrical limits decide reliability, inspect Figure 28.7: Full-Duplex vs Half-Duplex must be considered with Simultaneous vs Alternating. That visual pairing grounds duplex mode determines whether both sides can talk at once or must take turns in named evidence.
Use Simultaneous vs Alternating to test Full-Duplex vs Half-Duplex in the diagram at Figure 28.7. Then inspect FULL-DUPLEX as the final qualifier on duplex mode determines whether both sides can talk at once or must take turns. That sequence keeps under the hood: timing, edges, and electrical limits decide reliability tied to what is visibly labelled.
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.
28.3 Budget the Debug Port and the Display Separately
For an illustrative asynchronous debug connection at 9,600 bits per second, use one start bit, eight data bits and one stop bit per byte. Each useful byte therefore needs ten wire bits. A 40-byte line takes 400 divided by 9,600 = about 0.0417 s, or 41.7 ms, before gaps. Printing many such lines can block a simple program even though the sensor itself is slow.
Now assume the display accepts a synchronous serial transfer of 1,024 bytes at a 1 MHz clock, with one data bit per clock. The raw shift time is 8,192 divided by 1,000,000 = 0.008192 s, or 8.192 ms. Add command bytes, select timing and software pauses for the real transaction. The comparison explains why a clocked peripheral link can suit the display while the debug port remains simple and separate.
Read Figure 28.5 across point-to-point and shared-bus arrangements. A dedicated debug link confines many connection faults to one endpoint. A shared sensor bus saves pins but gives a stuck device a way to affect neighbours. The synchronous-versus-asynchronous figure then explains which timing comes from a shared clock and which comes from framing.
Predict whether moving the board-level bus down a long cable preserves these timing results. Extra capacitance, noise and ground differences can violate the interface’s electrical limits even when the bit-rate calculation still fits. Next, unplug one peripheral on the shared bus. Test whether the controller reports a timeout and continues useful work rather than waiting forever.
This module treats a wire as a local signal contract. Specify voltage levels, ground reference, connector, clock owner, device count and timeout behaviour alongside throughput. The calculations are useful upper-level budgets; a logic trace and the component timing requirements establish what the connected hardware actually tolerates. Choosing separate interfaces can make both debugging and failure containment easier without forcing every peripheral onto the fastest available option.
28.4 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.
28.5 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.
28.6 See Also
28.6.1 UART and RS-232
Study asynchronous point-to-point serial links, framing, voltage levels, and debugging.
28.6.2 I2C Protocol
Review two-wire addressing, pull-ups, bus loading, and shared sensor buses.
28.6.3 SPI Protocol
Explore clocked high-throughput peripheral links, chip select, and full-duplex transfers.
28.6.4 Wired Access: Ethernet
Connect board-level wired thinking to LAN-scale Ethernet, switching, and PoE.