Uart

A UART, short for Universal Asynchronous Receiver-Transmitter, is a hardware circuit that converts data between a parallel form, the way a chip's internal logic handles bytes, and a serial form, one bit sent after another over a single wire — with no separate clock line at all, unlike I2C or SPI, which both require a shared clock signal to stay synchronized. That missing clock line is UART's defining trait, and it's exactly why both ends of a UART connection have to independently agree on timing in advance, through a shared baud rate, rather than one side continuously signaling the other when to sample each bit. How a UART actually sends one byte of data across a single wire with no shared clock at all looks like this:

A few things are worth knowing about why having no shared clock line forces both ends of a UART link to agree on timing in advance, and what happens when they don't:

Because a UART has no clock line to continuously signal exactly when to sample each bit, both the sender and receiver have to independently know the agreed transmission speed, the baud rate, in advance — and if that agreed rate doesn't match closely enough between the two sides, the receiver will sample at the wrong moments and reconstruct the wrong data entirely. The start bit's falling edge gives the receiver exactly one synchronization point per byte, a reference moment it uses to then count out the rest of that byte's bits purely by timing, based on its own internally agreed baud rate, without any further external clock help. If the two sides' baud rates don't match closely enough — say one side is configured for 9600 baud and the other for 19200 — the receiver's internal timing drifts increasingly out of step with where the actual bits really are as it counts through the byte, and the data that comes out the other end is simply wrong, often garbled into characters that look nothing like what was actually sent.

UART is strictly point-to-point between exactly two devices, with no built-in addressing scheme at all, which is a direct structural contrast to I2C's shared, addressed bus and a real limitation whenever more than two devices need to communicate on the same link. A single UART connection links exactly one transmitter to exactly one receiver on each wire, with no mechanism for multiple devices to share the same wire and take turns the way I2C's addressed bus allows — connecting a third device to the same UART wires doesn't create a usable multi-device bus, it just creates electrical conflict. This is exactly why systems needing more than two devices on one link reach for I2C or SPI instead, while UART remains the natural choice specifically for simple, direct point-to-point links, like a microcontroller talking to a single GPS module, a Bluetooth radio module, or a debug console, where exactly two devices genuinely is the whole requirement.

Despite being one of the oldest and simplest serial protocols still in common use, UART persists specifically because its asynchronous, clock-free design makes it uniquely well suited to situations where routing a dedicated clock wire alongside the data line would be impractical or impossible, such as longer cable runs or wireless-adjacent links. Protocols requiring a shared clock line, like SPI and I2C, need that clock signal to stay tightly synchronized across the physical connection, which becomes progressively harder to guarantee as cable length grows or as a link passes through connectors, adapters, or wireless bridging hardware — UART's reliance on pre-agreed timing alone, with no clock signal that needs to be routed and kept clean across the connection, sidesteps that problem entirely. This is a meaningful part of why UART remains the default choice for connections to external modules like GPS receivers, cellular modems, and Bluetooth radios, and why the venerable RS-232 serial port, built on the same underlying asynchronous principle, survived in industrial and embedded applications for decades after mainstream computing moved on from it.

A full UART frame is configurable across several independent parameters beyond just baud rate — data bits, parity, and stop bits — and getting every single one of those settings to match exactly between both ends is required before communication will work correctly at all, not just getting the baud rate right. A typical configuration, commonly abbreviated as something like "8N1," specifies 8 data bits, no parity bit, and 1 stop bit, but devices can also be configured for 7 data bits, various parity settings for basic single-bit error detection, or 2 stop bits instead of 1 — and if the two communicating devices don't agree on every one of these settings simultaneously, not just baud rate alone, the resulting data will be misinterpreted even if the baud rate itself happens to match perfectly. This is exactly why troubleshooting a non-communicating UART link, much like troubleshooting an SPI mode mismatch, typically starts with verifying that every configuration parameter on both ends matches exactly, not just the most obvious one.

Read a UART as timing-based synchronization substituting for a missing clock wire, not simply "the simple serial protocol": a start bit gives the receiver its only synchronization reference point per byte, with every remaining bit timed purely by a baud rate both sides had to agree on in advance, and that clock-free design is exactly what makes UART uniquely suited to point-to-point links where routing a dedicated clock signal alongside the data would be impractical — the same property that explains both its decades-long persistence and its real limitation to exactly two devices per connection.