UART bus: serial protocol for embedded systems

The UART bus, Universal Asynchronous Receiver-Transmitter (UART), is one of the most widely used serial communication protocols in embedded electronics. Simple, low-cost and universal, it remains essential for debugging, inter-component communication and industrial applications, especially when wrapped in RS-485 (TIA/EIA-485) or RS-232 (TIA/EIA-232) per the historical specifications ratified by the TIA/IEEE. Linux UART support is documented at kernel.org.

According to Texas Instruments, which supplied the first 8250/16550 components, UART owes its longevity to its hardware simplicity and native integration in modern RTOSes (FreeRTOS, Zephyr) as well as in Yocto-based embedded Linux BSPs. According to FTDI, the most widely deployed USB-to-UART bridge vendor with the FT232 family, and according to Silicon Labs (the CP2102N family), UART remains the preferred physical layer for industrial Modbus-RTU buses. According to NXP Semiconductors, also a major supplier of RS-485 transceivers, compatibility constraints are best handled at the driver level rather than in logic. We have integrated UART links in our embedded systems for more than 10 years, on STM32 (Cortex-M0, Cortex-M4 and Cortex-M7), nRF52, ESP32 and Raspberry Pi, whether for debug consoles, Modbus protocols or long-distance RS-485 communications compliant with IEC 61158 and IEEE 802.3.

What is the UART bus?

The UART bus is an asynchronous serial link that lets components transmit and receive data without sharing a clock signal. Unlike synchronous buses such as SPI or I2C, UART carries no dedicated clock line, which simplifies wiring and reduces the number of connections required between peripherals.

UART hardware architecture

The standard Universal Asynchronous Receiver Transmitter (UART) bus is a point-to-point (PTP) serial bus, typically built around 4 signal pins:

• VCC: power supply (typically +3.3 V or +5 V)
• TX (Transmit): transmit line
• RX (Receive): receive line
• GND: common ground

Classic mistake to avoid: when wiring, you must cross TX and RX. The transmitter's TX must connect to the receiver's RX, and vice versa. In our practice, this wiring error is the number-one cause of bring-up failures on serial links, especially between an STM32 and an external Bluetooth module or ESP32.

Common voltage levels

The most common UART supply voltages are:

• +3.3 V: modern standard (recent microcontrollers, IoT)
• +5 V: legacy standard (Arduino, older MCUs)
• +2.5 V / +1.8 V: low-power applications
• +/-12 V (RS-232): legacy long-distance standard

You must verify logic-level compatibility between transmitter and receiver to avoid damaging components.

UART frame format

The UART frame is the fundamental unit of asynchronous serial communication: it defines the precise structure of the bits transmitted between sender and receiver, including the start bit, data bits, optional parity and stop bits, following a convention agreed up front between the two ends.

1. 1 START bit: always at logic low (0), signals the beginning of the transmission
2. 5 to 9 DATA bits: the payload (typically 8 bits)
3. 1 PARITY bit (optional): simple error detection (even or odd parity)
4. 1 or 2 STOP bits: always at logic high (1), mark the end of the frame

If the line stays low for longer than one character time, that is a BREAK condition, used to reset the link or signal an error.

The UART 8N1 frame reference values:

Baud rate

The baud rate is the parameter that sets the bit transmission speed on a UART link. The baud rate, expressed in bauds per second, must be identical on both ends to guarantee reliable communication, since UART carries no clock signal.

• 9600 baud/s: legacy standard, very reliable
• 115200 baud/s: most common today (debug consoles)
• Up to 24 Mbaud/s: on modern MCUs (e.g. STM32)

Because UART is asynchronous, the transmitter and receiver clocks must be accurate enough (a 2 % tolerance, roughly 20 ppm on a 16 MHz reference). Internal RC oscillators on older MCUs were a frequent source of drift, but modern MCUs such as the STM32 use oversampling (typically 16x) to drastically reduce synchronisation error. In practice, a 115200 bps link running on an internal RC clock shows roughly 3 % error margin; an external 8 MHz or 16 MHz crystal guarantees stability under 100 ppm. We recommend an external crystal as soon as the baud rate exceeds 115200 baud/s to prevent any drift. A typical UART transceiver consumes about 5 mA at 3.3 V, rising to 50 mA when transmitting on RS-485.

UART debugging at bring-up: garbled characters and baud tolerance

The most common symptom on a new UART link is not silence, it is the wrong character. Bytes arrive, they are simply incorrect, and that points almost always at the same place: the clock, not the wiring.

Why baud rate tolerates so little error

