EC-9.5 Serial Buses: UART, SPI, I2C and CAN

What this is and why it exists

Nearly every sensor, display and memory a small system talks to arrives on one of four buses. The choice is usually made by the part rather than by you.

What is left to you is knowing what each one costs in pins, in speed and in distance. The fourth cost is how it behaves when something goes wrong. That is what turns reading a datasheet into a design decision instead of a copying exercise.

The vocabulary

• Serial bus — a connection carrying bits one after another over few wires.
• Baud rate — the signalling rate agreed in advance on a link with no shared clock.
• Start bit — a leading bit that lets a receiver line itself up with the sender.
• Chip select — a line that tells one device on a shared bus that a transfer is for it.
• Acknowledge — a bit sent by a receiver to confirm a byte arrived.
• Clock stretching — a receiver holding the clock line low to delay the sender.
• Arbitration — the process by which several senders starting at once resolve who continues.
• Differential pair — two wires carrying opposite signals, read as the difference between them.

The mental model

First, why serial at all. A parallel connection sends eight bits at once and is fast, and it spends a pin for every line. Pins are the scarcest thing on a small package, and for a temperature sensor read once a second there is time to spare. Trading time for pins is almost always the right trade at this scale.

Now the four, in order of how much they assume.

UART assumes the least: two wires, one in each direction, and no clock between them. Both ends are configured for the same rate in advance. A start bit tells the receiver when a byte begins, and the receiver then samples at intervals it generates itself.

The consequence is a tolerance requirement. If the two ends disagree about the rate by more than a few per cent, the sampling drifts across the byte. The data then becomes rubbish. That is why the clock source topic matters here. A part running on an imprecise internal oscillator has trouble at some rates and not others.

UART has no addressing at all. Two devices, one link. Anything more needs a protocol layered on top.

SPI adds a shared clock, which removes the rate agreement entirely. The sender provides the clock, so any rate up to the slowest device's limit works. Two data lines carry the two directions at once, which makes it the fastest of the four by a wide margin.

The cost is a chip select line per device. Three devices is comfortable. Twelve devices is twelve pins spent on selection, and that is where SPI stops being the obvious choice. SPI also has no acknowledgement and no error detection of any kind. A device that is absent, unpowered or wired wrongly returns a plausible-looking value, usually all ones or all zeros.

I2C takes the opposite trade: two wires total, whatever the number of devices, with each device having an address. Every byte is answered by the receiver pulling the line low for one bit, so the sender learns whether anything is listening.

A missing acknowledgement is the most useful diagnostic in embedded work. It tells you immediately that the device is absent, unpowered, or at a different address than you thought. That is distinct from a device answering with unexpected data.

The two lines are open drain with pull-up resistors, which is what allows any device to hold a line low. It also allows a slow device to stretch the clock while it thinks. The same property means one stuck device can hold the bus and stop everything, which is the characteristic I2C failure.

CAN is the outlier and it was designed for vehicles. It uses a differential pair over tens of metres, tolerates severe interference, and expects several senders to start at once.

Arbitration is the elegant part. The bus is wired so that a dominant level wins. A sender that transmits a recessive bit and sees a dominant one knows it lost, and stops. The message with the lowest identifier continues without any data being corrupted and without any time being wasted. No collision, no retry, and the priority is built into the identifier.

CAN also carries proper error detection, acknowledgement and automatic retransmission, which is what you want when a lost message is a brake command.

Choosing between them comes down to four questions. How far does the signal go? How many devices? How fast? And what should happen when a device fails? SPI answers the third best and the fourth worst. I2C answers the second best. CAN answers the first and fourth best and costs a transceiver. UART answers none of them well and is the simplest thing that can work.

What you should now be able to explain or do

• Explain why serial buses dominate at this scale despite being slower than parallel.
• Say what makes a UART link fail when the two clock sources disagree slightly.
• Weigh the pin cost of SPI selection against its speed advantage.
• Use a missing I2C acknowledgement as a diagnostic and say what it rules out.
• Describe CAN arbitration and why it wastes no time when two senders start together.
• Choose a bus for a given distance, device count, speed and failure requirement.

Check yourself