When should you use DMA instead of CPU-driven data transfers?

DMA is beneficial when you need to move blocks of data between memory and peripherals (or memory-to-memory) at rates where CPU involvement becomes wasteful or infeasible. The decision comes down to three factors: data rate, transfer size, and what the CPU should be doing instead.

Use DMA when: (1) high data rates force the CPU to spend most of its time servicing transfers — an ADC sampling at 1 Msps generates a million interrupts per second, each costing 30-50 clock cycles for context switch, flag check, and data copy; at 72 MHz, that alone consumes 40-70% of the CPU. (2) You need deterministic transfer timing independent of interrupt latency — DMA responds to peripheral requests within 1-2 bus cycles, while an ISR has variable latency depending on current interrupt priority and pipeline state. (3) The CPU should be processing previously captured data while new data arrives — the classic producer-consumer pattern where DMA produces and the CPU consumes.

Use CPU transfers when: (1) data volumes are small and infrequent — a single 4-byte SPI command does not justify 10-20 register writes to configure the DMA channel. (2) The transfer involves per-byte logic that DMA's simple increment-and-copy model cannot express — byte stuffing, CRC computation inline, protocol framing, or conditional branching. (3) The system has only a few DMA channels and they are all allocated to higher-priority peripherals. The practical break-even point is roughly 8-16 bytes per transfer at rates above a few hundred transfers per second. Below that, the DMA setup overhead (50-200 CPU cycles) exceeds the time the CPU would spend doing the transfer directly.