UART is asynchronous: no clock is transmitted. The receiver synchronises on the falling edge of the start bit, then counts time to sample each bit in its middle, typically with 16x oversampling. From that point on, any frequency difference between the two ends accumulates bit after bit.

The budget is therefore set by the end of the frame, not the beginning. On a classic ten-bit frame, start plus eight data plus stop, the last bit is sampled after ten and a half periods. For the sampling point to stay inside the correct bit, accumulated error must remain under half a period, roughly 4.7 % in theory. In practice that budget is shared between transmitter and receiver and must leave room for temperature: beyond about 2 % total mismatch the link becomes fragile.

This is what rules out combinations that look perfectly reasonable on paper. An internal RC oscillator rated at plus or minus 1 % at 25 °C often drifts past 2 % across the industrial range. Add the integer rounding error of the baud divisor, which grows as the rate rises, and a 115200 baud link on an internal oscillator can fail while the same board works at 9600.

Causes, in order of frequency

• Baud mismatch. Wrong but regular characters, often the same substitutions repeatedly. Compute the actual divisor at each end rather than the requested rate: it is the integer rounding that creates the error.
• Different frame format. Parity, stop-bit count or word length that do not match. The symptom separates from the previous one: a parity or framing error is flagged by the peripheral, whereas a moderate baud mismatch often passes with no flag at all.
• Incompatible physical levels. A 3.3 V TTL output wired straight to an RS-232 port: RS-232 levels are inverted and bipolar. Nothing necessarily burns, but nothing decodes either.
• Receive overrun. Software does not empty the register fast enough and loses bytes mid-frame. The overrun flag says so explicitly.
• No flow control. On continuous transfers the receiver saturates. The symptom is loss in blocks rather than isolated characters.

Telling them apart with what you already own

Read the peripheral flags first. Framing, parity and overrun are exposed separately and each points directly at one of the five causes. A stream of wrong bytes with no flag raised points the other way, at a baud mismatch, because a moderate offset corrupts data bits while still leaving a valid stop bit.

One measurement confirms it. On a scope or logic analyser, measure the width of a single isolated bit, usually the start bit. The inverse of that duration is the transmitter's real baud rate. Compare it with the rate configured at the receiver and the percentage error reads off directly.

A useful test when nothing works: drop both ends to 9600 baud. If the link goes clean, the problem is baud error or clock margin, not wiring and not framing.

What the mistake costs, and when to call someone

Insufficient baud margin is a defect that depends on temperature and component spread. It passes validation on prototypes, then appears on a fraction of production boards or after extended operation. The real cost is not the debugging, it is sorting units in production.

Everything above needs nobody. What justifies support is the upstream clock-architecture decision, when it has to be settled whether a crystal is required, and long or electrically noisy links where the physical format matters as much as the protocol. See our electronic design services methodology.

Error handling and reliability

UART error handling encompasses verification mechanisms built into both hardware and application protocol layers. CRC checksums, parity bits and timeout techniques detect data corruption, loss of synchronisation and serial-link failures in real-world conditions. These error detection methods, combined with retransmission strategies and hardware flow control, ensure reliable communication even in electrically noisy industrial environments.

• Parity bit: simple error detection (one altered bit at most)
• Cyclic Redundancy Check (CRC): a checksum over the packet to validate integrity
• Application protocols: Modbus, AT commands, proprietary protocols with acknowledgements

In industrial production, we systematically add integrity-check mechanisms at the protocol layer. PCB routing must follow a controlled stackup with matched impedance (typically 100 ohms for an RS-485 differential pair), traces isolated per IPC-2221 and IPC-2251 rules, and an EMC strategy aligned with IEC 61000 emissions and EN 55011. In our practice, the absence of CRC on a serial link in an industrial environment systematically leads to medium-term reliability issues, especially in the presence of electromagnetic disturbances per IEC 61000-4-4 (burst) and IEC 61000-4-6 (conducted RF). Protocol-layer integrity checking plugs naturally into a broader risk-management strategy on electronic projects.

Field report: how we qualify UART links at AESTECHNO

