A debug console on a development board prints boot messages over two wires. No clock travels between the chips, no acknowledgement comes back, and nobody negotiated anything. Both ends were simply set to the same speed and format, and that is enough to carry text for decades. UART is what a protocol looks like when almost every question is answered with "nothing, by agreement in advance".
How does UART answer each question, and why does so little suffice?
Constraint | UART |
|---|---|
C1 Distance and medium | Short: a board or a short cable |
C2 Bandwidth and latency | Low: typically kilobits to a few megabits per second |
C3 Wires | Two signals (transmit and receive) plus ground |
C4 Topology | Point-to-point, full duplex (one line each way) |
C5 Who builds each side | Anyone; there is no single standard, only common conventions (fact S12) |
Each answer links to the lesson that explains the idea behind it.
# | Question | Answer |
|---|---|---|
1 | When is the data valid? | No clock is sent; both ends use the same agreed baud rate, and the receiver oversamples and re-aligns on each start bit, so clock error only has to stay small over one frame (1.2) |
2 | Where does a message start and end? | A start bit (0) begins each character and a stop bit (1) ends it; the line idles at 1 between frames (2.2) |
3 | Is the receiver ready? | None: the transmitter sends whenever it likes, a valid-only stream (3.1) |
4 | How much may I send before I hear back? | None in the frame; systems add RTS/CTS lines or XON/XOFF characters, both on/off flow control (fact S21) (4.2) |
5 | What exactly is being asked? | None: a UART moves bytes, and their meaning belongs to a higher layer (0.8) |
6 | How many requests can be in flight? | One character at a time in each direction; the receiver typically buffers a few in a FIFO (6.1) |
7 | In what order do results become visible? | Characters arrive in the order sent on a single wire, with nothing to reorder them (7.1) |
8 | Who gets the wire? | Nothing to share: each line has one transmitter (point-to-point) (8.1) |
9 | Why can it hang? | Nothing waits for anything, so nothing can deadlock; the price is that a receiver too slow to keep up loses characters (overrun) (9.2) |
10 | What if bits go wrong? | Optional parity detects a single flipped bit; a low stop bit is a framing error; there is no correction or retry (10.2) |
11 | How do the two sides agree at start-up? | No negotiation: both ends must be configured with the same baud rate, data bits, parity and stop bits beforehand (11.5) |
12 | How do we save power without losing data? | Not addressed by the protocol; the line simply idles high |
13 | What if there are several copies of one value? | Not applicable: there is no shared memory |
14 | Who is allowed to ask? | Not addressed: anyone with physical access can listen or send |
15 | How do we know it is correct? | No compliance programme; tests check frame formats, receiver tolerance to baud-rate mismatch, and overrun and framing-error handling (15.6) |
Timing from the data: the start bit's edge resynchronises the receiver every character, so cheap, independent clocks are enough (lesson 1.2).
Everything else by prior agreement: speed, format and even flow control are configuration, not protocol.
Errors detected at best: parity and framing errors are reported to software; nothing is resent.
A board (illustrative) ran its UART at 115,200 baud from a clock that was 4% off after a cheap oscillator was substituted. Short messages worked; longer bursts showed corrupted characters whenever the receiver's sampling point drifted past the middle of the last data bits. With the oscillator back within about 2%, the drift over one frame stayed inside the bit and the errors disappeared. UART tolerates clock error only because each frame is short.
The start bit's falling edge is the timing reference for the whole frame; without it the receiver cannot tell when a character begins.
Any two of: flow control, error recovery, configuration agreement, the meaning of the bytes.
UART needs no clock: each start bit re-aligns the receiver, so clocks only need to agree over one frame.
Handshake, flow control, negotiation and retry are all left to configuration or the system.
It works because rates are low, partners are configured together and lost characters are tolerable.