28 Wired Communication Fundamentals

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.

Look at Figure 28.1 for how many wires each link needs and who is on the other end of them.

+

Trace the three links out from the controller in the middle of Figure 28.1. The first is a private pair between two devices, crossed so each one talks into the other’s ear, and nothing else shares it. The second is a shared pair that several peripherals sit on at once, which is what makes addressing and electrical loading a design problem rather than a wiring detail. The third spends more wires to buy speed and adds a select line for every device, so the wire count grows with the peripheral list. Now notice the connection drawn to every part: a common power and ground reference. Without it the other three prove nothing, because the signal levels have nothing agreed to be measured against.

Use Figure 28.2 to compare the performance gained from extra signals with their pin and routing cost.

+

Read from UART’s small signal count toward I2C’s shared clock and addressable bus, then SPI’s separate clock, data directions, and select lines. More wires can support full-duplex transfer, simpler timing, or higher throughput, but each pin consumes package, connector, and board-routing space. Device count changes the cost again: I2C shares two signals, while basic SPI usually adds a select per peripheral. The useful comparison is therefore not speed alone. Distance, traffic direction, pin budget, electrical loading, debugging access, and fault isolation decide whether the extra signals buy anything the product needs.