STM32定时器触发ADC+DMA双缓冲实现多通道高频数据采集

做多通道数据采集模块时，我遇到过最典型的需求就是“一边连续采，一边还要忙着把数据打包发出去”。一开始在主循环里轮询ADC等EOC标志，采样间隔抖得没法看，稍微加点业务逻辑，采样率就掉到几千赫兹。换成ADC中断读取缓冲，看似精准，其实CPU开销巨大，采样率20kHz时相当于每50us打断一次主程序，数据量上来后基本干不了别的活。最终稳定下来的方案就是标题这套组合——定时器触发ADC，DMA双缓冲搬数据，主循环只负责从缓冲区拿现成数据做业务处理。这篇博文不铺垫基础概念，直接讲清楚这套方案为什么能解决采样抖动和CPU占用问题，CubeMX里怎么配，代码落地怎么处理，以及我实际踩过的坑。适合正在做数据采集、信号处理、电机控制类项目的读者，F103和F4/H7系列都能参考。

1. 先捋清楚：轮询、单通道中断、单缓冲DMA各自卡在哪

很多新手一上来就搜“STM32 ADC读取”，搜到的基本是三种做法：主循环轮询、ADC中断、单缓冲DMA。这三种方案单独用都没问题，但放到“多通道+连续采集+高频触发”这个场景下，短板立刻暴露。

1.1 主循环轮询：采样率上不去的根源

轮询的代码最直观，无非是启动一次软件转换，然后死等EOC标志：

HAL_ADC_Start(&hadc1); // 依次读取多个通道 for (int i = 0; i < CH_NUM; i++) { HAL_ADC_PollForConversion(&hadc1, 10); ch_val[i] = HAL_ADC_GetValue(&hadc1); }

问题在于PollForConversion是阻塞的，ADC转换期间CPU就在那空转。如果是单通道还好，多通道扫描模式下，每个通道都要等转换完成，转换时间累加起来，主循环一轮的耗时被拉长。更致命的是，主循环里只要插入其他任务——显示刷新、按键扫描、通信处理——整段循环周期就会抖动，采集时间点也跟着抖。对采样间隔有明确要求的场景，这种抖动直接导致波形失真。

我早期做温度采集还能忍，后来切到振动信号采集，采样率要求15kHz以上，轮询方案彻底废掉：循环周期不稳定，做FFT（快速傅里叶变换）时频谱里全是杂散。

1.2 中断采样：高频率下的CPU灾难

轮询不行，就有人想到ADC转换完成中断。每次转换结束，CPU进中断，把数据搬走：

void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc) { uint16_t val = HAL_ADC_GetValue(&hadc); // 实际上这种用法常配合DMA buffer[i++] = val; }

表面看解决了主循环阻塞问题，但代价是中断频繁。单通道20kHz触发，意味着CPU每50us就要响应一次中断，压栈出栈、进出中断、处理回调，这些开销挤占了主程序资源。如果系统里还有CAN、定时器、串口等多个中断源，中断优先级稍没处理好，就会出现采样点丢失或顺序错乱。

到这一步我意识到，真正靠谱的方案得让ADC结果“自己搬家”，把CPU从搬运工的角色里解放出来，这就得靠DMA。

1.3 单缓冲DMA：能采但会断流

DMA+ADC是官方方案里最常用的一组搭档，ADC转换完成，DMA自动把数据存到内存，CPU不用管。单缓冲的做法是定义一块缓冲区：

uint16_t adc_buf[ADC_BUF_SIZE]; HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adc_buf, ADC_BUF_SIZE);

DMA循环模式（Circular）下，缓冲区写满后回绕从头继续写，过程不需要CPU介入。看着挺好，但你要“边采边用”就会发现问题：CPU处理缓冲区数据时，DMA可能正在往同一块缓冲区写新数据。采集中的数据被处理逻辑读走一半，下一轮新数据又覆盖进来，数据一致性完全没法保证。