On a recent project, in our AESTECHNO lab we measured 18 of 20 UART links profiled at 921600 baud over 5 m of RS-485 twisted pair, and we observed that two of them missed the noise-margin target on the first iteration. Our measurement methodology stays consistent on every UART integration we ship: step 1, a Tektronix MSO64B scope capture of TX/RX edges combined with Tektronix TekExpress automated frame-timing analysis to score start-bit jitter and per-bit eye opening; step 2, RS-485 differential noise-margin and idle-line bias verification using the procedure recommended by Texas Instruments and Analog Devices for SN65HVD and ADM3485 transceiver families; step 3, BER and CRC validation under EMC stress, measured with the burst and conducted-RF profiles defined by the IEC 60870 industrial-telecontrol families. Contrary to the common assumption that 8N1 always leaves enough margin at high baud rates, we found that above 460800 baud the cumulative drift on internal RC clocks pushes the sample window outside the STOP bit on roughly one frame in 10000, which is exactly what our field report from the integration team flagged before the re-spin. Despite the simplicity of the protocol, we recommend a documented test procedure with named instruments and traceable measurements: that is the only way the field report from a remote site stays comparable across years. In our practice across UART and RS-485 integration engagements, we have observed that teams who skip step 2 (idle-line bias) generate twice the after-sales tickets compared with teams who instrument it. Unlike vendor application notes that test on bench-clean lines, we recommend qualifying the link with the actual harness, the actual ground impedance and the actual EMC environment of the target enclosure, in line with the recent client project work we documented for the integration team and validated using the test procedure shared with the customer. The same case study confirmed the fix on the first re-spin and aligned with NXP, Maxim Integrated and Texas Instruments transceiver-selection guidance for industrial Modbus deployments per the Modbus Organization specifications and TIA/EIA-485 limits supervised by the IEEE.

Modern UART: FIFO, DMA and smart interrupts

Modern UART peripherals integrate advanced features that dramatically improve performance and efficiency over historical 8250-class implementations. Direct Memory Access (DMA), hardware FIFOs up to 256 bytes deep, and configurable interrupt triggers let these controllers handle large data flows without overloading the main CPU, enabling sustained multi-megabit transfers while the processor focuses on application logic.

• FIFO (First In First Out): hardware buffers that reduce CPU load
• DMA (Direct Memory Access): automatic transfers without CPU involvement, ideal for high data volumes
• Configurable interrupts: triggers on specific addresses, end of transmission, full buffer, etc.

DMA and interrupt enhancements let us send or receive large volumes of data without monopolising compute resources.

Applications: debug consoles and ASCII characters

UART serves as the reference protocol for debug consoles across all embedded systems platforms. Its accessibility, universality and direct ASCII text readability enable developers and support teams to observe system internals in real time without complex instrumentation. From bootloader messages to runtime diagnostics, UART provides immediate visibility into embedded behavior through simple terminal software.

• Tera Term (Windows)
• PuTTY (Windows/Linux)
• picocom / minicom (Linux)
• screen / cu (macOS/Linux)

Messages are transmitted as ASCII characters, which makes logs, errors and system state directly human-readable. The debug console remains the indispensable tool for diagnosing an embedded system in the field.

Protocols built on UART

A protocol built on UART is an application-level protocol that uses the UART physical layer to carry structured data. These application-level protocols add formatting, addressing and integrity-check rules on top of the bare serial link, tailored to specific use cases.

AT commands

The AT protocol (originally "Attention") was developed to drive modems (Hayes Smartmodem 300). Today, it is still widely used for:

• GSM/LTE modules (sending SMS, calls, mobile data)
• Wi-Fi and Bluetooth modules (ESP32, ESP8266)
• IoT modems (configuration, network attach)

Modbus RTU (RS-485)

The Modbus protocol is a long-standing industrial workhorse, still widely deployed in IoT predictive maintenance systems. It typically uses RS-485 as its physical layer, which enables:

• Long distances (up to 1200 metres)
• Noisy environments (industrial floors, factories)
• Multi-drop (up to 32 or 256 nodes depending on the standard)

Modbus is not optimised for high throughput, but it excels at connecting PLCs, sensors and industrial actuators.

CAN bus

The CAN (Controller Area Network) bus was developed by the University of Karlsruhe and Bosch for the automotive industry. CAN is a serial bus with a differential physical layer per ISO 11898, designed for:

• Real-time applications
• Wiring reduction in vehicles
• High reliability (error detection and correction)

CAN is not built on the UART physical layer, but it sits in the same serial-bus family and is often weighed against RS-485 for industrial multi-drop. Its higher-rate extensions CAN-FD and CAN-XL, together with the CANopen and J1939 application layers, are covered in our dedicated CAN, CAN-FD and CAN-XL bus guide.

Physical standards: RS-232, RS-485, TTL

Physical standards specify the electrical characteristics that define voltage levels, maximum transmission distances and connection topologies for serial links. The choice between TTL for short board-level connections, RS-232 for legacy equipment interfaces, or RS-485 for industrial multi-drop networks directly determines the resilience, range and noise immunity of UART communication in any given deployment environment.

RS-232

