The Real Limits of Interrupt-Based UART RX

In many embedded system projects, UART communication appears reliable at first. Initial tests show no data loss, the system seems stable, and the topic is often considered resolved. However, once the baud rate is increased, the CPU frequency is reduced, or the system begins handling additional workloads, the same UART driver may suddenly start losing data.

In most cases, the root cause is not the UART hardware itself, but the software architecture on the RX path.

In this article, we analyze how far an interrupt-based UART RX approach can operate safely without using FIFO or DMA, supported by calculations, practical examples, and a professional BSP-oriented engineering perspective.

How Interrupt-Based UART RX Works

The interrupt-based UART RX model is widely used and appears straightforward at first glance:

• The UART peripheral generates an RX interrupt when a byte is received
• The CPU enters the interrupt service routine (ISR)
• Inside the ISR:
  • Status registers are checked
  • The RX data register is read
  • The received byte is written into a software buffer

This approach works well for low to moderate baud rates. However, there is a critical point that defines its limits:

Each incoming byte consumes CPU time. As this execution time increases or as bytes arrive more frequently, the system inevitably approaches its performance limits.

Why Problems Occur Without FIFO or DMA

When neither FIFO nor DMA is used, the UART RX path has very little tolerance:

• The UART peripheral continues to receive bytes
• If the CPU cannot service the RX interrupt in time:
  • An overrun occurs
  • Data is lost
• On the software side, this loss often happens silently

Without FIFO buffering or DMA offloading, the entire RX data path becomes strictly dependent on interrupt timing.

This behavior becomes particularly visible in:

• High baud rate communication
• Low CPU frequency configurations
• Multi-tasking or RTOS-based systems
• Environments with heavy interrupt traffic

ISR Execution Time vs Baud Rate - A Simple Calculation

To better understand the limitations, let us examine a simple but illustrative calculation.

Assumptions

• CPU frequency: 64 MHz
• UART configuration: 8N1 (1 byte = 10 bits)
• RX ISR execution time: 10 µs (including function calls, bit masking, and storing data into a software FIFO)

Byte Time per Baud Rate

Interpretation

• 115200 baud:
  • ISR time: 10 µs
  • Byte time: 87 µs
  • The CPU has approximately 77 µs available for other tasks
• 921600 baud:
  • ISR time: 10 µs
  • Byte time: 10.8 µs
  • The CPU is almost entirely occupied by UART RX processing

At this point, the system operates at the edge of its capabilities. Any additional delay, another interrupt, an RTOS context switch or a cache miss can easily result in data loss.

What Happens When CPU Frequency Is Reduced?

Now consider the same code and baud rate, but with a lower CPU frequency.

• CPU frequency: 64 MHz → 16 MHz
• ISR execution time increases approximately 4×
  • 10 µs → ~40 µs

As a result:

• At 115200 baud, the remaining time margin is reduced; safe operation still depends on interrupt latency and other system work
• 921600 baud becomes practically unusable
• RX overruns occur more frequently
• Data loss becomes sporadic and difficult to debug

This leads to an important engineering conclusion:

CPU frequency, ISR execution time, and overall system load must be evaluated together.

UART Polling vs Interrupt vs DMA

Let us briefly compare the three common UART RX approaches:

• Polling is simple but consumes excessive CPU time
• Interrupt-based RX is a balanced solution with clear limits
• DMA-based RX enables high throughput and deterministic behavior

It is important to correct a common misconception:

A Professional BSP Perspective

In industrial systems, UART drivers should never be designed for a single use case. A professional BSP architecture must support multiple scalable configurations, including:

• Interrupt-only
• Interrupt + FIFO
• DMA-based

This flexibility allows the same application code to run:

• On different MCUs
• At varying CPU frequencies
• Under different performance and system load constraints

without requiring modification.

Such an architectural approach prevents common field issues where identical firmware behaves inconsistently across different hardware platforms.

From Theory to Practice: BSP Development Training

Understanding UART performance limits at a theoretical level is important, but real value emerges when these concepts are applied in practice.

In professional BSP development, topics such as:

• Interrupt latency
• ISR execution time
• FIFO depth calculation
• DMA-based data flow
• CPU frequency scaling

are not isolated optimizations ; they are fundamental architectural decisions that directly impact system reliability, scalability, and long-term maintainability.

In our BSP Development Training , these concepts are not only discussed but implemented, measured, and analyzed on real hardware. Participants design UART drivers from the ground up, starting with an interrupt-based RX approach and progressively evolving the architecture to include FIFO buffering and DMA-driven data transfer.

Rather than relying on vendor-generated code or predefined HAL configurations, the training emphasizes:

• Understanding actual hardware behavior
• Making design decisions based on measurable constraints
• Building portable, scalable BSP layers across different MCU families

This hands-on methodology enables engineers to move beyond “it works” solutions and design communication subsystems that remain reliable under real-world operating conditions.

Conclusion

Although UART communication appears simple, it becomes a serious engineering challenge in systems requiring high performance and reliability.

• Interrupt-based RX works well up to a certain point
• As baud rate increases, mathematical limits emerge
• CPU frequency and ISR execution time are critical parameters
• For high speed and deterministic behavior, DMA is unavoidable