单缓冲只有两条路：要么等DMA停止再处理，处理完再恢复采集——这个过程中空的样本没法补，数据流断裂；要么就冒着数据一直被覆盖的风险去“抢读”，结果每轮数据都是半新半旧的混合体。多通道场景更麻烦，通道错位、边界跳变全来了。

所以，要维持数据采集不中断，又要让CPU安心处理，必须有两块缓冲区交替工作——这就是DMA双缓冲的价值。

2. CubeMX里把时钟、ADC、DMA和定时器串成一条链路

方案落地第一步是CubeMX配置。这里有几个坑，特别是第一次配置的人，很容易被图形界面里的选项带偏。

2.1 ADC时钟与采样时间的换算矛盾

ADC时钟决定了转换速度，但每种芯片限制不同。STM32F103的ADC最大时钟是14MHz，常见配置是APB2为72MHz时，ADC预分频选6分频，得到12MHz。有些同学看到预分频有2、4、6、8，随手选4，得出18MHz，芯片虽然能用，但采样精度已经不在规格书保证范围内，数据容易非线性。

转换时间换算公式是：

总转换时间 = (采样周期 + 12.5个ADC时钟周期) × 通道数 / ADC时钟频率

那12.5个周期是12位ADC固定需要的转换周期数。假设采样周期设为1.5个周期，3通道，ADC时钟12MHz：

(1.5 + 12.5) × 3 / 12MHz ≈ 3.5us

这个3.5us意味着一轮3通道扫描的最短时间。后面计算定时器触发频率时，这个值就是硬约束，触发周期必须比它长，否则数据必然错乱。

但采样周期不是越小越好。信号源内阻大、PCB走线长时，采样保持电容来不及充电，采出来的值就是偏的。这时候要根据输入端阻抗适当拉长采样时间，常见做法是设到55.5周期甚至239.5周期，牺牲采样率换取精度。

2.2 DMA双缓冲的前提：先确认芯片支不支持

这里必须说一个多数教程没点破的事实：STM32F103的DMA没有硬件双缓冲功能，只有循环模式。真正意义上的DMA双缓冲（Double Buffer Mode，DBM）是F2/F4/F7/H7等系列才有的特性。F103想实现“双缓冲”效果，通常的做法是DMA循环模式+半传输中断，把一块缓冲区当两块用，属于“伪双缓冲”。这个我后面会展开。

芯片选型上的差异：

如果你现在还没定芯片，只是做数据采集类项目，建议直接用F4或H7，硬件双缓冲省很多事。F103上模拟出来的双缓冲虽然也能用，但调度上要格外小心，后面避坑部分会重点说。

在CubeMX里配DMA时，F4以上芯片的DMA设置里能看到“Mode”和“Memory to Memory”等选项，双缓冲不是在这里勾选的。F4的做法是先配置DMA为Circular模式，跑通基础采集后，代码里手动初始化双缓冲，具体代码第三章给。

2.3 定时器触发不是说配个TRGO就行

定时器触发的核心是让ADC的启动时机由硬件决定，而不是软件反复调用启动函数。CubeMX里需要做两步：

第一步，配置定时器。以TIM2为例，选择Internal Clock，预分频和自动重载值决定触发频率：

// 以72MHz时钟为例，1kHz触发 Prescaler = 72 - 1; // 分频后1MHz Counter Period = 1000 - 1; // 1MHz/1000 = 1kHz

第二步，把定时器TRGO事件连接到ADC。SetTriggerSource里有个关键选择，使用定时器触发时，ADC的Continuous Conversion Mode必须关闭（即外部触发模式），否则ADC会自己连续转换，根本不管定时器的触发信号，采样率直接失控。这个选项在CubeMX的ADC配置里叫Continuous Conversion Disabled，有人勾选后怎么改触发频率都没用，数据依然哗哗往里写，问题就出在这。

