32 UART and RS-232 Protocols

networking-core

wired

comm

uart

32.1 Start With Two Devices Sending Bytes

UART is the simplest useful story for many devices: one side sends timed bits, the other samples them, and both must agree on framing and speed. There is no shared clock wire to rescue a mismatch.

That simplicity is why UART is common for consoles, sensors, modules, and debugging. It also means the evidence must be practical: voltage level, ground reference, baud rate, framing, and what each received byte is supposed to mean.

Overview: UART Sends Bytes Without A Clock Wire

UART is the simple asynchronous serial link used for debug consoles, GPS receivers, radio modules, bootloaders, and many board-to-board IoT connections. One wire transmits, one wire receives, and a shared ground gives both devices the same voltage reference.

The simplicity has a condition: both ends must already agree on baud rate, frame format, logic voltage, and flow-control behavior. UART does not carry an address, a clock, or a built-in retry scheme, so wiring and configuration mistakes show up as silence or garbled characters.

The design boundary is the important lesson. A microcontroller UART peripheral defines byte timing and framing; it does not define connector shape, cable robustness, message boundaries, or safe voltage levels. TTL UART on a board may idle at 3.3 V or 5 V logic. RS-232 inverts the logic and uses higher positive and negative voltages through a transceiver. RS-485 can carry UART-style bytes over a differential multidrop electrical layer, but then direction control, termination, and bus ownership become part of the release record.

For IoT products, UART is strongest as a local service, configuration, or module link: a boot console, GPS NMEA stream, AT-command modem, serial sensor, or factory programming port. It becomes fragile when teams treat it as a complete protocol. If bytes can be lost, delayed, or inserted during reset, the application needs explicit message framing, checksums, timeouts, retry rules, and buffer-overflow behavior above the serial link.

UART is point-to-point: TX on one device must reach RX on the other, and both sides need a common ground.

A receiver synchronizes on the start bit, samples the data bits by timing, optionally checks parity, then waits for the stop bit.

Frame Format

8N1 means 8 data bits, no parity, and 1 stop bit. With the start bit included, one data byte uses 10 bit times on the wire.

Baud Rate

Both devices must sample at the same bit timing. Common IoT settings include 9600 for sensors and 115200 for debug consoles.

Electrical Layer

TTL UART, RS-232, and RS-485 can carry similar serial bytes, but their voltages and wiring are not interchangeable.

Boundary to remember: UART describes the byte framing. RS-232 describes an older electrical interface with inverted, higher-voltage signaling. A microcontroller UART pin is not an RS-232 port unless a level shifter is present, and a working USB serial adapter test does not prove the final harness, grounding, or enclosure routing.

Practitioner: Keep A Serial Link Record

A dependable UART build has a short record: the electrical standard, connector or pinout, frame setting, baud rate, cable length, flow-control choice, and a known-good test message. Without that record, teams waste time swapping wires, guessing defaults, and blaming software for electrical faults.

Make the record executable. It should say exactly which endpoint is DTE or DCE when RS-232 language is used, which side of a connector drawing is shown, whether the port is 3.3 V tolerant, and whether RTS/CTS is wired or intentionally unused. If a legacy peer depends on DTR/DSR-style readiness, record whether DTR must be asserted for the whole transfer or tied through the connector; otherwise the data line can look correct while the peer refuses to send or receive. For field devices, include the installed cable length, shield or drain treatment, enclosure pass-through, and the highest sustained burst rate that the receiver can absorb without losing bytes.

RS-232 uses inverted high-voltage signaling; it must be translated before it reaches normal 3.3 V or 5 V microcontroller UART pins.

Connector diagrams must state the viewing side. Mirrored DB9 views are a common source of swapped TX/RX pins.

Record Field

What To Capture

Common Failure

Verification Step

Electrical Standard

TTL UART, true RS-232, or RS-485; logic voltage; required converter.

Connecting RS-232 voltage directly to a microcontroller GPIO.

Measure idle voltage before connection and confirm a level shifter where needed.

Frame Setting

Baud rate, data bits, parity, and stop bits, such as 115200 8N1.

One side uses parity or a different baud rate, producing readable-looking garbage.

Capture a known byte pattern or readable line at the configured setting.

Wiring

TX-to-RX crossover, RX-to-TX crossover, shared ground, cable length, connector side.

TX tied to TX, no common ground, or a mirrored connector pinout.

Use loopback first, then confirm idle, start, and stop states with a logic analyzer.

Flow Control

None, RTS/CTS, or software XON/XOFF; buffer size and sustained stream rate.

Receiver buffer overflow during continuous logs or firmware-style transfers.

Run a sustained transfer and check dropped bytes, pauses, and buffer high-water marks.

A low-speed link that works on the bench can still fail in a product when cable length, ground offset, oscillator tolerance, EMI, connector orientation, missing flow control, or a 5 V to 3.3 V mismatch eats the signal margin. The release test should use the final cable and a sustained message pattern, not only a short terminal echo.

Under The Hood: Timing Error Accumulates Across The Frame

UART receivers usually resynchronize on the start edge, then sample near the center of each bit period. Because there is no shared clock, any transmitter and receiver timing error accumulates until the frame ends. Longer frames, poor oscillators, noisy edges, and high baud rates all reduce the margin.

A receiver commonly oversamples the line, detects the falling start edge, waits toward the center of the first data bit, and then samples each following bit at the configured interval. If the local clock is too fast or too slow, those sample points drift. In an 8N1 frame the receiver only needs to stay aligned for one start bit, eight data bits, and one stop bit, then it can resynchronize on the next start bit. That is why moderate clock error can work for short frames but fail with long words, parity, two stop bits, or marginal edges.

Asynchronous serial links depend on both endpoints keeping close enough timing until the stop bit is sampled.

In 8N1, every byte consumes 1 start bit, 8 data bits, and 1 stop bit. At 9600 baud, that gives about 960 data bytes per second before protocol overhead. At 115200 baud, the byte rate is about 11,520 bytes per second, but electrical and timing margin become more sensitive to cable and oscillator quality.

Throughput is not only baud divided by frame length. A real product may pause between messages, wake a modem, wait for line turnaround, process AT responses, or copy bytes through interrupt handlers into a ring buffer. If the consumer task stalls, bytes can overrun even when the electrical link is perfect. That is why serial diagnostics should log framing errors, parity errors, overrun counts, buffer high-water marks, and message checksum failures separately.

UART trades addressing and shared-clock features for a simple point-to-point byte stream.

Clock Error

Keep combined transmitter and receiver error to only a few percent across the whole frame; crystal-based clocks usually make this easier than uncalibrated RC clocks, especially across temperature.

Signal Integrity

Cable capacitance, weak drivers, poor grounds, connector oxidation, and EMI slow edges or shift thresholds, especially at higher baud rates.

Error Handling

Parity can detect some single-bit errors, but robust IoT protocols still need message framing, checksums, sequence or length fields, timeouts, and retry behavior above UART.

32.2 Summary

UART is a simple asynchronous byte stream for IoT debug consoles, sensors, modules, and legacy equipment. It works when both sides agree on baud rate and frame format, TX/RX are crossed with a shared ground, the electrical layer is compatible, and sustained traffic has an overflow strategy. RS-232 is not the same as a microcontroller UART pin; translate the voltage before connecting it.

32.3 Key Takeaway

Treat every serial link as a record of framing, timing, wiring, voltage, and evidence. Most UART failures are not mysterious protocol bugs; they are mismatched settings, unsafe voltage levels, missing ground, weak timing margin, or unchecked buffering.