2.4DMA & memory-mapped I/O

In an embedded system, if the CPU must intervene byte by byte every time sensor data is acquired or a communication interface sends or receives data, the time available for computation is squeezed. DMA solves this problem, but behind the benefit of "reducing CPU load" lies a new source of contention: bus arbitration. This section covers the basic mechanics of DMA and memory-mapped I/O, along with the design caveat of how DMA can conflict with real-time behavior.

2.4.1Offloading the CPU with DMA

• DMA (direct memory access) is a mechanism whereby a DMA controller transfers data directly between memory locations, or between memory and a peripheral device, without CPU involvement. The CPU only needs to configure the DMA controller with the source, destination, and transfer size and start it; while the transfer is in progress, the CPU is free to run other computations concurrently (i.e., its load is offloaded).
• Transfer completion is typically signaled to the CPU via an interrupt. The benefit of DMA grows with the volume of data handled (burst sensor acquisition, buffered serial-communication transfers, etc.), but for small, low-frequency transfers, the overhead of configuring DMA can outweigh the benefit, and simple CPU-driven polling or direct transfer can sometimes be more efficient.

2.4.2Memory-mapped I/O

• Memory-mapped I/O assigns a peripheral device's control and status registers to specific addresses within the same address space as ordinary memory. The CPU can then operate the device using nothing but ordinary memory read/write instructions, without a dedicated I/O instruction set, which simplifies the instruction set and makes it easier to optimize via a compiler or to control directly from C.
• Because reading or writing a memory-mapped I/O register, unlike ordinary memory, triggers a side effect (a change in device state) on every access, the corresponding region must be declared volatile so the compiler does not omit or reorder those reads/writes for optimization. Neglecting this can cause serious defects, such as a register write being optimized away entirely.

A systems architect is designing a system that must simultaneously handle high-speed data acquisition from multiple sensors and a hard real-time control loop (a task updating PWM output on a fixed cycle) on the same MCU. By transferring sensor data to a buffer via DMA, the CPU should no longer need to babysit byte-by-byte transfers and could instead focus on the control loop's computation. In practice, however, the control loop occasionally spiked in execution time and missed its cycle. Investigating the cause revealed that the DMA controller and the CPU share the same memory bus, and due to bus arbitration, while DMA is transferring a large volume of data, the CPU's memory accesses (instruction fetches and data accesses) fail to win bus ownership and are made to wait. In other words, "DMA was supposed to free up CPU processing time," but in practice it created a new form of contention: the CPU and DMA compete for the shared resource of the memory bus, and CPU accesses during a DMA transfer are delayed by bus arbitration. The remedy requires a scheduling refinement—rather than leaving the DMA controller's bus ownership to simple round-robin arbitration, pause DMA transfers just before the control loop's cycle runs, or split the DMA transfer into small bursts interleaved with CPU accesses. The lesson this case illustrates is that "reducing CPU load" and "guaranteeing overall real-time behavior including bus contention" are two different problems, and introducing DMA must always factor in the CPU-access delay caused by bus arbitration.

2.4.3Section summary

• DMA transfers data between memory and a device without CPU involvement, offloading the CPU, with completion signaled by an interrupt
• Memory-mapped I/O places device registers in the same address space as ordinary memory, operable with ordinary instructions, requiring a volatile declaration
• Because DMA and the CPU share the memory bus, delay from bus arbitration occurs, and this contention with real-time behavior must be factored into the design