触发方式一般选“Trigger out event”或直接选定时器的TRGO上升沿，不同的HAL库版本叫法不同，本质一样：定时器计数溢出产生更新事件，事件映射到TRGO，TRGO信号触发ADC启动转换。配置完成后，生成的初始化代码里能看到类似这样的调用：

HAL_TIM_Base_Init(&htim2); HAL_TIM_Base_Start(&htim2); // 需要自己加，但手动启动前先确认定时器参数

别忘了在main函数里调用HAL_TIM_Base_Start_IT启动定时器，否则不会产生任何触发信号。

3. 双缓冲的代码实现：乒乓机制怎么落到HAL库

这一部分是核心，先说原理，再给可直接用的代码骨架。

3.1 乒乓的本质：两桶水交替接

假设DMA是水龙头，CPU是用水的人。只有一个水桶时，接满一桶水后得先停水、把桶拿去用、再拿回来接，中间水就断了。两个水桶就能流水线：DMA往A桶接水时，CPU用B桶里的水；A桶满了DMA自动切到B桶，CPU再处理A桶。两个桶交替，水流不断，谁也不用等谁。

对应到代码里，DMA硬件双缓冲模式下，DMA会自己按顺序先写缓冲区0，满了切换写缓冲区1，同时触发中断通知CPU处理缓冲区0；再满了切回缓冲区0，中断通知CPU处理缓冲区1。CPU处理一个缓冲区的时间，必须小于DMA填满另一个缓冲区的时间，这就是设计余量的核心约束。

3.2 F103的伪双缓冲：循环DMA+半传输中断

F103没有硬件双缓冲，但用循环模式加“半传输中断+全传输中断”也能模拟出两个半区的效果。假设定义一块256点的缓冲区，DMA从地址0开始写，写到128点（半满）时触发半传输中断，这时前半区128点数据稳定可处理；DMA继续写后半区，写满256点触发全传输中断，后半区数据稳定可处理。如此循环，逻辑上等于两块128点缓冲交替。

代码骨架：

#define BUF_LEN 256 uint16_t adc_buf[BUF_LEN]; // 分成两半使用 void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc->Instance == ADC1) { // 前半区数据就绪：adc_buf[0] ~ adc_buf[127] process_buffer(&adc_buf[0], BUF_LEN / 2); } } void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc->Instance == ADC1) { // 后半区数据就绪：adc_buf[128] ~ adc_buf[255] process_buffer(&adc_buf[BUF_LEN / 2], BUF_LEN / 2); } } // 初始化后启动 HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adc_buf, BUF_LEN);

注意，HAL_ADC_Start_DMA内部会启动DMA的传输完成中断和半传输中断，前提是CubeMX的NVIC设置里勾选了DMA中断通道。半传输中断触发HAL_ADC_ConvHalfCpltCallback，全传输中断触发HAL_ADC_ConvCpltCallback，这个映射是HAL库内部处理的，不用自己写DMA中断服务函数。

3.3 F4系列的真双缓冲：HAL_DMAEx_MultiBufferStart

如果芯片是F4以上，直接使用DMA硬件双缓冲，代码要稍微调整。基本思路是定义两块独立缓冲区，使用HAL库的多缓冲启动接口：

#define BUF_LEN 256 uint16_t dma_buf0[BUF_LEN]; uint16_t dma_buf1[BUF_LEN]; // 启动前先禁用DMA，防止状态冲突 __HAL_DMA_DISABLE(&hdma_adc1); HAL_DMAEx_MultiBufferStart(&hdma_adc1, (uint32_t)&ADC1->DR, // 外设地址 (uint32_t)dma_buf0, // 内存0 (uint32_t)dma_buf1, // 内存1 BUF_LEN); HAL_ADC_Start(&hadc1);

启动后，DMA自己管理两块缓冲区的交替，每次一个缓冲区填满，触发传输完成中断。回调里需要判断“当前DMA正写哪块缓冲区”，空闲的那个才是可以处理的数据：

