企业官网建设流程全解析

搞嵌入式的人，迟早会遇到一个绕不开的话题：DMA。不信你看自己的工程，串口打印、SPI刷屏、ADC连续采样、Flash读写——只要数据量稍微上来一点，CPU就全耗在把数据从寄存器搬到内存这件事上了。这期顺手把我在驱动开发里用DMA的经验理一遍，从原理到配置，从测速到踩坑，一次说透。我默认看这篇的朋友至少有裸机或者RTOS的开发基础，没写过DMA也至少被DMA坑过，这篇就当是帮你把零散的东西串起来。

1. DMA到底解决什么问题

1.1 先理解DMA的本质工作

DMA的全称是Direct Memory Access，直译过来就是“直接内存访问”。很多教程喜欢把它描述成“不需要CPU参与的数据搬运”，这个说法对但不完整。更准确地说，DMA是一个独立于CPU之外的数据搬运引擎，它挂在内核总线上，可以自己发起读写总线的操作，把数据从源地址搬到目的地址。CPU只需要在开始之前告诉它“你从哪拿、放到哪、搬多少、搬完叫我”，然后就可以去睡大觉或者干别的活。

这里有一个关键点：DMA不是不需要CPU参与，而是不需要CPU一块一块地参与。初始化DMA、启动传输、处理中断，这些仍然要CPU来做。省掉的是逐字节或者逐字拷贝的循环，也就是那部分最机械、最浪费时间的指令周期。

可以用一个生活化的类比来理解：CPU就像一个项目经理，而DMA是专门的搬运工。没有DMA的时候，项目经理需要亲手把每一箱货物从一个仓库搬到另一个仓库，中途什么事情都干不了。有了DMA之后，项目经理只需要告诉搬运工“把A仓库的50箱货搬到B仓库”，然后就可以去开会、写方案，等搬运工干完喊一嗓子就行了。

1.2 DMA的三种基本搬运方向

在驱动开发里，DMA的传输方向通常分为三类：内存到内存、外设到内存、内存到外设。虽然看起来只是方向不同，但实际配置和使用逻辑差异很大。

内存到内存的搬运，常用于较大块的数据拷贝、图像缓冲区的处理或者内存整理。这种模式下，源地址和目的地址都由CPU指定，DMA控制器纯粹当搬运工。比如你有一张图片要旋转90度，前面的预处理阶段用DMA把原始数据从A缓冲搬到B缓冲，再做像素级算法，CPU压力会小很多。

外设到内存，是最常见也最实用的一种。典型代表就是串口接收、ADC多通道连续采样、SPI从设备接收数据。外设有数据要传递时，会向DMA控制器发一个请求信号，DMA拿到请求就主动从外设数据寄存器把数据搬走，写进内存。CPU不参与这个过程，数据已经在后台偷偷被收好了。

内存到外设，典型的场景是串口发送、DAC波形输出、数据显示到SPI接口的LCD屏幕。CPU把要发送的数据准备好，DMA按顺序把数据一块一块送进外设的发送寄存器，外设自己会把数据逐字节发出去。

理解这三种方向其实是在帮你建立DMA驱动的第一层框架：搞清楚数据源在哪、数据目的地是哪、由谁发起请求。后面所有配置工作，本质上都是在回答这三个问题。

1.3 什么时候该用DMA，什么时候不该用

很多人一看DMA这么好用，恨不得把所有外设都接上DMA。但用过一段时间就会发现，DMA不是万能的，也不是所有场景都应该上DMA。

先说适合用DMA的场景：数据量大、周期性发生、且CPU有别的活要干。串口通信波特率115200，每秒大约11.5KB的数据量，如果每收到一个字节都触发一次中断，CPU在高波特率下几乎被淹没；这时候用DMA加空闲中断，就能把接收整包处理变成“数据攒好了我再去处理”。SPI刷屏更是如此，一帧320x240的RGB565图像是150KB，用CPU逐像素推，就算主频跑144MHz也感觉很吃力，换成DMA突发传输之后，CPU基本可以腾出来跑其他逻辑。

