Moving Data Without the CPU

Unit 9, lesson 1 showed that each interrupt costs a fixed number of cycles to enter, handle and leave. When the “handling” is only moving one byte between a peripheral’s data register and memory, nearly all of that cost is overhead, and it scales with the data rate:

With an illustrative 60 cycles per interrupt at 48 MHz, a 115 200 baud UART (11 520 bytes/s) costs 1.4 % of the CPU, which is fine. At 921 600 baud it costs 11.5 %, and an SPI stream at 8 Mbit/s (a million bytes a second) would need 125 %: more than the CPU has. Long before that point, bytes are lost whenever a higher-priority handler delays the byte interrupt for longer than the receive FIFO can cover.

↑ This step uses the figure at the top of the page.

With the pico-sdk, sending a message to UART0 by DMA looks like this:

int ch = dma_claim_unused_channel(true);
dma_channel_config c = dma_channel_get_default_config(ch);
channel_config_set_transfer_data_size(&c, DMA_SIZE_8);       /* one byte per transfer */
channel_config_set_read_increment(&c, true);                 /* walk through msg[] */
channel_config_set_write_increment(&c, false);               /* always the UART's data register */
channel_config_set_dreq(&c, uart_get_dreq(uart0, true));     /* wait for room in the TX FIFO (lesson 2) */
dma_channel_configure(ch, &c, &uart_get_hw(uart0)->dr, msg, len, true);   /* true: start now */

The function returns at once; the channel sends the bytes while the program continues. The STM32 HAL does the same with HAL_DMA_Init() for the settings and HAL_DMA_Start_IT(&hdma, src, dst, length) to start. Zephyr’s documentation is candid that a portable DMA API is impossible, because “each DMA has unique memory requirements, peripheral interactions, and features”; the concepts, however, are the same everywhere.

The program learns that a transfer is complete in one of two ways:

• polling the channel’s busy flag, as dma_channel_wait_for_finish_blocking() does, or HAL_DMA_PollForTransfer() on an STM32;
• a completion interrupt: on the RP2040 the channel’s bit in INTS0 or INTS1 (cleared by writing 1, unit 9, lesson 4); on the STM32 the transfer-complete flag, which HAL_DMA_IRQHandler() turns into a call to the handle’s XferCpltCallback.

One subtlety connects straight to unit 2, lesson 5: the compiler does not know that the DMA changed the destination buffer. The pico-sdk’s wait function ends with a compiler memory barrier precisely “to stop the compiler hoisting a non volatile buffer access above the DMA completion”. The same applies in the other direction: finish writing a buffer, then start the channel, with a barrier between them if the buffer is not volatile.

DMA removes instructions, not bus traffic. Every byte still crosses the bus matrix twice (a read and a write), competing with the cores for the same memories and peripherals; unit 3, lesson 3 showed how an arbiter makes one master wait. Setting a channel up takes a few register writes, and the completion interrupt still runs. So DMA pays off for:

• high rates and long blocks, where per-byte interrupts would dominate;
• continuous streams (audio, ADC sampling, displays), lessons 4 and 5;
• precise timing, because a hardware-paced transfer does not wait for a handler;
• low power, because the CPU can sleep while data moves.

For a handful of bytes now and then, a plain loop or an interrupt is simpler and costs less than configuring a channel.

A 921 600 baud UART with 8N1 framing carries 921 600 / 10 = 92 160 bytes/s. With one 60-cycle interrupt per byte:

With DMA into 256-byte blocks and an illustrative 200-cycle completion handler, there are 92 160 / 256 = 360 interrupts a second:

about 77 times less. For the 8 Mbit/s SPI stream (10⁶ bytes/s), per-byte interrupts would need 125 % of the CPU, so they cannot work at all; DMA with 16-byte blocks needs 62 500 × 200 / 48 × 10⁶ = 26 %, and with 1024-byte blocks 0.41 %. The line rate is the same in every case: DMA does not make the UART faster, it frees the CPU while the UART runs.