void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc->Instance == ADC1) { // 读取DMA当前目标缓冲区标志，CT=0表示正在写内存0，CT=1表示正在写内存1 uint32_t ct = __HAL_DMA_GET_CT(&hdma_adc1); if (ct == 0) { // DMA正在写dma_buf0，空闲的是dma_buf1 process_buffer(dma_buf1, BUF_LEN); } else { process_buffer(dma_buf0, BUF_LEN); } } }

关键是__HAL_DMA_GET_CT这个宏，它读的是DMA控制寄存器里的Current Target位。第一次用真双缓冲时，我在这里卡了挺久，一直在想“怎么知道哪个缓冲区写完”，查寄存器手册才发现这个位就是为双缓冲准备的。

3.4 回调里到底能做什么

有人喜欢直接在回调里做数据运算、滤波、打包，我建议不要这么干。中断回调里停留时间越长，DMA覆盖缓冲区的可能性越大，因为伪双缓冲的时间约束是“处理半区数据的时间必须小于DMA写满半区的时间”。

正确做法是回调里只做两件事：把数据标记为“可处理”，或者拷贝一份到线程安全的数据队列。具体流程是：

volatile uint16_t *ready_ptr = NULL; volatile uint16_t ready_len = 0; void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc->Instance == ADC1) { ready_ptr = &adc_buf[0]; ready_len = BUF_LEN / 2; HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin); // 翻转IO做性能观测 } }

主循环或RTOS任务里检测到ready_len非零，就处理对应数据，处理完清零标志。如果处理逻辑太重，用环形队列缓冲，让数据先排队，不要让回调等。

4. 多通道数据还原：通道顺序、偏移计算和边界处理

到了多通道阶段，DMA缓冲区里不再是一个通道的连续数据，而是一组通道交替排列，这里有个非常经典的错位坑。

4.1 通道扫描顺序与DMA缓冲区的映射

CubeMX配置ADC时，可以添加多个Rank（转换序列），每个Rank指定一个通道和采样时间。DMA缓冲区里的数据顺序不是按通道号排的，而是按Rank顺序排的。

举个例子，我在配置里设置的Rank顺序是：

那么DMA缓冲区里的序列就是：CH0、CH2、CH1、CH0、CH2、CH1……永远按这个节奏重复。如果配置完我按通道号0、1、2去解析数据，后续所有通道数据全错位，尤其当不同通道电压差异大时，很容易看出数据是“跨通道跳变”的，查了半天才发现是Rank设置顺序的问题。

正确的解析逻辑应该是按Rank顺序：

// 一个完整采样组包含3个通道的数据 for (int i = 0; i < BUF_LEN; i += 3) { ch0_data[k] = adc_buf[i]; // Rank1 -> CH0 ch2_data[k] = adc_buf[i + 1]; // Rank2 -> CH2 ch1_data[k] = adc_buf[i + 2]; // Rank3 -> CH1 k++; }

缓冲区长度最好设为通道数的整数倍，否则最后一组数据不完整，处理时容易越界。

4.2 从码值到真实物理量的换算

ADC输出的是数字量，12位ADC的范围是0~4095，对应0V到参考电压VREF。换算公式：

电压值(V) = 采样码值 × VREF / 4095

如果VREF是3.3V，那么码值2048对应约1.65V。注意，这里的参考电压不是随便填的，必须等于ADC的VREF+引脚实际电压。有些开发板VREF接的是3.3V，有些接的是外部基准芯片，测不准时要先拿万用表量一下实际参考电压，再改换算系数。

如果项目对精度要求高，建议加均值滤波。多通道场景下可以对同一通道的多组数据做滑动平均，比如每16组数据求一次均值，能有效压制随机噪声。注意别把不同通道的数据混在一起求均值，那会把信号搞乱。

4.3 触发频率与转换时间必须算清楚

这是整套方案里最容易算错、也最容易出问题的地方。定时器触发频率不能拍脑袋，得先算ADC一轮扫描的总转换时间。

沿用前文的公式：