不适合用DMA的场景也非常鲜明：单次传输量小、实时性要求极高、或者数据需要逐字节处理的情况。比如I2C读写一个EEPROM寄存器，总共就几个字节，DMA配置和启动代码的开销可能比直接用CPU轮询还大。还有像按键扫描这种，本身数据量就少得可怜，而且每读一次都需要立即判断状态，DMA反而引入延迟。

我的个人经验是：传输长度小于16字节的场景，尽量不要用DMA；传输长度在几百字节以上、而且数据是“攒批处理”模式的，用DMA性价比最高。

2. 高频应用场景拆解

2.1 串口DMA：发送顺手，接收用空闲中断

串口几乎是每个嵌入式项目的标配，串口DMA也是我使用频率最高的DMA场景。先说发送方向，串口发送用DMA其实逻辑非常直接：应用层把数据组织成一帧，填进发送缓冲区，然后启动DMA传输，让DMA把缓冲区内容搬进串口的数据寄存器。发送完成后会触发DMA传输完成中断，这时串口才算真正把数据发完了，可以释放缓冲区。

但这里有个很多人忽略的问题：串口外设的TXE（发送寄存器空）标志触发DMA请求的时机。使用DMA发送时，串口硬件会在发送寄存器为空时自动向DMA控制器产生请求，DMA响应请求后写入下一个数据。所以从CPU角度看，调用一次DMA发送API之后，数据是“异步”地在往外走，如果这时候立刻修改发送缓冲区，很可能导致数据错乱。正确的做法是维护一个发送状态标记，DMA传输完成中断之后才允许写缓冲区。

接收方向比发送要麻烦不少，单纯靠DMA接收会把数据连续不断地存进缓冲区，但你不知道哪一帧数据结束了。经典解决方案是DMA加串口空闲中断（IDLE）：DMA一直在后台接收数据，每收到一个字节就搬进环形缓冲区；当串口总线上出现空闲（即一个字节之后超过一个字节时间没有新数据），硬件触发IDLE中断，此时从DMA当前计数寄存器算出本轮收到了多少个字节，交给协议层去解析。

这套方案的难点在于时间点控制，IDLE中断产生的那一刻，DMA可能还在搬数据或者刚好停在边界。稳妥的处理方式是先在串口中断里暂停接收方向的DMA（不是关闭DMA时钟，而是禁用接收通道），计算本次接收长度，再把缓冲区头指针推进，最后重新使能DMA接收。这样能避免在中断服务函数里读DMA计数时，后面还有新数据覆盖缓冲区，导致数据错位。

2.2 SPI DMA：刷屏和传感器采集的利器

SPI外设和DMA的配合，在嵌入式开发里可以称得上黄金搭档。SPI本身的时钟往往很高，比如主频72MHz的芯片，SPI可以跑到18MHz甚至更高；如果用CPU逐字节向SPI数据寄存器写数据，每写一个字节都要等TXE标志，效率低到令人抓狂。DMA参与之后，数据从内存连续灌进SPI的发送寄存器，外设自己控制时序，速度直接拉满。

我在实际项目中用得最多的SPI DMA场景是LCD刷屏。前面提到一帧图像150KB，用CPU推屏大概要几十毫秒，用DMA传输可以压到10毫秒以内，而且传输过程CPU完全释放，可以处理触控扫描或者其他协议栈。需要注意的是，SPI DMA刷屏时，DMA每搬运一个字节到SPI数据寄存器，SPI主控会在SCLK上产生一个时钟脉冲；因此发送数据的位数必须和SPI配置的数据帧格式一致，常见的是8位帧格式，对应DMA的数据宽度也设置为8位。

SPI接收使用DMA时，有个容易踩坑的地方：SPI全双工模式下，主控要读取从设备的数据，必须同时向外发送数据来产生时钟。所以很多场景下接收DMA和发送DMA要同时工作，发送DMA填0xFF或者自定义的指令字节，接收DMA保存从设备返回的数据。如果只开了接收DMA，没有及时触发发送，你会发现接收DMA永远等不到数据，因为总线上根本没有时钟。

2.3 TIM+DMA Burst：用定时器指挥数据流

