UART · Module 1

UART vs Other Interfaces: Choosing the Right Link

Serial interfaces differ first in where the receiver's timing comes from, then in what organises a shared medium — and capability is paid for in what the system must already provide. A question order for choosing between UART, SPI, I2C, CAN, USB and Ethernet.

Chapter 1.5 closed on an unresolved trade: the same absent requirements that let UART work during boot make it wrong wherever throughput, sharing, self-description or guaranteed delivery matter. This chapter turns that into something an architect can act on.

The usual way this comparison is presented — a table with a speed column — is close to useless, because speed is the axis along which the answer is most often already obvious and least often the reason for the decision. Nobody chooses between UART and Ethernet on throughput grounds; the situations where both are plausible are decided by something else entirely.

What actually separates these interfaces is structural, and Module 1 has already built the deepest of the axes. This chapter names them, places six interface families along them, and turns the result into a question order.

1. The Axis Module 1 Already Built

Chapter 1.2 established the most consequential question one can ask about a serial link: where does the receiver's sampling reference come from? Three answers exist, and essentially every serial interface belongs to one of them.

Figure 1 — the three clocking families. Reading left to right, the timing reference moves from a dedicated conductor, to prior agreement, to the data stream itself. Each step removes a wire and adds logic; the rightmost family buys rate and self-description at the cost of machinery that must work before the link exists at all.

The clock is sent. A dedicated conductor carries the sampling reference, generated alongside the data. SPI and I²C work this way. The receiver is told when to sample, so its logic can be modest — but a conductor is spent, and the reach is bounded by how well the clock–data relationship survives the journey rather than by the signalling alone.

The rate is agreed and no clock is sent. Both ends are configured to the same nominal rate in advance and the receiver constructs its own reference. UART works this way, and so does CAN, which additionally resynchronises from edges within a frame. No conductor is spent, and the cost is that a configuration mismatch corrupts data silently, with no mechanism in the link to detect the disagreement.

The clock is embedded in the data. The transmitter encodes the stream so that it is guaranteed to contain transitions, and the receiver recovers a timing reference from those transitions. USB and Ethernet work this way. It scales to rates the other families cannot approach and makes links largely self-describing — at the cost of line coding, recovery hardware, and a start-up sequence that must complete before any data moves.

🔍 Why this ordering is the useful one

Read the three families left to right and the same trade appears at every step: each removes something from the wire and adds something to the logic.

That matters because it predicts availability, which Chapter 1.5 identified as the property that decides whether an interface can be used when a system is not yet working. Logic that must run before a link exists is logic that can fail before the link exists. An embedded-clock interface needs its recovery and start-up machinery working before a single byte moves; an agreed-rate interface needs two configuration values.

So the axis that looks like it is about wires is really about what must already be true. That is why a boot console is a UART and not an Ethernet port, and it is not a statement about speed at all.

2. The Second Axis: What Organises a Shared Medium

Clocking decides how one receiver interprets one transmitter. The second axis decides what happens when more than two devices are involved, and it separates the families that the first axis groups together.

A shared medium needs three things, and an interface either defines them or leaves them to a layer above:

Addressing — some way for a transmission to identify its intended recipient. SPI does this out-of-band with a per-device select conductor. I²C, CAN, USB and Ethernet all carry an address or identifier inside the transmission itself. UART carries none.

Arbitration — some way to decide who may transmit. SPI has a single controller that simply decides. I²C and CAN both define genuine multi-controller arbitration resolved on the wire. USB is host-directed: devices transmit when asked. Ethernet on modern switched links largely sidesteps the question by giving each link two endpoints. UART defines nothing.

Error handling — detection, and a defined response. CAN is the strongest here, with frame-level acknowledgement, error signalling and fault confinement built in. USB and Ethernet detect errors and, at their own or a higher layer, retry. UART offers weak per-frame detection and no retry at all.

Chapter 1.4 showed that an electrical layer can make sharing physically possible for UART while supplying none of these three — which is exactly why a protocol like an industrial fieldbus has to be layered on top. The interfaces that define these things natively have already paid for them in complexity. Choosing one of them because sharing is needed is not a compromise; choosing UART and building the three yourself sometimes is.