总转换时间 = (采样周期 + 12.5) × 通道数 / ADC时钟频率

比如F103，ADC时钟12MHz，3通道，采样周期55.5周期：

(55.5 + 12.5) × 3 / 12MHz ≈ 17us

对应的最大触发频率约58.8kHz。如果非要跑到100kHz，就必须把采样周期降到1.5周期：

(1.5 + 12.5) × 3 / 12MHz ≈ 3.5us

最大触发频率约285kHz。注意这是理论极限，实际工程里我建议留至少20%~30%余量，因为DMA写入、中断响应、CPU处理都有额外耗时，卡在极限值上很容易出隐性问题。

采样时间的选择逻辑是：先看信号源阻抗，决定最小采样周期；再看目标采样率，验证触发频率是否低于推荐值；最后才是去配置定时器。

5. 避坑实录：我在双缓冲方案里踩过的四个高频坑

这一节全是真实调试记录，按“症状、根因、排查、解决”的顺序写，照着排查能省不少时间。

5.1 半传输中断开了却没进回调

第一次在F103上做伪双缓冲，代码写好后发现只有HAL_ADC_ConvCpltCallback在触发，HAL_ADC_ConvHalfCpltCallback死活不执行。一开始怀疑是寄存器配置问题，进调试模式看DMACR的HTIE位，发现确实是使能的。后来查CubeMX的NVIC设置，才发现DMA的中断通道虽然勾了，但CubeMX默认生成的DMA中断服务函数只处理了传输完成中断，半传输中断的中断源在启动DMA时没有使能。

排查过程：

1. 在HAL_ADC_ConvHalfCpltCallback入口打上断点，程序没停，说明回调没被调用。
2. 进DMA1_Channel1_IRQHandler看一眼，发现只处理了TCIF标志。
3. 阅读HAL库源码，发现HAL_ADC_Start_DMA内部调用的HAL_DMA_Start_IT其实使能了HT和TC两个中断，问题不在HAL层，而在CubeMX生成的中断回调过滤逻辑里。
4. 检查后发现，是我自己在中断服务函数里多加了一层判断，把半传输中断标志过滤掉了。

解决方式是去掉多余过滤，或者直接让中断服务函数保持原样。很多人改中断服务函数时喜欢加自己的判断逻辑，结果把HAL库需要的标志给吞了，这类问题特别隐蔽。

5.2 定时器触发频率过高，数据直接错乱

有次把定时器触发频率从60kHz调到120kHz，出来的数据波形开始周期性跳变，每过一段就出现检测阈值范围外的大毛刺。通过逻辑分析仪看定时器TRGO波形，频率确实稳定在120kHz；用示波器测ADC触发到转换完成的时间，发现上一轮3通道转换还没结束，下一轮触发就来了。

关键代码计算：

3通道，采样周期1.5周期，ADC时钟12MHz 总转换时间 ≈ 3.5us，理论最高285kHz

120kHz虽然低于理论值，但示波器实测转换时间已经超过理论值不少，原因是PCB布局导致ADC输入端寄生电容偏大，采样保持时间被动拉长。这种情况下，要么降低触发频率到80kHz以下，要么给信号源加一级低阻驱动电路，把等效阻抗降下来。

这个坑提醒我：理论公式只是下限参考，实际还是以示波器实测为准，设计时留够余量，别在临界点附近跑。

5.3 编译优化后采样值全变

有一段代码在-O0优化下运行正常，切到-O2优化后，回调里的数据标志永远为0，主循环一直取不到数据。一开始以为是DMA配置被优化掉，后来发现是共享变量没加volatile限定。

问题是这样的：

uint8_t data_ready = 0; // 缺少volatile

主循环里判断data_ready时，编译器在-O2优化下认为这个变量在循环里没有被修改，直接把判断条件优化成了死循环，永远跳不出去。即使修改要在中断回调里写data_ready = 1，编译器也不感知中断上下文。