一些热词提到了TIM的DMA Burst应用，这确实是很进阶的功能。常规的DMA传输模式是一次请求搬运一个数据，Burst模式则是在一次外设请求到来之后，DMA连续搬运多个数据，像一次“爆发式”传输。在定时器场景里，通常配合定时器的更新事件来触发DMA，实现定时地把内存里的数据批量搬到外设寄存器。

最典型的应用是用TIM产生多路PWM波形，通过DMA从内存数组加载占空比配置。比如你要输出一个正弦波PWM调制信号，预先在内存里放一张256点的正弦表，每个点对应一个定时器比较寄存器值；定时器每次更新时触发DMA，由DMA把表格里的数据搬进CCR寄存器。这样CPU只需要把表格准备好，剩下的波形更新完全交给硬件，输出的PWM占空比平滑变化。

这种用法还需要注意定时器DMA请求和更新事件的时序对齐，如果DMA搬运的速度跟不上定时器的更新频率，就要考虑使用循环模式或者降低更新频率。Burst传输的字节数和地址增量需要算清楚，搬错一个地址，整个波形就乱了。

2.4 DMA连续请求模式怎么理解

DMA连续请求模式，指DMA控制器在外设请求解除之前持续产生传输请求。以串口发送为例，串口发送寄存器空时产生的DMA请求可能是电平信号，如果不做处理，DMA会一直搬运数据直到缓冲区耗尽；这种模式适合大数据块的连续传输。

循环模式下，DMA传输完设定的数据量后自动回到起点继续传输，特别适合音频播放、ADC循环采样这类需要不间断数据流的地方。配置循环模式时，要把内存地址设为自动递增，否则每次回到起点地址不变，数据就写在同一块区域反复覆盖。

如果你的DMA控制器是STM32F1系列那样比较老的型号，还要注意外设地址固定、内存地址自动递增的配置方式；而到了F4/H7系列，DMA控制器改成了Stream加Channel的结构，请求映射关系更灵活，配置思路也变成“选择一个Stream，然后把请求外设接到对应的Channel上”。换平台之后第一件事就是重新确认这两套命名体系的差异。

3. 实际动手：DMA测速和性能验证

3.1 为什么开发驱动之后还要测速

很多工程师写完DMA驱动，能跑通就认为事情结束了，我一开始也是这么干的。后来发现，能跑通和跑得好完全是两回事。DMA虽然号称不占CPU，但它占用总线带宽，如果总线上同时挂着LCD、以太网、USB等多个高速外设，DMA之间会相互抢占总线，导致某一方性能下降。这时候如果不在实际环境里测速，根本发现不了问题。

还有一个现实需求是评估DMA到底带来多少性能收益。比如串口波特率提升了，DMA是否还是必要的？SPI刷屏提速，瓶颈是DMA通道的配置还是外设时钟上限？这些都必须测量数据说话，而不是拍脑袋。

3.2 DMA带宽怎么算，实测怎么测

DMA的理论带宽取决于DMA控制器的时钟频率和一次传输的数据宽度。以STM32F4为例，DMA控制器挂在AHB总线上，主频约84MHz，总线宽度为32位，理论上最大传输速率大约是84M次传输每秒，每次传输32位，也就是每秒可以搬运约336MB数据。实际应用中因为总线仲裁、源设备和目的设备的速度限制，能达到的实测带宽远低于这个数值。

我在项目中常用的测速方法是：准备两个大小相同的内存缓冲区，一个作为源，一个作为目的；启动DMA传输，在启动前把某个GPIO引脚拉高，在传输完成中断里把引脚拉低；用示波器或者逻辑分析仪测量高电平持续时间，就能精确计算搬运一块数据实际花的时间。

用这种方法测出来的数据非常直观。假设缓冲区大小是64KB，GPIO高电平时间为1.2毫秒，那么实际传输速率就是64×1024÷0.0012，大约54.6MB/s。同一次测试里，再用memcpy跑一遍同样大小数据的拷贝，记录耗时，对比两者谁快。对于大部分不涉及缓存一致性问题的小内存搬移，memcpy因为使用了CPU指令流水线和编译器优化，往往能接近甚至超过DMA；但当数据块增大、源和目的端都是外设时，DMA的优势就彻底显现出来了。

