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:
UART RX performance is fundamentally limited by the ISR execution time per received byte.
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
| Baud Rate | Time per Byte |
|---|---|
| 115200 | ~87 µs |
| 921600 | ~10.8 µs |
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:
115200 baud is no longer a safe operating point
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:
Baud rate alone is not a meaningful metric.
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:
| Method | CPU Load | High Baud Rate | Reliability |
|---|---|---|---|
| Polling | Very high | ❌ | ❌ |
| Interrupt | Medium | ⚠️ | ⚠️ |
| DMA | Low | ✅ | ✅ |
- 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:
DMA is not a luxury or an optimization — it is a necessity for reliable high-baud-rate communication.
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
A robust UART design starts with architecture — not configuration tweaks.