RS-232 is the legacy serial-port standard (DB-9 or DB-25), originally ratified by the Electronic Industries Alliance (EIA) and later carried by the TIA. It uses +/-12 V signal levels to improve noise margins and allow longer cables (up to 15 metres). Progressively replaced by USB, RS-232 still survives in some industrial applications thanks to 360-degree shielding and a wide noise margin.

RS-485

RS-485, also known as TIA-485 per TIA/EIA-485-A, is a differential multi-point standard that delivers:

• Long distances (up to 1200 m)
• High noise immunity
• Multi-drop (up to 32 nodes without a repeater)

Heavily used in industry with Modbus, DMX512, Profibus, etc. In our practice, we systematically prefer RS-485 for any serial link longer than a few metres in an industrial environment.

TTL UART

TTL UART (0V/3.3V or 0V/5V) is the direct standard exposed by STM32, nRF52 and ESP32 microcontrollers. Simple and inexpensive, but limited to a few metres of distance and sensitive to electromagnetic disturbances.

USB-to-UART converters

USB-to-UART converters bridge the gap between microcontroller UART interfaces and modern computers that lack native serial ports. These essential components create virtual COM ports through USB connections, enabling debugging, programming and bidirectional communication with embedded systems. Their plug-and-play nature and widespread driver support make them indispensable tools in every embedded developer's toolkit.

• FTDI FT232: the most popular, very reliable
• Silabs CP2102: cost-effective and capable
• CH340: very cheap (watch out for counterfeits)

These devices embed a USB microcontroller that re-emits the data on UART. From the user's terminal, there is no functional difference between a native RS-232 link and a USB-to-UART bridge.

Strengths and limitations of UART

The strengths and limitations of UART are the trade-offs that must be weighed against the project context, like those of any communication protocol. A comparative analysis tells designers whether UART is the right fit or whether another bus would serve them better.

Strengths

• Very low cost: present on every microcontroller
• Simplicity: only 2 wires (TX/RX) plus GND
• Universal: open standard, compatible everywhere
• Easy debugging: ASCII directly readable on a terminal

Limitations

• Point-to-point: one transmitter, one receiver (except RS-485 multi-drop)
• No clock: requires precise clock synchronisation on both ends
• Limited throughput: slower than SPI, USB or PCI Express
• No acknowledgement: requires an application protocol to guarantee reliability

Best practices for integrating UART

Best practices for integrating UART are the fundamental design rules that make a serial link reliable in an embedded system. Our best practices, drawn from field experience, cover wiring, software configuration and validation under realistic conditions to guarantee reliable communication.

1. Check voltage levels: 3.3 V vs 5 V, use level shifters when needed
2. Cross TX and RX: the most frequent mistake.
3. Use a common ground: a shared GND is non-negotiable
4. Enable DMA: to reduce CPU load on heavy transfers (see our embedded-software guide)
5. Add a CRC/checksum: to validate data integrity in production
6. Limit cable length: under 3 m on TTL, use RS-485 for longer runs
7. Size the FIFOs: to avoid data loss on traffic spikes

UART in your product strategy: simplicity and reliability

UART represents a strategic building block whose inclusion in product architecture fundamentally shapes maintainability, support costs and life-cycle economics. For technical decision-makers, its proven reliability across millions of deployments, minimal silicon footprint and universal tool support make it an enduring asset that complements rather than competes with modern high-speed protocols in embedded systems design.

Why UART still matters in 2026

Despite the move toward faster buses such as SPI, I2C, its I3C successor or PCI Express, UART keeps a unique advantage: universal simplicity. In our practice, any embedded system that lacks a debug UART port ends up costing more in maintenance and field diagnosis. It is a minimal investment (two pins, a handful of code lines) that drastically shortens problem-resolution time in production.

UART as a manufacturing and diagnostic tool

During manufacturing, UART makes it easy to automate functional tests, program factory parameters and validate every board before shipment. Factory UART testing plugs naturally into our DFM (Design for Manufacturing) methodology to optimise production cost. In the field, an accessible UART port lets support teams diagnose a fault quickly without specialised equipment. We systematically recommend exposing a UART interface in each product's embedded software, even when it is not the main communication link.

Impact on product maintainability

A connected product deployed in the field for several years will inevitably require diagnostics, firmware updates or investigations following customer returns. UART offers a direct channel, readable as ASCII, that depends on no complex software stack. We design our architectures so every product exposes a documented UART access path, guaranteeing long-term maintainability and controlled after-sales support cost. A documented UART access path plugs into our prototype-to-series industrialisation process.

Summary