测速时有个容易被忽视的细节：DMA传输完成中断不意味着数据对外设已经发送完。比如串口DMA发送，DMA把数据搬进串口数据寄存器后立即传输完成，但串口还要时间逐位把数据发出去。所以测DMA发送带宽和测外设实际吞吐量是两回事，前者是总线侧指标，后者是物理链路指标，别搞混。

3.3 测速失败和代码上常见的错误

DMA测速跑出来的数字几乎不可能等于理论带宽，这是正常的。但如果你测出来的速度明显异常，比如比理论值低一个数量级，就得检查配置问题了。最常见的是DMA数据宽度配置过小，明明外设和内存都是32位对齐，却把数据宽度设成了8位，每次传输只搬1字节，效率自然上不去；第二个高频错误是缓冲区地址没有对齐到总线宽度边界，导致DMA内部要拆分传输请求。

还有一个我踩过很多次的坑：数据宽度和地址递增不一致。DMA控制器的地址递增是“以数据宽度为单位”增长的。比如把每次传输的数据宽度设置成32位（4字节），地址递增就会每次增加4。但如果缓冲区定义成了uint8_t数组，你实际分配到的是每个元素1字节，和地址递增4之间就产生严重错位。这个问题经常在编译阶段发现不了，数据错乱又非常隐蔽。

测速代码调试时，可以先把DMA的优先级调高，排除掉总线仲裁的干扰，保证测出来的值接近该通道的极限。然后再调回正常优先级，观察多DMA并行时性能下降的比例。

4. 手把手配置一个串口DMA驱动

4.1 配置前的准备工作

这里我以STM32F4系列和HAL库为例，把串口DMA发送和接收的完整驱动框架写一遍。虽然各家芯片的底层寄存器不同，但配置流程是通用的：使能DMA控制器和外设时钟——配置DMA通道/流——设置外设地址、内存地址、数据长度——选择方向、优先级、数据宽度——使能中断——最后启动DMA请求。

准备工作包括：确定串口使用的DMA请求映射，比如USART1的接收请求对应DMA2 Stream2 Channel4，发送对应DMA2 Stream7 Channel4，这些映射关系在芯片参考手册里都有表格。必须先确认清楚了再写代码，不要随手复制上一个项目的配置。

4.2 串口DMA初始化代码

串口DMA发送的初始化，核心是配置一个内存到外设方向的DMA流。这里给出HAL库的参考写法，注意我为了演示把代码尽量精简了。

void uart_dma_tx_init(void) { __HAL_RCC_DMA2_CLK_ENABLE(); hdma_tx.Instance = DMA2_Stream7; hdma_tx.Init.Channel = DMA_CHANNEL_4; hdma_tx.Init.Direction = DMA_MEMORY_TO_PERIPH; hdma_tx.Init.PeriphInc = DMA_PINC_DISABLE; hdma_tx.Init.MemInc = DMA_MINC_ENABLE; hdma_tx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE; hdma_tx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE; hdma_tx.Init.Mode = DMA_NORMAL; hdma_tx.Init.Priority = DMA_PRIORITY_HIGH; hdma_tx.Init.FIFOMode = DMA_FIFOMODE_DISABLE; HAL_DMA_Init(&hdma_tx); __HAL_LINKDMA(&huart1, hdmatx, hdma_tx); HAL_NVIC_EnableIRQ(DMA2_Stream7_IRQn); }

几个关键点说一下。外设基地址不递增，因为串口发送只有那么一个数据寄存器；内存地址要递增，因为缓冲区是连续的。数据宽度设置为字节，配合串口8位数据帧格式。模式用普通模式，一次发送完成就停下来，不会自己重新开始。

串口DMA接收的初始化和发送差别不大，只需把方向改成外设到内存，内存地址递增、外设地址固定。但接收方向通常配成循环模式，方便配合空闲中断做不定长接收。

