USART stands for Universal Synchronous/Asynchronous Receiver-Transmitter. It’s a hardware peripheral built into microcontrollers that sends and receives serial data, one bit at a time, over just a few wires. What makes it “universal” is its flexibility: it can operate in asynchronous mode (like a standard UART) without a shared clock signal, or switch to synchronous mode where a clock signal coordinates the data transfer. You’ll find a USART in nearly every modern microcontroller, from Arduino boards to industrial embedded systems.
How a USART Sends and Receives Data
At its core, a USART contains two shift registers: one for transmitting and one for receiving. When you want to send a byte, your code writes it into a transmit holding register. The USART then loads that byte into the transmit shift register and pushes it out one bit at a time on the TX (transmit) pin. On the receiving end, incoming bits arrive on the RX (receive) pin and get shifted into the receive shift register until a full byte is assembled, at which point your code can read it.
A baud rate generator inside the USART divides the microcontroller’s main clock down to the desired communication speed. Standard baud rates include 9,600, 115,200, 230,400, and 921,600 bits per second. The most commonly used rate is 115,200, which works well for general-purpose data transfer. Higher rates like 230,400 or above are needed when you’re pushing larger amounts of data, such as sensor readings at 200 updates per second.
Asynchronous Mode: No Clock Wire Needed
In asynchronous mode, the USART works exactly like a UART. There’s no shared clock signal between the two devices. Instead, both sides agree ahead of time on the same baud rate, and the data itself carries timing information through start and stop bits.
Each chunk of data, called a frame, follows a specific sequence. The transmitter pulls the line low for one bit period to create a start bit, signaling that data is coming. Then it shifts out the data bits (typically 8), least significant bit first. After the data, an optional parity bit can be included for basic error checking. Finally, the transmitter pulls the line high for one or two bit periods to create the stop bit, marking the end of the frame. The most common configuration is “8N1”: 8 data bits, no parity, 1 stop bit.
This mode only requires two signal wires (TX and RX), making it simple to wire up and widely compatible. The tradeoff is that both devices must have their baud rates matched closely. Even a small mismatch causes communication errors.
Synchronous Mode: Clock-Driven Transfer
Synchronous mode is what separates a USART from a plain UART. In this mode, one device acts as the master and generates a clock signal on a dedicated clock pin (often labeled CK or XCK). The other device, the slave, uses that clock to know exactly when to read or write each bit. Data is shifted out on one clock edge and read in on the opposite edge.
Because the clock eliminates any ambiguity about timing, synchronous mode can run faster and doesn’t need start or stop bits wrapping every byte. This means less overhead per transfer. The cost is an extra wire for the clock signal and a fixed master/slave relationship. Some USART implementations can even operate as an SPI-compatible interface in synchronous mode, with configurable clock polarity and phase settings, which lets them talk directly to SPI devices like sensors and memory chips.
USART vs. UART
A UART is asynchronous only. It has two pins (TX and RX) and operates in full-duplex mode, meaning it can send and receive at the same time. A USART includes all of that capability plus synchronous mode, which adds a clock pin (XCK) and, in some implementations, a direction pin (XDIR) for controlling half-duplex communication. That brings the pin count up to three or four.
In practice, most people use a USART in its asynchronous mode, where it behaves identically to a UART. The synchronous capability is there when you need it, for faster transfers or for interfacing with clock-driven protocols, but it’s not something every project requires. If your microcontroller’s datasheet says it has a USART, you can treat it as a UART and ignore the synchronous features entirely.
Error Detection Flags
The USART hardware monitors incoming data for three types of problems, each flagged automatically so your code can respond.
- Frame error: The receiver expected a stop bit (a high signal) but saw a low signal instead. This usually means the baud rates don’t match or the connection is noisy.
- Overrun error: A new byte arrived before your code read the previous one, and the receive buffer was already full. The new data is lost. This happens when your code isn’t reading fast enough.
- Parity error: The parity bit didn’t match the data, suggesting one or more bits were corrupted during transmission. This flag only activates if you’ve enabled parity checking in your configuration.
These flags appear in a status register that your code (or an interrupt handler) checks after each received byte. They’re your first line of defense for diagnosing communication problems.
Hardware Flow Control
When one device sends data faster than the other can process it, bytes get lost. Hardware flow control prevents this using two additional signals: RTS (Request to Send) and CTS (Clear to Send).
The process works like a handshake. When one device wants to transmit, it pulls its RTS line low, telling the other device to start listening. The receiving device, when it’s ready to accept data, pulls its own RTS line low, which the sender sees on its CTS input. Only then does actual data transmission begin. Once the transfer finishes, the lines go back high. If the receiver’s buffer fills up, it simply doesn’t assert the ready signal, and the sender waits.
Flow control is optional. Many simple connections between a microcontroller and a sensor or GPS module work fine without it. But for high-speed or high-volume transfers where data loss isn’t acceptable, enabling RTS/CTS is a reliable solution that doesn’t require any special software logic.
Common Protocols Built on USART
The USART’s flexibility makes it the underlying hardware for several standardized communication protocols. Smart cards, for example, communicate using the ISO 7816 standard, which runs over a single bidirectional data line with even parity and 8-bit characters. Many microcontroller USARTs have a dedicated ISO 7816 mode that handles the timing and signal inversion required by smart card and security access module interfaces.
The LIN bus, used extensively in automotive systems for controlling things like mirrors, windows, and seat adjusters, also relies on USART hardware. LIN uses break character detection and auto-baud features that are built into modern USART peripherals, allowing a microcontroller to participate on a LIN network without additional communication chips. Beyond these, plain asynchronous USART communication is the backbone of GPS modules, Bluetooth serial adapters, RS-232 and RS-485 industrial links, and debug consoles on virtually every embedded platform.

