UART Protocol: How Serial Communication Works and Where It’s Still Used (2026)

UART (Universal Asynchronous Receiver-Transmitter) is a hardware communication protocol that transfers serial data between two devices without a shared clock line, using predetermined baud rates and frame structures.

Early in my work with embedded systems, a GPS module I was integrating refused to produce readable data. The code was strictly correct and the power supply was stable. After two hours, I found that the problem was a baud rate mismatch. The microcontroller was configured for 9600 baud, while the GPS module was transmitting at 115200 baud.

Both devices were exchanging data the entire time, but neither could correctly interpret what the other was sending. This experience introduced me to something that every developer eventually learns: UART communication depends entirely on both sides agreeing on the same parameters before a single useful bit can be exchanged.

What UART Is and How It Differs From Other Serial Protocols

UART, or Universal Asynchronous Receiver-Transmitter, is a hardware communication protocol used to transfer serial data between two devices using two data lines and a shared ground. One line carries data from the transmitter to the receiver, while the other carries data in the opposite direction. Unlike I2C, UART doesn’t use a shared clock line. It’s asynchronous, which means timing isn’t coordinated through a shared clock signal between the devices. Instead, both sides operate independently at a predetermined bit rate.

This design eliminates the need for a clock line, making UART easier to implement and well suited for simple data communication. In contrast, protocols such as SPI and I2C require the clock signal to travel along with the data, which limits bus length and makes them less practical for long cables between separate devices. UART’s asynchronous design allows it to work reliably over longer distances when paired with suitable physical transceivers. That’s why it remains a fundamental protocol for sensor systems, GPS, solar monitoring interfaces, debugging consoles, and a wide range of embedded communication applications.

When I compare UART with the fieldbus protocols we use in factory control systems, the difference is straightforward. Industrial Ethernet protocols like PROFINET and EtherCAT are synchronous and high-speed, built for real-time PLC-to-robot communication. UART is simpler, slower, and doesn’t need a network master. But it’s everywhere—in the sensors that feed data into those same PLCs, in the GPS modules we integrate into fleet trackers, and in the serial consoles we use to debug Linux boards when nothing else responds.

How UART Frames and Sends Data

UART transmits data in units called frames. Each frame follows a defined structure, and both sides must be configured with the same frame parameters before communication can work correctly.

When no data is being transmitted on the line, it remains in an idle high state. This idle state is also a useful diagnostic signal. If the line is low when it should be idle, either the transmitter has failed or there’s a wiring fault.

A start bit begins each frame. The transmitter pulls the line from high to low for one bit period. The receiver detects this transition and begins sampling the subsequent bits at the configured baud rate.

Data bits follow the start bit. The standard configuration is 8 data bits, although 5, 6, 7, or 9 bit configurations may be used for specific applications. Data is transmitted least significant bit first. For the ASCII character S, binary 01010011, the first bit leaving the transmitter is the rightmost 1, not the leftmost bit.

The optional parity bit can provide basic error detection. It’s used to detect certain transmission errors by checking the number of 1 bits in the frame. With even parity, the parity bit is set so that the total number of 1 bits in the frame is even. Parity can reliably detect a single-bit error, but if two bits are corrupted, the error may go undetected. For more robust error detection, higher-level protocols typically implement CRC checks.

Stop bits end the frame. The line returns to the idle high state for one or two bit periods, signaling completion and giving both sides time to prepare for the next frame.

Baud Rate and Why UART Configuration Errors Are Usually Invisible

Baud rate is the number of bits transmitted per second and must be the same on both sides of a UART connection. Common rates include 9600, 19200, 38400, 57600, and 115200 baud, with some hardware supporting rates in the megabaud range.

One of the hardest UART configuration mistakes to detect is that the protocol provides no mechanism to indicate whether the received data is valid. The receiver accepts the incoming bits and attempts to interpret them as valid data. If the timing is correct, the data can be interpreted correctly. If the baud rates differ significantly, the receiver can decode the data incorrectly without providing any indication of what went wrong. Instead of completely failing during short communications, this can produce intermittent errors that can be difficult to isolate.

UART allows approximately 2 to 3% variation between the actual bit rates on each side. Clock drift under thermal loading, where the clock source shifts as the device heats up, can cause systems that initially work correctly to develop errors after continuous operation. When a UART link starts producing errors after running for an extended period, it’s worth checking the clock source for thermal drift.

UART receivers handle remaining timing variations through oversampling. Most hardware samples each bit multiple times, typically 16 samples per bit, and uses majority voting or a similar method to determine the bit value. This allows the receiver to tolerate small timing errors at the bit edges, but it doesn’t compensate for a significant baud rate mismatch.

UART Frame Configurations in Common Use

The most common ARM UART configuration is 8-N-1: 8 data bits, no parity, and one stop bit. This configuration appears in microcontroller libraries and serial terminal tools as a clearly labeled shorthand. It’s a good default configuration unless the datasheet specifies otherwise.

E-1-7 (7 data bits, even parity, one stop bit) appears in some older systems and serial terminal connections. Using 7 data bits limits the character set to standard ASCII characters, while parity is typically included in environments where longer cable runs make bit errors more likely due to noise.