3. The Comparison

Every row below is a starting hypothesis, generalised over a family with real variation inside it.

Interface	Clocking model	Typical signal conductors	Topology and arbitration	Throughput class	What the system must already provide
UART	Rate agreed in advance; no clock sent	2 (one per direction)	Two endpoints by default; sharing needs a different electrical layer and a protocol above	Low	Two matching configuration values
SPI	Clock sent by the controller	3 shared + 1 select per device	One controller, several targets, selected out-of-band; no arbitration needed	Moderate to high for a board-level link	A controller that decides; a select line per device
I²C	Clock sent by the controller, targets may stretch it	2 shared	Many devices on one pair; in-band addressing; genuine multi-controller arbitration	Low to moderate	Addresses assigned in advance; pull-ups
CAN	Rate agreed in advance; resynchronised within a frame	2 (one differential pair)	Multi-controller bus; priority arbitration on the wire; acknowledgement and fault confinement	Low	A controller with arbitration and error handling; bit-timing configuration
USB	Clock embedded in the data	2 (one differential pair) + power	Host-directed tree; devices enumerate and are addressed by the host	High	A host, a driver stack, enumeration, and working power
Ethernet	Clock embedded in the data	2 to 8 conductors depending on variant	Point-to-point links into switches; addressing and delivery handled by the stack above	Very high	A MAC, a PHY, link negotiation, and a protocol stack

Read the last column as the chapter's argument. It ascends roughly with capability, and each entry is a precondition that can fail. An interface requiring enumeration and a driver stack is unavailable in exactly the situation Chapter 1.5 described.

How to read the throughput column, and how not to

Throughput class is the least decisive column in the table, and it is placed second-to-last deliberately.

Two failure modes come from over-weighting it. The first is treating the classes as an ordering on quality — they are consequences of the other columns, not achievements. A link that embeds its clock can run fast because it spent the machinery to do so. The second is comparing across categories where the comparison has no meaning: the question "is SPI faster than Ethernet" has no useful answer, because nothing in any real system is decided by it.

The useful version is a threshold, not a ranking: does the required rate exceed what this family can reach? If yes, that family is eliminated. If no, throughput is finished as a criterion and the decision belongs to the other columns.

4. A Question Order

The table becomes a procedure when the columns are applied in the order that eliminates most effectively. Asking these in sequence resolves most decisions in three questions.

One — must the link work before the system does? If the interface is a boot console, a diagnostic channel or a bring-up aid, availability dominates everything, and the families requiring enumeration, negotiation or a driver stack are eliminated first. This question alone frequently ends the discussion.

Two — how many devices share the medium, and who decides who talks? Two endpoints leave every family viable. More than two eliminates plain UART unless a protocol layer is being built deliberately, and makes the interfaces with native addressing and arbitration the natural starting point.

Three — does the required rate exceed what remains? A threshold test, per the callout above. It usually eliminates nothing that questions one and two have not already settled, which is precisely why leading with it produces poor decisions.

Then the secondary considerations: distance and electrical environment, which are a physical-layer question (Chapter 1.4) rather than a framing one; the software stack the target platform already has; and the verification and bring-up cost of the interface itself.

The cost engineers under-count

Interface choice is usually discussed as a hardware decision, and the recurring estimation error is ignoring what each choice costs to develop and verify.

A UART's verification surface is small: framing, timing and configuration, as this curriculum's later modules show. An interface with enumeration, addressing, arbitration and error recovery has a verification surface that includes every state machine implementing those, along with their interactions — and a bring-up story where a failure can originate in any of them.

That cost is worth paying when the capability is needed. It is a poor trade when it is not, and it is the main reason a simple link survives in systems whose every other interface is more capable: the simplest thing that meets the requirement is usually also the thing you can prove works.

5. Three Decisions, Worked

A sensor on the same board, read a few times a second, with pins scarce. Question one does not apply. Question two: two endpoints. Question three eliminates nothing. Everything is viable, so the decision falls to secondary factors — and pin cost points at I²C, which shares two conductors across many devices, over SPI, which spends a select conductor per device. If the sensor happens to offer only one of them, the decision was already made by the part. This is the common case where the interface the component provides legitimately outranks architectural preference.

