Serial protocols: UART, SPI, I2C

Three protocols coexist because serial communication has competing demands (speed, wire count, number of devices, and simplicity) and no single design optimizes all of them, so each protocol makes a different trade-off that's best in a different situation. UART optimizes simplicity for a point-to-point link: just two wires and no shared clock (both sides agree on a baud rate), which is dead simple and perfect for connecting two devices (an MCU to a PC for debug, to a GPS module), but it fundamentally only links two devices and its asynchronous nature means a baud-rate mismatch corrupts data. SPI optimizes speed: a shared clock makes it synchronous and fast, full-duplex (simultaneous send and receive), and simple per device: ideal for high-speed peripherals like displays, SD cards, and fast ADCs; its cost is wiring, because each additional slave needs its own chip-select line, so wiring grows with the number of devices and it doesn't scale gracefully to many peripherals. I2C optimizes wire efficiency for many devices: only two shared wires (data and clock) carry a whole bus of devices, each addressed by a unique address, so you can hang many low-speed sensors on the same two wires. Its cost is speed (slower than SPI) and a bit more protocol complexity (addressing, acknowledgement). So the trade-offs map cleanly: need a simple link between two devices? UART. Need raw speed to a few peripherals and can afford a wire per device? SPI. Need to connect many devices over as few wires as possible and can tolerate lower speed? I2C. This is the recurring engineering theme of fit-to-purpose: rather than one universal protocol that's mediocre everywhere, you have a small toolkit where you pick the one whose trade-off matches your situation's priorities (speed vs wires vs device count vs simplicity). Knowing all three and their trade-offs is what lets an embedded developer interface any peripheral well, which is exactly why they all persist and why the skill is choosing among them, not memorizing one.

UART's asynchronicity is the source of both its simplicity and its fragility, and contrasting it with the clocked protocols reveals what a shared clock actually does. In any serial link, bits are sent one after another on a wire, and the receiver must know ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍when to sample the wire to read each bit correctly. It has to align its sampling to the sender's bit boundaries. Synchronous protocols (SPI, I2C) solve this by sending an explicit clock line alongside the data: the clock signal tells the receiver exactly when each bit is valid, so the two sides are inherently synchronized and the data rate can be whatever the clock runs at, even varying, without confusion. UART omits that clock line (that's what 'asynchronous' means) which makes it simple (only two wires, TX and RX, no clock to route) and is why it's so convenient for basic point-to-point links. But without a shared clock, the receiver has no signal telling it when bits are valid; instead, both sides must independently agree in advance on the bit rate (the baud rate) and the receiver uses that agreed timing (plus start bits to mark the beginning of each byte) to guess when to sample. This is the fragility: if the two sides' baud rates don't match (or a side's clock drifts too far), the receiver samples at the wrong moments and reads garbage. The data is corrupted with no clock to fall back on. So UART trades the robustness and rate-flexibility a shared clock provides for the simplicity of fewer wires, at the cost of requiring exact pre-agreement on speed and being sensitive to timing mismatch. The deeper lesson is that a clock line is the mechanism that keeps sender and receiver synchronized bit-by-bit: synchronous protocols carry it explicitly (robust, rate-flexible, but an extra wire), while asynchronous UART replaces it with a pre-shared agreed rate (simpler wiring, but fragile to mismatch). Understanding this is why 'check the baud rate' is the first thing you do when a UART link garbles data, and why SPI/I2C don't have that particular failure mode.

The three serial protocols an MCU uses are like three ways to have a conversation. UART is like two people talking directly at an agreed pace, with no conductor: they just both agree beforehand how fast they'll speak (the baud rate) and then talk back and forth on two lines: dead simple, but it only works between two people, and if they disagree on the pace, it comes out as gibberish (a baud-rate mismatch garbles the data). SPI is like a fast conversation led by a conductor's beat: there's a shared clock (the conductor) keeping everyone perfectly in time, so it's quick and you can talk and listen at once, but to address each listener you need a separate 'attention' signal for each one (a chip-select per device), so the more listeners, the more 'attention' wires you string up. Great when you need speed with just a few devices (a fast display, an SD card). I2C is like a group on a shared party line: everyone shares just two wires, and to talk to someone you call them by name first (each device has an address) so the right one responds: ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍many people can share the same two wires, which is wonderfully wire-efficient for hooking up lots of sensors, but the shared, take-turns nature makes it slower than SPI. So you pick the conversation style to fit: two people, simple, agreed pace -> UART; fast, few listeners, with attention signals -> SPI; many sharing two wires, called by name -> I2C. Knowing all three and which fits is how an MCU talks to everything around it.

Protocol choices (match to situation):

Wiring summary: UART uses 2 wires to the PC; SPI uses ~4 wires to the display (clock, two data, chip-select); all the I2C sensors share the same 2 wires (SDA+SCL), each responding to its unique address, so adding more sensors adds ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍no extra wires, just more addresses on the bus.

How matching each protocol interfaces everything efficiently: - UART for the PC link: the situation is a simple two-device async link: UART is exactly that (TX/RX, baud rate), minimal and standard for debug. - SPI for the display: the situation needs speed. SPI's shared clock gives fast, full-duplex transfer ideal for a display; the single chip-select cost is trivial for one device. - I2C for the many sensors: the situation is many low-speed devices, few wires: I2C shares two wires among all the sensors (addressed), so you connect many without a forest of wires (accepting lower speed, fine for environmental sensors).

By choosing each protocol to fit its situation (simple link / speed / many-devices-few-wires), the node interfaces the PC, display, and all the sensors efficiently. The right speed and minimal wiring for each. This fit-to-purpose selection is the core skill of interfacing peripherals, and these protocols (using the MCU's UART/SPI/I2C peripherals, often with DMA) are how the embedded system talks to everything around it.