void uart_dma_rx_init(uint8_t *buf, uint16_t len) { __HAL_RCC_DMA2_CLK_ENABLE(); hdma_rx.Instance = DMA2_Stream2; hdma_rx.Init.Channel = DMA_CHANNEL_4; hdma_rx.Init.Direction = DMA_PERIPH_TO_MEMORY; hdma_rx.Init.PeriphInc = DMA_PINC_DISABLE; hdma_rx.Init.MemInc = DMA_MINC_ENABLE; hdma_rx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE; hdma_rx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE; hdma_rx.Init.Mode = DMA_CIRCULAR; hdma_rx.Init.Priority = DMA_PRIORITY_HIGH; hdma_rx.Init.FIFOMode = DMA_FIFOMODE_DISABLE; HAL_DMA_Init(&hdma_rx); __HAL_LINKDMA(&huart1, hdmarx, hdma_rx); HAL_DMA_Start(&hdma_rx, (uint32_t)&huart1.Instance->DR, (uint32_t)buf, len); __HAL_UART_ENABLE_IT(&huart1, UART_IT_IDLE); HAL_NVIC_EnableIRQ(DMA2_Stream2_IRQn); }

这里用了HAL_DMA_Start而不是HAL_UART_Receive_DMA，原因是我想自己控制接收缓冲区，不经过HAL库里那层缓冲管理。HAL库的Receive_DMA接口内部维护了一个缓冲状态，在做协议解析时容易绕进去，不如直接用底层接口，逻辑更清楚。

4.3 普通模式和循环模式的选择

收发两个方向我分别用了普通模式和循环模式，很多人不理解为什么这样选。发送方向一个包发完就结束了，用普通模式，传输完成中断里做收尾；接收方向要持续接收不同帧的数据，如果每次都用普通模式接收一帧就停，后续再来数据就没有DMA接管，必须重新启动，而重新启动的过程中容易丢数据，所以我更推荐接收用循环模式。

循环模式的问题是你不知道数据在哪一刻更新了。解决思路是利用串口IDLE中断作为分帧信号：数据停在缓冲区后，串口产生空闲中断，在中断里读取DMA数据计数器，得知当前已经接收了多少字节，再和上次处理位置相减，就能算出这一帧的长度。计数器只是相对位置，真正可靠的边界标记是“上一次处理到哪了”加上“现在计数器指到哪了”，所以驱动里要维护一个last_pos变量。

void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(&huart1); uint16_t cur_pos = rx_len - __HAL_DMA_GET_COUNTER(&hdma_rx); uint16_t recv_len = (cur_pos + rx_len - last_pos) % rx_len; if (recv_len != 0) { process_rx_frame(rx_buf + last_pos, recv_len); last_pos = cur_pos; } } }

注意取模运算，因为循环缓冲区在绕回起点时，计数器差值可能是负数。这个公式也是网上各种串口DMA接收例程最容易抄错的地方，不少人直接做减法，缓冲区绕回之后就错位，而且这种错位不是每次出现，只在长度跨边界时才出现，排查起来极其痛苦。

4.4 发送接口的封装和状态管理

发送侧要封装得容易使用，同时防止DMA还在忙时被重复调用。我用一个简单的状态变量控制，发送中禁止再次启动，接口返回忙状态，由上层决定是等待还是丢弃。

typedef enum { TX_IDLE = 0, TX_BUSY, } tx_state_t; volatile tx_state_t tx_state_flag = TX_IDLE; uint8_t uart_dma_send(uint8_t *buf, uint16_t len) { if (tx_state_flag == TX_BUSY) { return 0; /* 发送忙，返回失败 */ } tx_state_flag = TX_BUSY; HAL_UART_Transmit_DMA(&huart1, buf, len); return 1; } void DMA2_Stream7_IRQHandler(void) { if (__HAL_DMA_GET_FLAG(&hdma_tx, DMA_FLAG_TCIF3_7)) { __HAL_DMA_CLEAR_FLAG(&hdma_tx, DMA_FLAG_TCIF3_7); tx_state_flag = TX_IDLE; } HAL_DMA_IRQHandler(&hdma_tx); }

