企业官网建设流程全解析

DMA这东西，刚接触嵌入式的人容易走两个极端。一种是觉得它高深莫测，能不用就不用，串口收数据老老实实一个字节一个字节进中断，CPU被频繁打断还自我感觉良好；另一种是听说DMA能"解放CPU"，上来就配一堆通道，结果数据错位、传输不完整、中断进不去，调了两天怀疑人生。我在带新人和做项目的过程中，这两种情况都见过太多次。这篇就围绕嵌入式驱动开发里的DMA，把它的工作机制、配置思路、常见坑和实测经验一次讲透，不管你是刚学STM32的在校生，还是已经在做Linux驱动、GD32、HC32F460这类平台的工程师，都能从中找到能直接用的东西。

1. DMA到底在替CPU干什么活

1.1 从一次串口收包说起

先看一个最朴素的场景：你用STM32的串口接收一帧100字节的数据。不用DMA的写法通常是开接收中断，每来一个字节进一次中断，在中断里把数据存进缓冲区，再判断帧头帧尾。100字节就是100次中断，如果波特率是115200，理论上每秒最多能来11520个字节，也就是每秒上万次中断。CPU主频就算跑到72MHz，这么频繁地进出中断，上下文保存恢复的开销累积起来也相当可观，更别说你还有别的任务要跑。

DMA（Direct Memory Access，直接存储器访问）解决的正是这个问题。它本质上是一个独立于CPU内核的外设控制器，能在存储器和外设之间、存储器和存储器之间直接搬运数据，整个过程不需要CPU逐字节参与。CPU只需要做三件事：配置好源地址、目的地址、传输长度和触发方式，然后启动传输，剩下的搬运工作DMA自己完成，搬完了再通过中断通知CPU一声。

打个比方，CPU是公司老板，数据搬运是搬砖。没有DMA的时候，老板亲自一块一块搬砖，搬一块记一下账，累得半死还干不了别的。有了DMA，老板雇了个搬运工（DMA控制器），告诉他从哪搬到哪、搬多少，然后老板去开会处理别的事，搬运工搬完了敲个门说"搬完了"，老板再回来验收。这个类比虽然糙，但把DMA的核心价值说清楚了：把CPU从重复的、机械的数据搬运中解放出来。

1.2 DMA控制器的内部结构长什么样

理解DMA的内部结构，对后面配置和排错非常关键。以常见的STM32F103/F407系列为例，DMA控制器内部大致有这么几个核心部件：

• 通道（Channel）或流（Stream）：每个通道对应一组固定的外设请求源。F103是7个通道的DMA1加5个通道的DMA2，F407则换成了"流"的概念，每个流有8个可选通道。通道和外设的对应关系是硬件固定的，不能随便乱配，这是新手最容易踩的坑之一。
• 源地址寄存器与目的地址寄存器：分别存放数据从哪来、到哪去。这两个地址在传输过程中会自动递增或保持不变，取决于你配置的增量模式。
• 传输计数器（NDTR）：记录还剩多少数据没搬。每搬一个数据单元，计数器减一，减到零触发传输完成中断。
• 优先级仲裁器：当多个通道同时请求时，硬件根据软件优先级和硬件优先级决定谁先搬。
• FIFO（仅F4/F7/H7等高级系列有）：用于缓冲和打包数据，支持突发传输（Burst），能显著提升总线利用率。

这里要特别强调一点：DMA通道和外设的映射关系是硬件写死的。比如STM32F103的USART1_TX固定对应DMA1_Channel4，USART1_RX固定对应DMA1_Channel5，你配错了通道，数据根本不会动。很多"配置看起来没问题但就是不通"的案例，最后查出来都是通道选错了。查手册的时候一定要翻到"DMA request mapping"那张表，别凭记忆。

1.3 三种传输方向与增量模式的组合逻辑

DMA的传输方向有三种：外设到存储器、存储器到外设、存储器到存储器。每种方向下，源和目的地址的增量模式（Increment）需要分别配置，这个组合逻辑如果搞混，数据就会全部堆在同一个地址上，或者地址乱跳导致越界。

