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

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.

In other words, the UART protocol is nothing more than a mutual agreement on timing, voltage, and frame format. When either side breaks that agreement, the data is garbage. No exceptions.

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 does not use a shared clock line. It is asynchronous, which means timing is not 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. This is why it remains a fundamental protocol for sensor systems, GPS, solar monitoring interfaces, debugging consoles, and a wide range of embedded communication applications.

For a deeper technical background on how asynchronous serial standards evolved, Wikipedia’s UART article covers the original Teletype roots and the framing conventions that still define modern implementations.

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 is 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 the least significant bit first. For the ASCII character S, binary (1010011), the first bit leaving the transmitter is the rightmost 1, not the leftmost bit.

The optional parity bit can provide basic error detection. It is 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 is 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 does not compensate for a significant baud rate mismatch.

UART Frame Configurations in Common Use

The most common ARM UART configuration is N-1-8 : 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 is 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 are not 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 does not 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.

If you are verifying signal levels on the bench, a reliable digital multimeter is the first tool I reach for before connecting anything expensive to an unknown port.

For more detail on the electrical characteristics that separate RS-485 from TTL, Analog Devices’ RS-485 guide breaks down differential signaling, termination, and cable requirements with oscilloscope plots from real hardware.

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 is 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 is not required.

UART operates in an asynchronous mode, so it does not 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.

On the factory floor, we still use oscilloscope testing to catch signal-integrity issues on long RS-485 runs that a multimeter simply cannot see.

For anyone integrating motion systems alongside serial networks, our guide on servo drive system integration explains how the control layer ties into the same Modbus RTU buses that carry UART frames.

Conclusion

UART’s design is deliberately minimal. Beyond an optional parity bit, there is no clock line, no addressing, and no built-in error correction. Both devices agree on the baud rate, frame format, and wiring, and then transfer data.

That simplicity is exactly why the UART protocol remains the default choice for embedded engineers in 2026.

The baud rate mismatch that caused me to lose two hours early in my career would have been caught immediately if I had known to check the parameters on both sides first. That lesson has stayed with me ever since: before troubleshooting anything, verify that both sides are configured consistently. This applies to any new hardware device being introduced into an existing system, regardless of how much experience you have.

Key Takeaways

• UART protocol is asynchronous: no shared clock line, just TX, RX, and ground.
• Baud rate must match on both sides within 2–3 % tolerance; mismatches produce silent data corruption with no error flag.
• The most common frame format is 8-N-1: 8 data bits, no parity, one stop bit.
• TTL, RS-232, and RS-485 are physical layers that carry UART frames at different voltages and distances.
• UART remains the backbone of Modbus RTU, GPS modules, cellular modems, and Linux serial consoles in 2026.

UART Protocol: Frequently Asked Questions

What distinguishes UART from RS-232 and RS-485?

UART is the protocol framing, timing, and bit structure. RS-232 and RS-485 are physical layer standards that carry UART signals at different voltage levels and over different topologies. RS-232 uses high single-ended voltages and supports point-to-point connections up to 15 meters. RS-485 uses differential signaling and supports multi-device buses over distances up to 1200 meters. A UART module in a microcontroller can interface with either standard using the appropriate level converter or transceiver.

Why must both sides of a UART connection use the same baud rate?

UART does not use a clock line, so the receiver samples incoming bits using its own internal clock. If the receiver’s sampling rate does not match the transmitter’s bit rate, the receiver samples bits at the wrong moments and reads incorrect data. The protocol provides no handshaking to detect or signal this mismatch the receiver simply interprets whatever arrives as valid data. Small mismatches within the 2-3% tolerance may produce occasional errors; large mismatches produce completely unreadable output with no indication of the cause.

What can the UART parity bit detect, and what are its limitations?

The parity bit detects single-bit error cases where exactly one bit in the data frame changed state during transmission. If two bits are corrupted simultaneously, the parity check passes incorrectly and the error goes undetected. Parity is frequently disabled in systems where the application protocol provides CRC checking or other more reliable error detection.

In what situations is UART more appropriate than SPI or I2C?

UART is appropriate for communication between separate physical devices connected by cables, particularly when those devices are not on the same circuit board. SPI and I2C are synchronous protocols designed for short-distance chip-to-chip communication on PCBs. UART’s asynchronous design, combined with physical layer options like RS-485, makes it suitable for the longer distances, noisier environments, and separate-device configurations where SPI and I2C are not practical.

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.