很多新人直接调用HAL_UART_Transmit_DMA就不管了，然后缓冲区被复用，导致发送数据随机出错。其实DMA传输完成中断里清理状态就是关键一步，它告诉你“缓冲区现在可以安全释放了”。我在每个发送接口的注释里都会专门强调：等tx_state_flag回到IDLE再复用缓冲区。

5. 避坑指南：DMA驱动的常见问题排查

5.1 缓存一致性：DMA和CPU看到的数据不一样

这是带D-Cache的高性能MCU上最经典的DMA坑，比如STM32F7、H7系列。CPU写入发送缓冲区之后，数据可能还待在CPU的缓存里，没有真正落到内存；这时候DMA外设直接去读取内存，读到的是旧的或者不完整的数据。反过来，DMA从外设接收到内存后，CPU再去读缓冲区，读到的可能是缓存里残留的旧数据。

解决方法是传输之前做缓存维护：发送前使用SCB_CleanDCache_by_Addr清理发送缓冲区对应的缓存行，让数据写回内存；接收完成后使用SCB_InvalidateDCache_by_Addr使接收缓冲区的缓存失效，强制CPU重新从内存加载。注意这里的地址必须按32字节对齐，长度也要对齐到32的整数倍，否则缓存行维护会漏掉边界。

调试时碰到DMA数据偶尔正确偶尔错误、代码逻辑怎么查都没问题的场合，优先怀疑缓存一致性问题。

5.2 数据错位、丢帧，这些现象背后是同一类原因

串口DMA接收最常见的现象是：一帧数据解析出来是乱的，字节顺序不对，或者第一帧正常第二帧就丢尾。大部分情况是因为处理框架没把“DMA搬运数据”和“协议解析数据”隔离好，典型错误是在IDLE中断里直接处理缓冲区，而这个缓冲区可能正被DMA继续写入。

正确的思路是把缓冲区划分成多个区段，或者用双缓冲。DMA写一半的时候，CPU处理另一半已经完成的数据，两边互不干扰。如果硬件不支持双缓冲，就采用“处理完一个区段再启动下一轮接收”的方案。

另一个丢帧原因是清IDLE标志的时机。IDLE标志需要在串口中断标志置位后及时清除，如果进入中断后先做了一堆耗时操作再清标志，这个帧的数据可能已经和下一帧粘连了。我习惯进入中断函数的第一件事就是清标志、取计数器，然后再去做协议解析。

5.3 中断优先级导致的死锁和性能问题

DMA完成中断和串口IDLE中断如果设计得不好，会造成一种很难查的“假死机”。举个例子，串口IDLE中断优先级配置得很低，而另一个高频中断优先级很高，且一直占用CPU；那么串口IDLE标志迟迟得不到响应，接收数据就停在缓冲区里，看起来像DMA没工作，实际上DMA一直在正常收数据，只是软件没去取。

反过来，如果把DMA中断优先级配得过高，中断函数里又做了大块数据的拷贝或者解析，就会阻塞其他关键中断，系统的实时性严重下降。经验做法是：DMA中断只做状态置位和极短的数据移动，协议解析放到主循环或者低优先级任务里执行。

5.4 常见问题速查表

排查DMA问题有一个通用原则：先确认外设侧，再查DMA侧，最后查内存侧。不少人一上来就怀疑DMA配置，改了几天发现原来是串口引脚复用没配好。先从外设能否在非DMA模式下正常工作开始，再用DMA方式对比，这样定位问题最快。

写在最后

DMA这个外设，说穿了就是一个提高了效率的数据搬运工。真正决定驱动写得好不好的，不是你初始化代码写得有多花哨，而是你有没有把“谁请求、谁搬运、谁处理、何时处理”这几个问题想清楚。我早期写DMA驱动，配置完能跑就觉得完事大吉，后来被串口丢帧、缓存不一致、总线冲突这些坑一个个教做人，才慢慢总结出上面这套方法：先理解硬件行为，再画数据流，最后写代码做状态管理。这套顺序反过来，多半要靠加班来偿还。希望这篇笔记能让你少走几步弯路，尤其是循环接收那部分取模运算，以及缓存维护那两行代码，建议直接抄进自己的驱动框架里，早晚用得上。