这个表看着简单，但实际配置时外设寄存器的地址是固定的，所以外设那一侧的增量必须禁止，否则DMA会去访问一个不存在的地址，轻则传输失败，重则触发硬件错误。存储器那一侧通常要使能增量，让数据依次写入缓冲区的不同位置。我见过有人把串口接收配成源地址增量，结果DMA去读了一堆无关的寄存器地址，收到的数据全是乱的。

2. 串口DMA收发：从配置到跑通的完整链路

2.1 为什么串口场景最适合用DMA

串口是DMA最经典的应用场景，没有之一。原因很直接：串口数据是流式的、连续的、方向明确的，而且收发双方的速度往往不匹配。比如你用115200波特率接收上位机发来的固件包，一包可能几KB，如果靠中断逐字节收，CPU会被打断得七零八落；如果靠轮询，那CPU就彻底被占死了，别的活别想干。

用DMA接收，配置好缓冲区和长度，启动后CPU该干嘛干嘛，收满一帧或者收到空闲帧（IDLE）再处理。用DMA发送，把要发的数据丢进缓冲区，启动传输，发完了中断通知你，中间CPU完全不用管。这就是为什么几乎所有正经的嵌入式项目，串口都会上DMA。

在Linux驱动开发里，串口DMA的体现形式又不一样。Linux的串口子系统（serial core）已经帮你把DMA框架搭好了，驱动工程师要做的是实现DMA相关的回调，比如dma_request_chan申请通道、在start_tx里启动DMA传输、在DMA完成中断里调用uart_write_wakeup唤醒上层。这块后面单独展开。

2.2 STM32 HAL库下的串口DMA接收配置

以STM32F407 + HAL库为例，串口DMA接收的配置步骤大致如下。这里我用CubeMX生成基础代码，再手动补充关键逻辑，这样最贴近实际项目流程。

第一步，在CubeMX里使能USART1，模式选Asynchronous，波特率115200，8N1。然后在DMA Settings标签页点Add，给USART1_RX添加一个DMA请求，通道会自动选到DMA2_Stream2（F407的映射），方向Peripheral To Memory，优先级Medium，模式选Normal还是Circular看需求。

第二步，配置DMA参数。Mode我一般接收用Circular（循环模式），这样缓冲区满了自动从头覆盖，配合IDLE中断做不定长接收特别顺手；发送用Normal，发完就停。Data Width两边都选Byte，因为串口是字节流。Memory地址增量使能，Peripheral地址增量禁止。

第三步，生成代码后，在main里启动接收：

uint8_t rx_buf[256]; // 启动DMA接收，循环模式 HAL_UART_Receive_DMA(&huart1, rx_buf, sizeof(rx_buf)); // 使能IDLE中断，用于检测一帧结束 __HAL_UART_ENABLE_IT(&huart1, UART_IT_IDLE);

第四步，在中断服务函数里处理IDLE事件。HAL库默认的USART1_IRQHandler会调用HAL_UART_IRQHandler，但它不处理IDLE，需要你自己加：

void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(&huart1); // 计算本次接收到的数据长度 uint16_t recv_len = sizeof(rx_buf) - __HAL_DMA_GET_COUNTER(huart1.hdmarx); // 处理数据，注意这里要快进快出 process_rx_data(rx_buf, recv_len); // 循环模式下不需要重新启动，Normal模式需要重新调用HAL_UART_Receive_DMA } HAL_UART_IRQHandler(&huart1); }

这段代码里有个关键点：__HAL_DMA_GET_COUNTER返回的是DMA还剩多少没搬，用缓冲区总长减去它，就是本次实际收到的字节数。这是IDLE + DMA组合接收不定长数据的标准套路，实测非常稳。

2.3 串口DMA发送的两种触发方式

发送比接收简单，因为发送的时机是你自己控制的。常见两种方式：

一种是"发一包启动一次"，适合数据量小、发送不频繁的场景。调用HAL_UART_Transmit_DMA，传进去缓冲区和长度，HAL库会自动配置DMA并启动，发完进HAL_UART_TxCpltCallback回调。注意这个回调里不能做耗时操作，最好只置个标志位。

