Blocking vs non-blocking driver design — what are the tradeoffs?

A blocking driver holds the CPU in a polling loop until the operation completes. For UART transmission, this means spinning inside uart_send() until the last byte has shifted out of the transmit data register. The advantage is simplicity — the function returns only after the data is fully sent, so the caller knows the operation is done and can immediately reuse the buffer. No callbacks, no state machines, no concurrency concerns.

The downsides are severe in production systems. First, the CPU is 100% idle during the transfer — a 100-byte UART transmission at 9600 baud takes roughly 100 ms, during which a 72 MHz Cortex-M4 wastes approximately 7.2 million clock cycles doing nothing. Second, blocking inside an ISR is catastrophic — it prevents lower-priority interrupts from being serviced and can trigger a watchdog reset if the watchdog timeout is shorter than the transfer time. Third, blocking breaks real-time guarantees — if a motor control loop must execute every 50 microseconds but a blocking SPI transfer takes 200 microseconds, you miss three control deadlines.

Non-blocking drivers use interrupts or DMA to perform the transfer in the background. uart_send() copies data into a ring buffer, starts the DMA, and returns immediately. The completion is signaled via a callback, a flag, or an RTOS semaphore. This is the production-grade approach because it keeps the CPU available for computation and maintains deterministic timing for real-time tasks. The cost is complexity: you need buffer management, ISR-safe data structures, and careful handling of concurrent access between the ISR and the main application. You also need to track whether a previous transfer is still in progress before starting a new one. Despite this complexity, non-blocking design is the standard for any system that does more than blink an LED.