A status channel from an FPGA to an engineer's laptop. Question one dominates: this must work when the design does not, which eliminates anything needing negotiation inside the FPGA. Question two: two endpoints. Question three: a human reads the output, so the rate requirement is trivial. UART, and the USB complexity is absorbed by a bridge that the FPGA never sees (Chapter 1.5). Notice that the link the laptop sees is USB — the choice was about which side of the bridge the design sits on.

Twenty nodes distributed around a vehicle, exchanging short messages, where a failing node must not take the system down. Question one does not apply. Question two is decisive and rules out plain UART: many devices, no central controller, and a requirement — fault confinement — that is a protocol feature rather than a wiring one. CAN defines priority arbitration, acknowledgement and fault confinement natively. Building those on UART over RS-485 is possible (Chapter 1.4) and means implementing and verifying what CAN already specifies.

6. Where the Comparison Stops Being Useful

Three honest limits, because a comparison chapter that does not state them teaches overconfidence.

Family names hide enormous variation. "SPI" covers arrangements differing in edge conventions, data width and transfer structure; "Ethernet" spans conductor counts, reach and rate classes that have little in common. Any row above can be wrong for a specific part, and the table is a hypothesis to check rather than a fact to cite.

The component often decides. A sensor offering one interface has settled the question. Architectural preference matters when designing both ends, and at the system's boundaries it frequently does not apply at all.

Systems use several, and the interesting engineering is at the boundaries. A real product has a high-rate link for data, a low-rate one for control, and a diagnostic channel that works when the others do not. The recurring question is therefore rarely "which one" but "which one here" — and the bridges between them, like the USB-to-serial bridge in Chapter 1.5, are where the layering from Chapter 1.4 earns its keep.

7. Understanding Check

8. Summary

Serial interfaces are not points on a speed scale. They differ first in where the receiver's timing comes from, and the three answers — the clock is sent, the rate is agreed in advance, the clock is embedded in the data — order the field better than any performance figure. Each step along that order removes a conductor and adds logic, which means it also measures what must already be working for the link to exist.

The second axis is what organises a shared medium: addressing, arbitration and error handling. An interface either defines them or leaves them to a layer above. UART leaves all three, which is why sharing requires both a different electrical layer (Chapter 1.4) and a protocol built on top.

Those two axes produce a question order that settles most decisions before throughput is considered: must the link work before the system does; how many devices share the medium and who decides who talks; does the required rate exceed what remains. Throughput is a threshold test, not a ranking, and leading with it produces poor decisions.

The recurring conclusion is that capability and availability are in tension. An interface that can do more requires more to be true before it does anything, and the machinery buying that capability is also a verification and bring-up cost. UART sits at the low-capability, high-availability end — which is why it is the wrong choice for moving data and the right one for the channel that has to work when moving data is not yet possible.

Finally, the comparison has limits worth carrying: family names hide large variation, the component at one end often settles the question outright, and real systems use several interfaces at once, so the live question is almost always "which one here".

9. What Comes Next

Module 1 is complete. A UART is a converter between parallel data and timed line activity; its receiver builds a sampling reference from a configured rate, an event in the signal and its own clock; the link is two independent one-way conductors with a defined idle level; the electrical layer below is a separate choice that decides reach and topology; the whole arrangement survives because it asks almost nothing of the system around it; and it is chosen — or rejected — on availability and sharing long before speed.

Every one of those statements has depended on a question this module deliberately refused to answer: two clocks that were never synchronised and drift apart — how does that work at all?

Module 2 answers it. It establishes the bit as a unit of time, shows how a receiver reconstructs a bit grid from a single alignment event, quantifies how oscillator error accumulates across a frame, and derives where the sampling margin actually comes from. Everything after it — baud generation, receiver architecture, error behaviour — is built on that arithmetic.

Browse the full path on the UART tutorials index. For the comparison's nearest neighbour treated from the other side, SPI vs UART approaches the same clocking distinction from a forwarded-clock interface's perspective.

Continue learning

Where this fits

Part of the UART curriculum.