另一种是"环形缓冲 + 持续发送"，适合数据量大、需要连续输出的场景，比如日志打印。自己维护一个环形缓冲区，上层往里写，DMA从里往外读，读指针追上写指针就停，有新数据再启动。这种模式实现起来复杂一些，但能避免频繁启动DMA带来的开销。

注意：DMA发送期间，绝对不能修改正在发送的缓冲区内容，否则发出去的数据会错乱。如果上层要复用这个缓冲区，必须等发送完成回调触发后再改。

2.4 实测中串口DMA最容易翻车的三个点

第一个坑是缓冲区对齐和大小。有些系列（比如带Cache的H7）要求DMA缓冲区按Cache Line对齐，否则会出现数据不一致。F1/F4没有Cache，这个问题不明显，但一旦上H7或者M7内核，就必须处理Cache一致性问题，要么把缓冲区放到非Cache区域，要么在DMA传输前后做Cache清理和无效化。

第二个坑是IDLE中断和DMA完成中断的竞争。如果一帧数据刚好填满缓冲区，DMA完成中断和IDLE中断可能同时触发，处理不当会重复处理数据或者丢数据。我的做法是在IDLE处理里先关DMA，处理完再开，或者用状态机标记当前帧是否已处理。

第三个坑是波特率太高时DMA响应不过来。理论上DMA搬运速度远高于串口速率，但如果总线上有更高优先级的DMA在跑（比如LCD刷屏、SD卡读写），串口DMA可能被延迟，导致溢出错误（ORE）。这时候要么提高串口DMA优先级，要么降低其他DMA的占用。

3. ADC + DMA：多通道采集的正确打开方式

3.1 单通道轮询的痛点和DMA的解法

ADC采集是另一个DMA重度应用场景。假设你要采集8个通道的模拟量，用轮询方式：切换通道、启动转换、等EOC标志、读数据，循环8次。每次转换加上等待时间，8个通道轮一遍可能就要几十微秒，而且CPU全程被占着。

用DMA就不一样了。配置ADC为扫描模式（Scan Mode），开启连续转换（Continuous Conversion），使能DMA请求，DMA配置成循环模式，目的地址指向一个8元素的数组。启动一次，ADC就自动按顺序转换8个通道，每转换完一个，DMA自动把结果搬到数组对应位置，转完一轮自动从头再来。CPU完全不用管，需要数据的时候直接读数组就行。

这个方案在STM32F407上实测，8通道12位精度，采样率可以轻松跑到几百kHz，CPU占用几乎为零。关键词里提到的"stm32f407vet6 adc dma 中断 stm32cubemax配置"，说的就是这个典型场景。

3.2 CubeMX配置ADC多通道DMA的细节

在CubeMX里配置ADC多通道DMA，有几个地方容易配错：

• Scan Conversion Mode必须使能，否则只会转换第一个通道。
• Continuous Conversion Mode根据需要选。如果要DMA循环搬运，这个通常使能；如果是一次性采集，可以禁止。
• DMA Continuous Requests这个选项在F4系列里很关键。使能后，ADC每转换完一个通道就发一次DMA请求，DMA搬一个数据；禁止的话，DMA要等整个序列转换完才搬。多通道采集必须使能这个选项，否则数据会错位。
• Number Of Conversions要设成通道数，比如8个通道就设8。
• DMA模式选Circular，这样数组会被循环填充。

配置完生成代码，启动采集：

uint16_t adc_buf[8]; HAL_ADC_Start_DMA(&hadc1, (uint32_t *)adc_buf, 8); // 需要数据时直接读adc_buf[0]~adc_buf[7]

这里有个细节：HAL_ADC_Start_DMA的第三个参数是"转换次数"，不是字节数。对于16位ADC结果，DMA的Data Width要配成Half Word，这样8个通道对应8个半字，长度传8就对了。如果配成Byte，长度就要传16，而且数据会拆成高低字节，读出来是错的。

3.3 ADC DMA的数据对齐与精度问题