9-bit UART is used in multi-drop bus protocols, where the ninth bit serves as an address flag. The receiver identifies a frame with the ninth bit set as an address, while a frame with the ninth bit cleared is identified as data. Devices on the bus ignore frames that aren’t addressed to them, allowing multiple receivers to share a single UART bus.

Two stop bit configurations are used for applications that require additional processing time between frames. Most modern microcontrollers paired with older or lower-speed hardware can generally operate reliably with one stop bit.

UART Physical Layer Standards: TTL, RS-232, and RS-485

UART defines the protocol but doesn’t specify voltage levels. The physical layer is determined separately, and mismatches between physical layer standards are one of the more common sources of hardware damage in embedded development.

TTL UART operates at the microcontroller’s native logic levels: 0V for logic low and 3.3V or 5V for logic high. This is the simplest physical layer and works for on-board connections or short cables. Connecting a 5V UART output to a 3.3V input without level shifting can permanently damage the receiving device. Connecting an RS-232 port directly to any TTL UART input will destroy the input—the voltage levels are incompatible and RS-232 voltages exceed the rating of standard logic inputs.

RS-232 uses inverted logic at higher voltages: logic 1 is represented by voltages between -3V and -12V, and logic 0 by voltages between +3V and +12V. A level converter such as the MAX232 is required to translate between RS-232 line voltages and TTL logic. RS-232 supports point-to-point connections up to approximately 15 meters at lower baud rates and remains in use for console ports on networking equipment and certain industrial machines.

RS-485 uses differential signaling: logic state is determined by the voltage difference between a pair of wires (A and B) rather than a single wire measured against ground. Common-mode noise affects both wires equally and cancels out when the difference is taken, giving RS-485 significantly better noise immunity. RS-485 supports cable runs up to 1200 meters, multiple devices on a shared bus, and data rates up to 10 Mbps on shorter runs. Industrial protocols including Modbus RTU, Profibus, and BACnet MS/TP use RS-485 as their physical layer.

On the factory floor, I’ve used portable oscilloscopes to debug RS-485 timing issues between PLCs and VFDs. The differential pair makes it more resilient than single-ended TTL in electrically noisy environments, but you still need to get the baud rate and termination right.

UART Compared to SPI and I2C

SPI is a synchronous protocol that uses separate data lines for each direction and a chip-select line for each peripheral device. It supports full-duplex communication and speeds of up to 10 megabits per second. It’s designed for high-bandwidth peripherals on circuit boards, such as displays, flash memory, and ADCs. However, each device requires a separate chip-select line, which means the number of devices that can be selected is limited without adding additional hardware.

I2C uses two lines, clock and data, and supports multiple devices on the same bus through addressing. Each device has a unique address, and the master initiates communication. I2C supports half-duplex communication and typically operates at 100 kHz or 400 kHz, making it suitable for lower-speed peripherals where high bandwidth isn’t required.

UART operates in an asynchronous mode, so it doesn’t require a clock line. It provides two-way communication between separate devices over a physical connection and can reliably work over longer distances with suitable transceivers. When two separate devices need to exchange data over a cable—such as a microcontroller and a GPS receiver, a cellular modem and a Bluetooth module—UART is a common solution. Rather than being alternatives to one another, embedded systems often use all three protocols for different purposes.

Applications Where UART Remains the Standard

USB-to-UART bridge chips (FT232R, CP2102, CH340) allow computers without native serial ports to communicate with UART devices. When a development board is connected to a laptop and appears as a COM port or /dev/ttyUSB device, a USB-to-UART chip is performing the translation.

Cellular modems in IoT devices expose a UART interface and accept AT commands. The modem handles radio-frequency communication; the host microcontroller communicates with it exclusively over UART. The same interface pattern applies to GPS receivers, Wi-Fi modules, LoRa radios, and Bluetooth modules in embedded designs.

The Linux serial console operates over UART. On embedded Linux boards, boot messages and the login shell are accessible through a UART port on the GPIO header. When a board fails to boot and network access is unavailable, the UART console is the primary diagnostic interface.

Modbus RTU, the dominant serial protocol in industrial automation, uses UART framing over RS-485. PLCs, variable frequency drives, sensors, and actuators from thousands of manufacturers communicate using this combination. A protocol standardized in 1979 continues to operate production equipment worldwide because the underlying UART and RS-485 combination is reliable, simple, and supported by hardware from every embedded electronics supplier.

In my experience wiring up servo drives and PLCs, the fieldbus gets all the attention—Profinet, EtherCAT, Ethernet/IP. But behind the scenes, UART is still doing the quiet work. It’s in the USB cable you use to flash firmware. It’s in the GPS module reporting location to your tracking server. And it’s in the Modbus RTU line running between a temperature sensor and a compact PLC in a remote pump house.

Key Takeaways

Frequently Asked Questions

About the Author

Michael Chen is an industrial automation engineer with 12 years of experience in PLC programming, SCADA integration, and machine vision deployment. He previously led automation upgrades at a Tier 1 automotive supplier in Michigan and holds Siemens TIA Portal Advanced and FANUC HandlingTool certifications. At Techynovate, he tests PLCs, sensors, and vision systems hands-on.