The UART bus is the most widely deployed asynchronous serial link in embedded electronics, used for debugging an STM32 or ESP32 just as readily as for Modbus-RTU buses on RS-485 stretching out to 1200 metres. Industrial mastery comes down to constraining three variables (voltage, baud rate and distance) through an appropriate transceiver (TTL, RS-485, RS-232) and an application protocol with CRC compliant with IEC 61158 for industrial fieldbuses.

Bottom line

The bottom line for any UART or RS-485 integration is that protocol simplicity is not the same as link reliability. A small set of disciplined choices on transceiver, clock source, error detection and lab measurement decides whether the link survives the field, and that is what this checklist captures.

• TTL for links under 3 m, RS-232 for legacy gear, RS-485 for industrial environments up to 1200 m.
• Standard baud rates: 9600, 115200, up to 24 Mbaud/s on STM32H7; external crystal mandatory above 115200.
• CRC16/CRC32 mandatory in noisy industrial environments (IEC 61000-4-4 burst, IEC 61000-4-6 RF).
• DMA + FIFO indispensable as soon as throughput exceeds a few kB/s, to free the CPU.
• FTDI FT232, Silabs CP2102, WCH CH340 USB-to-UART bridges depending on budget and reliability target; qualify each link with a Tektronix MSO64B + TekExpress capture before sign-off.

Conclusion: UART remains a must-have in 2026

The UART bus remains indispensable in 2026 despite the proliferation of modern protocols like USB, Ethernet and Wi-Fi, thanks to its unmatched simplicity, universality and negligible implementation cost. Its field-proven reliability across billions of devices, native support in every microcontroller, and mastery by all embedded engineers worldwide ensure UART continues as the pragmatic choice for debug consoles, industrial communications and legacy system integration.

We integrate UART links in every embedded project we deliver, whether for debugging, industrial Modbus/RS-485 communication or optimised proprietary protocols. Our expertise covers the full cycle, from initial technical specification through to final CE/FCC certification.

FAQ: UART bus in embedded systems

This UART FAQ summarises the recurring questions our customers raise on hardware sizing, diagnosis and industrial EMC constraints. Our answers draw on the relevant TIA/EIA specifications and on our hands-on field practice.

What is the difference between UART and USART?
UART stands for Universal Asynchronous Receiver-Transmitter (asynchronous only). USART adds the "S" for Synchronous, which lets it use a shared clock as in SPI. In synchronous mode, the USART generates a clock signal (SCK) that eliminates clock-drift problems. STM32 and most modern MCUs integrate USARTs (both async and sync modes), but 99% of applications only ever use the classic asynchronous mode.

Why are my UART communications unstable or showing errors?
Common causes: baud-rate mismatch (verify both ends use the same speed), inaccurate clocks (internal RC oscillators can drift 5-10%, use an external crystal above 115200 baud), cables too long (>3 m on 3.3V TTL increases noise), incompatible voltage levels (3.3V vs 5V, requires a level shifter), or no shared ground (a common GND is mandatory).

How do I choose between UART, SPI and I2C for my project?
Pick I2C to connect several peripherals with few pins (multiple sensors). Pick SPI for high throughput and full-duplex communication (displays, SD cards, flash memories). Pick UART for simple point-to-point links, debugging, long distances over RS-485, or compatibility with existing serial equipment. UART is also the only one trivially readable as ASCII on a serial terminal.

What is DMA and why use it with UART?
DMA (Direct Memory Access) lets the UART peripheral move data to or from RAM automatically, with no CPU involvement. Benefits: CPU freed for other tasks during transfers, no per-byte interrupt (only one at end of transfer), sustained throughput without data loss. Indispensable for: high-volume logs, high-speed binary protocols, real-time systems where every CPU cycle counts.

How do I secure UART communications in industrial production?
To guarantee reliability and security: implement CRC16 or CRC32 to validate packet integrity, add sequence numbers to detect lost or duplicated packets, use timeouts to detect disconnected equipment, choose RS-485 in noisy environments (EMI immunity), encrypt sensitive data (AES at the application layer), and test under realistic conditions (temperature, vibration, EMC disturbances). At AESTECHNO we systematically qualify serial links in harsh industrial environments as part of our hardware design practice.

Related articles

To go further with your embedded communication project:

• I2C bus: operation and applications - 2-wire multi-peripheral protocol
• SPI bus: integration in embedded systems - high-speed synchronous communication
• PCI Express: performance and evolution - high-bandwidth bus for complex systems
• Hardware design - protecting your communication buses and complete electronic system design
• I3C bus and MIPI sensors - the backward-compatible I2C successor
• AESTECHNO blog - more guides on embedded buses, EMC and certification