ADC的转换结果有左对齐和右对齐两种。12位精度下，右对齐时结果在低12位，高4位是0；左对齐时结果在高12位。DMA搬运的是整个16位寄存器，所以读出来的值要根据对齐方式做移位处理。我一般用右对齐，读出来直接就是0~4095，省事。

还有一个容易被忽略的点：ADC的采样时间和DMA的搬运速度要匹配。如果采样时间设得太短，采样电容还没充够电就转换，结果会偏小。特别是高阻抗信号源，采样时间要适当加长。这个和DMA没关系，但经常和DMA问题混在一起，排查时要分开看。

4. DMA测速：怎么知道你的DMA到底跑多快

4.1 测速的意义和常见误区

"DMA测速"这个词在搜索里出现频率很高，说明很多人关心DMA的实际吞吐能力。测速的意义在于：验证配置是否正确、评估系统瓶颈、对比不同传输模式的效率。

但测速有个常见误区：很多人只测了"启动到完成"的总时间，然后除以数据量算出速率，这个结果包含了中断响应、函数调用等开销，不能反映DMA本身的搬运能力。要测DMA的真实带宽，应该用硬件定时器在DMA启动前清零、完成中断里读值，这样测出来的才是纯搬运时间。

4.2 用定时器给DMA传输计时

以STM32F407为例，用TIM2做微秒级计时，测一次内存到内存的DMA传输：

uint32_t dma_test_src[1024]; uint32_t dma_test_dst[1024]; volatile uint32_t dma_time_us = 0; // 配置TIM2为1MHz计数，即每微秒加一 void tim2_init(void) { __HAL_RCC_TIM2_CLK_ENABLE(); TIM2->PSC = 84 - 1; // 84MHz / 84 = 1MHz TIM2->ARR = 0xFFFFFFFF; TIM2->CR1 |= TIM_CR1_CEN; } // 启动DMA前 TIM2->CNT = 0; HAL_DMA_Start_IT(&hdma_memtomem, (uint32_t)dma_test_src, (uint32_t)dma_test_dst, 1024); // DMA完成回调里 void DMA2_Stream0_IRQHandler(void) { dma_time_us = TIM2->CNT; // 1024个32位字 = 4096字节 // 速率 = 4096 / (dma_time_us * 1e-6) 字节/秒 }

实测F407在168MHz主频下，内存到内存DMA传输4KB大约需要几微秒，算下来带宽在几百MB/s量级。这个数字受总线仲裁、源目的地址是否在同一总线等因素影响，不同配置下差异可能很大。

4.3 影响DMA速率的几个硬件因素

测速结果不理想时，别急着怀疑代码，先看看这几个硬件层面的因素：

• 总线矩阵和仲裁：DMA和CPU、其他主设备共享总线，如果CPU正在密集访问Flash，DMA访问SRAM的速率会受影响。
• 源和目的是否在同一总线：比如从SRAM搬到SRAM，和从外设搬到SRAM，路径不同，速率不同。
• 数据宽度：32位传输比8位传输效率高，因为同样数据量下事务数少。
• 突发传输（Burst）：F4以上的DMA支持突发模式，一次总线仲裁搬多个数据，能显著提升效率。关键词里的"stm32的tim dma burst应用"说的就是这个。
• FIFO的使用：合理配置FIFO阈值和突发长度，能减少总线占用次数。

我做过一组对比测试，同样搬4KB数据，8位宽度无突发大概要十几微秒，32位宽度加4拍突发能压到几微秒，差距非常明显。所以如果对DMA吞吐有要求，一定要把数据宽度和突发模式配到位。

5. Linux驱动开发中的DMA：和裸机完全不同的思路

5.1 Linux DMA引擎框架的分层

从裸机转到Linux驱动，DMA的使用方式会发生根本性变化。裸机是你直接操作DMA寄存器，Linux下则要通过DMA引擎框架（DMA Engine Framework）来申请和使用DMA通道。这个框架把DMA控制器抽象成"provider"，把使用DMA的设备抽象成"consumer"，中间通过dma_request_chan、dmaengine_prep_slave_sg、dmaengine_submit、dma_async_issue_pending这一套API来交互。