解决方式是所有在中断和主循环之间共享的变量，一律加volatile限定：

volatile uint8_t data_ready = 0;

DMA缓冲区是否需要加volatile要分情况。如果只是DMA往缓冲区写、CPU读，DMA写内存的行为编译器看不到，理论上也需要加。但加volatile后，编译器对这块内存的优化就会受限，访问速度会略降。折中做法是加内存屏障，比如在拷贝数据前执行__DMB()或__DSB()，确保DMA写入完成后再开始CPU读取。

5.4 双缓冲切换时读到半新半旧的数据

伪双缓冲方案里，处理前半区数据的回调刚运行到一半，DMA可能已经回绕到前半区开始写新数据了，这时候读取前半区末尾的数据，会拿到新旧掺杂的值。半区数据里出现不连续跳变，就是这个问题。

排查思路是先确认处理耗时：在回调入口翻转GPIO，用示波器测高电平时间，得出处理半区数据实际耗时；再计算DMA写满半区需要多久。F103场景下，如果定时器触发频率50kHz，半区128点，写满半区需要128/50kHz=2.56ms。只要处理耗时小于2.56ms，理论上不会覆盖。

如果处理耗时接近甚至超过了2.56ms，有几种应对：加大缓冲区，让半区点数更多，DMA写满半区的时间变长；降低触发频率；或者把处理拆到主循环，回调只置标志位。

真双缓冲芯片上这个问题会缓解一些，但如果处理时间超过单缓冲填充时间，同样会出现覆盖风险。缓冲区和处理速率的匹配是逃不掉的约束。

6. 上板验证与效果数据

整套方案落地后，验证环节不能省。我最常用的验证方式有三种：波形回放、线性度校验、CPU占用观测。

6.1 波形回放和线性度校验

信号发生器输出1kHz正弦波，幅度0~3.3V，接入一个采集通道。在某个缓冲处理函数里，把原始码值转成电压值，再通过串口DMA输出到PC，用串口绘图工具画波形。如果看到连续正弦波，没有毛刺、没有跳变，说明定时器触发和DMA搬运正常。

线性度校验收尾再做：给通道输入0V、1V、2V、3.3V几个直流电平，记录采样平均值。换算成电压后与万用表实测值对比，误差通常应在±1%以内。如果低电压段偏差明显，大概率是采样周期太短导致采样保持电容充电不足，把采样周期调大即可。

6.2 CPU占用的观测方法

测量CPU占用率不需要复杂工具，直接在回调处理函数前后翻转一个GPIO，用示波器看高电平占空比。例如3通道、50kHz触发、每128点处理一次，处理耗时约700us，那么CPU在数据处理上的占用率大约是：

处理一次耗时 / 半区填充周期 = 0.7ms / 2.56ms ≈ 27%

这个占比在可接受范围内。如果同样的采样率换成ADC中断方案，50kHz意味着每20us进一次中断，CPU基本被吃掉大半，双缓冲的优势一目了然。

6.3 实测效果总结

我在这套配置下跑了较长时间的高频采集，没有出现过采样错位和数据丢失。关键参数记录如下：

整套方案的体验是：定时器触发让采样间隔完全由硬件决定，示波器上看采样点的时间间隔相当均匀；DMA双缓冲让数据搬运不影响采集连续性，主循环拿到数据后可以做打包、传输、存储这些正经事。想进一步优化，可以把处理函数里的浮点运算改定点运算，或者把数据处理拆到RTOS低优先级任务里，CPU占用还能再低一些。

说到根本，这套方案的思路就是“能交给硬件的别让软件做”，定时器管节奏，DMA管搬运，CPU只做判断和处理。用下来稳定性比纯中断方式高一个量级，排查起来也清晰——采样有问题先看定时器波形，再查DMA寄存器，基本能快速定位。如果非要给后来者一句建议，那就是：不要急着上多通道，先用单通道把触发和双缓冲链路跑通，再逐步加通道，排查范围越小，问题浮出水面越快。