为什么要这么设计？因为Linux要支持各种不同的DMA控制器，如果每个驱动都直接操作寄存器，代码没法复用，也没法统一管理通道资源。框架层帮你处理了通道分配、描述符管理、中断处理等通用逻辑，驱动工程师只需要关心"我要搬什么数据、从哪到哪"。

5.2 串口驱动里DMA的接入点

以Linux串口驱动为例，DMA的接入点主要有这么几个：

• probe阶段：调用dma_request_chan申请TX和RX通道，申请失败要能优雅降级到PIO模式。
• start_tx：把待发送的数据映射成DMA描述符，提交并启动。这里要用dma_map_single做地址映射，确保DMA能访问到物理地址。
• RX路径：通常用循环缓冲区加DMA，配合定时器或者字符超时中断来判断帧结束。
• 中断处理：DMA完成中断里调用dmaengine_tx_status检查状态，然后唤醒上层或者启动下一次传输。

这里有个和裸机完全不同的概念：Cache一致性。在带Cache的ARM处理器上，CPU写的数据可能还在Cache里没落到内存，DMA直接去内存搬就会搬到旧数据。所以DMA传输前要dma_sync_single_for_device，传输后要dma_sync_single_for_cpu。这个在裸机上基本不用考虑，但在Linux下是必考题，嵌入式面试八股文里经常出现。

5.3 设备树里怎么描述DMA通道

Linux下DMA通道的分配是通过设备树（Device Tree）描述的。以串口为例，设备树节点里会有这样的属性：

uart1: serial@40011000 { compatible = "st,stm32-uart"; reg = <0x40011000 0x400>; interrupts = <37>; dmas = <&dma1 4 0x400>, <&dma1 5 0x400>; dma-names = "tx", "rx"; status = "okay"; };

dmas属性里，第一个cell是DMA控制器 phandle，第二个是通道号，第三个是配置标志。dma-names给通道起了名字，驱动里用dma_request_chan(dev, "tx")就能拿到对应的通道。这套机制比裸机灵活得多，但也要求你对设备树语法和DMA控制器的binding文档有足够了解。

6. 那些年我在DMA上踩过的坑

6.1 通道映射记错导致传输静默失败

这个坑我踩过不止一次。有一次用STM32F103做串口发送，凭记忆把USART1_TX配到了DMA1_Channel5，结果数据死活发不出去，也不报错，就是没反应。查了半天代码没发现问题，最后翻参考手册的DMA请求映射表，发现USART1_TX是Channel4，Channel5是USART1_RX。改过来立马就通了。

教训就是：DMA通道映射永远查手册，别凭记忆。不同系列、不同外设的映射都不一样，F1和F4的编号规则完全不同，F4还多了"流"的概念，更容易搞混。

6.2 忘记清除传输完成标志导致中断反复触发

DMA传输完成中断触发后，必须清除对应的标志位，否则中断会一直触发，CPU被卡死在中断里。HAL库的HAL_DMA_IRQHandler会帮你清标志，但如果你自己写中断服务函数，就要手动清。这个坑在裸机开发里很常见，表现是程序跑着跑着就卡住了，用调试器一看，一直在进中断。

6.3 缓冲区被优化掉或未初始化

编译器优化有时候会把看起来"没被使用"的DMA缓冲区优化掉，或者放到错误的段里。DMA缓冲区一定要用volatile修饰，或者用__attribute__((section(".dma_buffer")))放到指定段，确保它真的在内存里，而且地址是DMA能访问的。另外缓冲区一定要初始化，否则第一次传输可能读到随机值。

6.4 传输长度单位搞错

DMA的传输长度单位是"数据单元个数"，不是字节数。如果你配的是16位数据宽度，长度传100，实际搬的是200字节。这个在ADC多通道采集和SPI DMA里特别容易搞错。我一般会在代码里加注释标明单位，避免后面自己都忘了。

6.5 循环模式下数据覆盖

循环模式（Circular）很方便，但如果不配合IDLE中断或者半传输中断，缓冲区满了会自动从头覆盖，旧数据就丢了。用循环模式一定要有机制知道"当前数据写到哪了"，否则读到的数据可能是新旧混合的。IDLE中断、半传输中断（HT）、传输完成中断（TC）这三个配合使用，才能可靠地处理不定长数据。

7. 不同平台的DMA差异与选型参考

7.1 STM32、GD32、HC32F460的DMA对比

国产MCU这几年用得越来越多，GD32和HC32F460的DMA和STM32有相似之处，但细节差异不小。

GD32的DMA和STM32F1高度兼容，很多代码可以直接移植，但要注意GD32的主频更高，如果DMA和CPU访问同一块SRAM，仲裁行为可能不同。HC32F460支持描述符链式传输，适合复杂的多段搬运场景，但配置方式和小华自己的库绑定，移植性差一些。

7.2 SPI + DMA的组合应用

SPI是高速外设，配合DMA能发挥最大威力。比如驱动LCD屏、读写Flash、和AD7606这类高速ADC通信，都适合用SPI DMA。关键词里的"安富莱ad7606"和"spi dma"说的就是这个场景。

AD7606是8通道16位并行/串行ADC，用SPI接口读取时，如果靠CPU逐字节读，采样率上不去。用SPI DMA，配置好接收缓冲区和长度，启动一次就能把8个通道的数据全部搬回来。注意SPI的时钟极性和相位要和AD7606匹配，DMA的接收长度要算对（8通道 x 2字节 = 16字节）。

7.3 DMA在嵌入式AI和工装测试中的角色

现在嵌入式AI很热，边缘设备上跑推理，数据搬运量很大。DMA在这里的作用是把传感器数据高效地搬到内存，再把内存里的数据搬到加速器或者NPU。比如摄像头采集、麦克风阵列采样，都是DMA的重度用户。

工装测试场景里，DMA用来做批量数据采集和比对。比如产线上要测试一块板子的ADC精度，用DMA连续采集几千个点，然后上位机分析。这时候DMA的稳定性和测速就很重要，采集速度上不去，产线节拍就达不到。

8. 给不同阶段工程师的DMA学习建议

8.1 新手：先把一个场景吃透

如果你刚开始学DMA，别贪多。选一个场景，比如串口DMA接收，把它彻底搞明白：通道怎么选、寄存器怎么配、中断怎么处理、数据怎么读。把这一个场景跑通、跑稳，你对DMA的理解就超过一大半人了。然后再扩展到ADC、SPI，会发现套路是相通的。

推荐的学习路径是：先看参考手册的DMA章节，理解通道映射和传输模式；然后找一个官方例程，对着手册逐行看懂；最后自己从零配一遍，不看例程。这个过程走下来，DMA就不再是黑盒了。

8.2 进阶：理解总线、Cache和性能

当你已经能熟练配置DMA，下一步要关注的是性能和一致性。理解总线矩阵、仲裁机制、Cache一致性，这些决定了你的DMA能不能跑出理论带宽。特别是在Cortex-M7和Cortex-A系列上，Cache问题不处理，DMA数据就是错的，而且错得很随机，很难查。

建议动手做一次DMA测速实验，用定时器精确测量不同配置下的传输时间，对比数据宽度、突发模式、FIFO配置的影响。这个实验做完，你对DMA性能的理解会有一个质的飞跃。

8.3 面试：DMA相关的高频问题

嵌入式面试里DMA是高频考点，常见问题包括：DMA和中断的区别、DMA传输的三种方向、如何用DMA接收不定长数据、Cache一致性问题怎么处理、Linux下DMA引擎框架的工作流程。回答的时候别只背概念，结合你实际做过的项目讲，比如"我在串口接收里用IDLE中断加DMA循环模式处理不定长帧，具体是这样做的……"，这样面试官会觉得你是真做过。

我个人在实际项目中的体会是，DMA这东西，看十遍手册不如动手配一遍。它涉及的细节太多，通道映射、增量模式、中断标志、缓冲区管理，任何一个地方疏忽都会导致问题。但一旦你真正跑通了几个场景，就会发现它的设计其实很优雅，是嵌入式系统里性价比最高的性能优化手段之一。后面如果要做高速数据采集或者多外设并发，DMA更是绕不开的基础设施，早点把它啃下来，后面会省很多事。