1. 方案设计与思路拆解为什么是定时器触发DMA搬运做嵌入式有些年头的人应该都有这种感觉ADC采样这件事看起来简单真正做扎实了却不容易。很多人一开始都是直接在主循环里调HAL_ADC_Start()然后阻塞等待转换完成再读结果。这种方式在小项目里够用可一旦遇到高频采样或者多通道采集问题立刻暴露出来——CPU被反复打断程序到处是等待标志位的代码数据稍微多一点就手忙脚乱。我最初接触STM32H743的ADC时也被这颗芯片的配置复杂度吓了一跳。H743内置3个独立ADC分别是ADC1、ADC2和ADC3采样率理论上能达到数MSPS级别正经算下来性能非常能打。但问题在于如果你只会用阻塞式读取那这些性能基本白瞎了。后来我自己搭了一套定时器触发DMA搬运的采集链路才真正感觉到什么叫“数据自己会流”。这套方案有一个很形象的类比定时器触发是心跳ADC是传感器前端DMA是搬运工。定时器按固定频率“砰砰”跳动ADC听到一次心跳就采一次样采样结果被DMA自动搬进内存整个过程CPU不用管数据是怎么流动的。CPU只在数据搬完一帧的时候被叫醒一次处理完再睡回去。主循环里那些花在等待和拷贝上的时间一下解放了出来。这套架构解决的核心问题就三个一是采样时刻精确可控二是数据搬运不占CPU三是CPU只在必要时刻介入。对做电机控制、逆变器、音频采集、振动监测这类场景的朋友来说这三个点恰恰是刚需。你在网上搜STM32H743和ADC会看到大量关于“采样周期怎么配”“ADC时钟多少合适”的讨论但真正把触发机制和数据流串起来讲的其实不多。这篇文章就是从实践出发把链路里的每个环节拆开讲透。这套方案适合谁来参考我认为分三类人。第一类是刚把H743跑起来想把ADC用熟的开发者第二类是项目里对CPU占用率有硬指标的人比如你跑着屏幕刷新又跑着算法库留给ADC的死时间本来就少第三类是采样频率要求高、时序要求严格的工控和音频开发者。不同基础的人看这篇文章收获点可能不同但整套链路搭完你能明显感觉到程序的气质变了——代码清爽数据稳定CPU干正事的时间多了。2. 核心细节解析与实操要点2.1 STM32H743的ADC时钟链路别人的上限不是你的上限很多人在H743上配ADC时钟时喜欢直接照搬F103那套经验这其实是踩坑的开端。H743的ADC时钟挂在ADC专用PLL上而不是简单的APB2分频。芯片内部有一个PLL2专门给ADC供电和提供时钟你可以通过RCC_PLL2单独配置。我第一次配置时直接用HAL_RCCEx_GetPeriphCLKConfig()把PLL2的输出设成了200MHz再分频给ADC。这里提醒一句H743的ADC最高工作时钟是50MHz超过这个值会导致采样结果不稳定这是你在数据手册里能找到的硬指标。有些人看H743主频480MHz想当然地认为ADC时钟也能拉高结果采样数据跳得跟心电图似的。正确的做法是把PLL2配置到200MHz让ADC分配器分到50MHz这个组合业内验证最稳。还要注意一个关键点ADC的采样周期和转换周期是两回事。每个通道的采样时间可以单独设置选择范围从1.5周期到810.5周期不等。刚上手的人容易把采样周期理解成转换周期导致实际采样频率和预期对不上。我试过用8.5周期的采样时间配合12位分辨率单个通道的转换总时长大约是8.512.521个ADC时钟周期。算一下就是21÷50MHz420ns换算成采样率就是约2.38MSPS。这个数字对我来说完全够用。2.2 触发源怎么选规则组、注入组与定时器TRGOH743的ADC有两组通道规则组和注入组。规则组是主采集组适合连续扫描多个通道注入组带优先级适合紧急插入的采集任务。日常做数据流采集90%的情况用规则组就够了。触发源的选择才是关键。每个ADC可以被定时器事件、外部引脚、软件触发等多种方式触发。这里我强烈建议用定时器的TRGO事件来触发ADC。TRGO全称是Trigger Output定时器在计数的过程中可以在特定时刻输出一个触发信号这个信号直接连到ADC的触发输入端。比起软件触发硬件触发的好处是时间精度高不受中断延迟和代码执行顺序影响。我用的定时器是TIM2工作在PWM模式周期设成采样间隔的对应值。比如我想让ADC每秒采样100k次定时器时钟是200MHz那么ARR的值就是200MHz÷100kHz2000。配好之后定时器每到更新事件就输出TRGO脉冲ADC接到脉冲立刻启动一次转换。这样采样间隔的抖动可以控制在几十纳秒以内对工频信号采样、振动波形还原这类场景来说抖动小特别重要。触发源的映射关系也别搞错了。H743里TIM2的TRGO可以触发ADC1、ADC2和ADC3但TIM1、TIM8这类高级定时器的映射关系又不一样。配错的话ADC死活不启动查了半天最后一拍大腿——映射不对。配置时翻一下参考手册里的Table里面列了“ADC trigger connections”一览表对照着选最稳妥。2.3 DMA搬运用的是哪条道DMA1还是DMA2触发源解决之后下一个头疼的问题是DMA通道选择。H743的DMA有两个控制器DMA1和DMA2每个控制器下有一堆Stream数据流。ADC的结果寄存器挂在哪条DMA通道上必须查到具体映射关系然后在CubeMX里精准匹配不然编译能过运行起来DMA就是干的着急搬不到数据。这里提一个容易忽略的点H743的ADC1和ADC2在双模式下的DMA请求路径跟单模式不同。如果你只开ADC1DMA请求走的是DMA1对应通道但如果你要同时用ADC1和ADC2并且让它们通过双模式协同采样DMA请求的挂载点就变了。我第一次尝试双ADC交错采样时就因为在双模式下配错了DMA Stream导致数据流断断续续折腾了一整天才反应过来。我最终的配置方案是走ADC1的单个DMA StreamDMA传输模式设为循环模式。循环模式的好处是DMA搬完一整轮数据后不用CPU介入自动重新开始搬运。你只需要在初始化时给它一个目标缓冲区地址和传输长度它就一直在那儿勤勤恳恳地跑直到你显式停止它。这个设计非常贴合数据流采集的场景——采集工作本身就应该是后台的、持续的。2.4 数据宽度与内存对齐别让硬件帮你“隐式转换”ADC的结果寄存器是32位的但实际有效数据只占其中的16位右对齐时为bit15~bit0左对齐时是bit31~bit16。DMA搬运时数据宽度的设置就变得很微妙。如果你把DMA源地址数据宽度设为字32位目标地址也设为32位那么搬运一次就是4字节缓冲区长度的含义会跟着变。最稳的做法是把DMA数据传输宽度统一为半字16位源地址是ADC_DR的低16位目标地址是uint16_t数组。这样缓冲区长度和采样点数一一对应解析数据时不用做任何移位和掩码操作。我见过有人为了省空间用uint16_t接收DMA配置却是32位宽度结果缓冲区内每隔一个采样点就多出两个无效字节数据全乱了。内存对齐也有讲究。DMA缓冲区最好声明为32位对齐特别是在开Cache的情况下。H743有D-Cache如果你在数据采集过程中让DMA往带Cache的内存区域写数据而CPU又同时去读这块区域就会出现缓存一致性问题。解决办法要么把缓冲区定义在.RAM_D1区域并配置为不缓存要么在读取前做一次SCB_InvalidateDCache_by_Addr()操作。后者更通用但会带来微小的性能开销需要权衡。3. 实操过程与核心环节实现一套能直接跑的代码框架3.1 CubeMX配置要点存档我用STM32CubeMX生成的项目为基础把关键配置说透。芯片选择STM32H743VIT6外设树里依次打开ADC1启用规则组通道选择IN0或IN1这类你实际使用的引脚触发源选择Timer 2 Trigger Out event连续转换模式关掉因为我们要靠定时器来驱动单次转换TIM2时钟源选内部时钟PWM模式或者直接配成Update事件输出TRGODMA设置ADC1的DMA请求Stream选择参考数据手册里ADC1对应的那个方向外设到内存模式循环数据宽度两边都是半字时钟树先把PLL2配置到200MHz然后确认ADC时钟分配器输出50MHz。CubeMX生成代码之后我们要干的第一件事是删掉HAL_ADC_Start()这个调用。为什么因为我们要启用的是DMA采集模式应该用HAL_ADC_Start_DMA()它会自动把ADC和DMA都启动起来而且不会阻塞。在定时器还没启动之前ADC就安静地等在那儿什么都不干。/* 初始化完成之后在main函数中执行 */ HAL_TIM_Base_Start(htim2); /* 启动定时器开始产生TRGO */ HAL_ADC_Start_DMA(hadc1, (uint32_t *)adc_buffer, ADC_BUFFER_LEN);定时器必须先启动吗其实顺序无所谓但先启动定时器再启动ADC的DMA采集时DMA缓冲区里可能存着定时器跑起来之后才产生的第一波数据。对于分析采样时刻的完整性来说这个细节影响不大但强迫症的话可以先启动DMA再启动定时器。3.2 DMA缓冲区与半传输中断的双缓冲策略ADC_BUFFER_LEN设成多大直接关系到数据处理的实时性。缓冲区太小CPU被频繁打断去搬数据缓冲区太大数据延迟就大系统响应速度变慢。一个常见做法是把缓冲区设成两帧用DMA的半传输中断和传输完成中断来交叉处理数据。假设我想每处理256个采样点做一次FFT我就把DMA缓冲区设成512个采样点。DMA搬满256个采样点时触发半传输中断此时CPU处理前256个数据DMA继续往后搬搬满512个时触发传输完成中断CPU处理后256个数据。由于DMA是循环模式这个流程周而复始数据永远在流水线上流动。这种双缓冲策略在音频采集上尤其好用INT16样本流处理起来特别丝滑。3.3 让数据从“一个个数”变成“一帧帧帧”数据流处理的核心思维是不要每次从DMA缓冲区里抠一个点出来算而是凑齐一批数据再统一处理。这就是帧的概念。我用的是回调函数。HAL库会在DMA半传输完成和传输完成时分别调用HAL_ADC_ConvCpltCallback和HAL_ADC_ConvHalfCpltCallback。我在回调里设置一个标志位主循环检测到标志位置位就处理对应的半帧数据。注意中断服务函数里不要做浮点运算和耗时操作只管置标志位即可。volatile uint16_t dma_frame_ready 0; volatile uint8_t frame_index 0; void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc-Instance ADC1) { frame_index 0; dma_frame_ready 1; } } void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc-Instance ADC1) { frame_index 1; dma_frame_ready 1; } } /* 主循环中 */ while (1) { if (dma_frame_ready) { process_frame(adc_buffer[frame_index * 256]); dma_frame_ready 0; } }实际跑下来CPU在100kHz采样率下几乎无感主循环里还能腾出大量时间跑界面刷屏和通信协议。这比之前用中断逐点读ADC结果的方式强太多了程序结构也整体上了一个台阶。3.4 多通道扫描模式下的数据排列如果你要同时采集多路信号比如三相电流加母线电压规则组可以按顺序把多个通道排在序列里。DMA搬出来的数据是一个接着一个的通道值例如通道0、通道1、通道2、通道0、通道1、通道2……在处理时就要按通道数切帧。H743的规则组最多支持16个序列位置但每个序列位置对应的通道号可以重复。实际项目里我一般用4个通道做一轮DMA缓冲区长度设成4的整数倍加对齐。这样每一轮DMA数据正好对应一轮完整的多通道采样。注意双ADC模式下ADC1和ADC2交错采样时DMA拿到的数据排列顺序跟单ADC模式不同。双模式下的数据是32位的高16位来自ADC2低16位来自ADC1。很多人第一次开着双通道模式却发现数据全是乱的多半就是没有对32位数据做拆解。我看过不少论坛帖子都在问这个说实话只要看一遍ADC_CDR寄存器Common Data Register的位描述就明白了。4. 常见问题与排查技巧实录4.1 ADC数据一直为零或者卡死在同一个值这是新手最容易遇到的问题。数据一直为零先检查ADC的通道引脚是否配置成模拟模式。CubeMX里如果忘了把引脚设为ADC_IN的Analog模式GPIO寄存器会默认输出模式读回来的数据自然不是有效值。另一种情况是数据卡死在某个固定值比如4095或者0这时候要怀疑采样保持电容是否被充电到了错误电平。最常见的原因是引脚悬空对于高阻抗的采样电路来说悬空引脚上微弱的漏电流就能让ADC结果漂移不定。解决办法是给外部引脚加一个电容到地或者启用ADC内部的看门狗和偏置校准功能做辅助判断。4.2 DMA搬运的数据跟预期对不上长度还是字节数HAL库的HAL_ADC_Start_DMA()最后一个参数是Length很多人在填这个参数时会犯迷糊。在H743的HAL库实现里这个长度是“数据项数”而不是“字节数”。如果DMA数据宽度是半字那么长度填256代表256个半字占512字节。如果你误把这个长度理解成字节数填了128实际只搬了64个样本后续处理时会发现数据点数不对、频域分析也不对。我之前就栽在这个地方过。后来学聪明了在初始化之后主动读一下DMA的NDTR寄存器调试时打印出来一眼就能确认配置是否跟预期一致。4.3 采样抖动大、波形毛刺多用定时器硬件触发之后理论上采样抖动应该很小。但如果你启动的是“连续转换模式”同时又用了定时器触发两者会打架。连续转换模式下ADC转换完一个通道后会立刻开始下一个完全无视定时器触发脉冲。所以用定时器触发的正确姿势是关闭连续转换模式开启单次转换模式或者“触发模式”。另外ADC参考电压的稳定也很关键。H743的VREF引脚如果没做好滤波采样结果会跟着参考源的噪声起伏。硬件设计上VREF附近一定要放一个0.1uF的陶瓷电容和1uF的钽电容离引脚越近越好。4.4 采样率提不上去DMA忙不过来如果你配置的采样率超过了ADC的实际能力DMA缓冲区里的数据就会变成新旧交错的乱码。ADC完成一次转换需要固定时间比如50MHz时钟下12位转换约21个周期。如果你让定时器每400ns就触发一次转换ADC根本干不完。这种问题在调试时特别隐蔽因为触发信号很干净ADC却没到“就绪”状态就去响应下一次触发。解决办法是以ADC的实际转换时间上限为准反推定时器触发频率上限。别贪把触发频率设置在ADC吞吐率的80%~90%之间留出裕量整个系统会稳定很多。5. 扩展玩法不只是波形采集还能直接对接算法链链路搭好之后你会发现手里的这条数据流特别值钱。因为CPU占用低、数据连续稳定后续不管是做滤波、FFT、PID控制还是故障特征提取都有了可靠的数据源。我用这套方案做过一个三相电机电流采集的小系统。定时器固定10kHz触发ADCDMA把三相电流和母线电压连续搬进缓冲主循环里跑Clarke变换和Park变换再把数据通过串口DMA发送到上位机。整个系统的CPU占用率连15%都不到剩余的资源全部用于跑电机控制算法。放在以前用中断逐点采集的时候这个性能想都不敢想。我实测过同一套代码如果把ADC时钟从50MHz降到25MHz功耗会明显降低但采样精度在大多数场景下感知不到差别。如果你的系统对功耗敏感可以尝试降低ADC时钟代价仅仅是分辨率在高频段略微下降。还可以考虑把三个ADC全部利用起来ADC1采电压、ADC2采电流、ADC3采温度三个ADC独立触发、独立DMA互不干扰。这样传感器数据全部并行采集同步性比单个ADC分时扫描好很多。要说缺点就是对DMA通道资源要求高了用之前先check一下DMA映射表看看哪个Stream还能空出来。我在实际使用中最满意的一点是这套方案的代码风格非常统一。初始化配置集中在一个函数里回调里只置标志位主循环只做帧处理。哪怕隔了三个月回头再看代码也能很快进入状态不用一行行去追实现细节。如果后面想继续深挖还可以试试注入组通道配合外部触发做“紧急优先级采样”或者把采样数据直接通过LTDC显示成实时波形。思路打开了这套机制的潜力会超出你最初的需求。
1. 方案设计与思路拆解为什么是定时器触发DMA搬运做嵌入式有些年头的人应该都有这种感觉ADC采样这件事看起来简单真正做扎实了却不容易。很多人一开始都是直接在主循环里调HAL_ADC_Start()然后阻塞等待转换完成再读结果。这种方式在小项目里够用可一旦遇到高频采样或者多通道采集问题立刻暴露出来——CPU被反复打断程序到处是等待标志位的代码数据稍微多一点就手忙脚乱。我最初接触STM32H743的ADC时也被这颗芯片的配置复杂度吓了一跳。H743内置3个独立ADC分别是ADC1、ADC2和ADC3采样率理论上能达到数MSPS级别正经算下来性能非常能打。但问题在于如果你只会用阻塞式读取那这些性能基本白瞎了。后来我自己搭了一套定时器触发DMA搬运的采集链路才真正感觉到什么叫“数据自己会流”。这套方案有一个很形象的类比定时器触发是心跳ADC是传感器前端DMA是搬运工。定时器按固定频率“砰砰”跳动ADC听到一次心跳就采一次样采样结果被DMA自动搬进内存整个过程CPU不用管数据是怎么流动的。CPU只在数据搬完一帧的时候被叫醒一次处理完再睡回去。主循环里那些花在等待和拷贝上的时间一下解放了出来。这套架构解决的核心问题就三个一是采样时刻精确可控二是数据搬运不占CPU三是CPU只在必要时刻介入。对做电机控制、逆变器、音频采集、振动监测这类场景的朋友来说这三个点恰恰是刚需。你在网上搜STM32H743和ADC会看到大量关于“采样周期怎么配”“ADC时钟多少合适”的讨论但真正把触发机制和数据流串起来讲的其实不多。这篇文章就是从实践出发把链路里的每个环节拆开讲透。这套方案适合谁来参考我认为分三类人。第一类是刚把H743跑起来想把ADC用熟的开发者第二类是项目里对CPU占用率有硬指标的人比如你跑着屏幕刷新又跑着算法库留给ADC的死时间本来就少第三类是采样频率要求高、时序要求严格的工控和音频开发者。不同基础的人看这篇文章收获点可能不同但整套链路搭完你能明显感觉到程序的气质变了——代码清爽数据稳定CPU干正事的时间多了。2. 核心细节解析与实操要点2.1 STM32H743的ADC时钟链路别人的上限不是你的上限很多人在H743上配ADC时钟时喜欢直接照搬F103那套经验这其实是踩坑的开端。H743的ADC时钟挂在ADC专用PLL上而不是简单的APB2分频。芯片内部有一个PLL2专门给ADC供电和提供时钟你可以通过RCC_PLL2单独配置。我第一次配置时直接用HAL_RCCEx_GetPeriphCLKConfig()把PLL2的输出设成了200MHz再分频给ADC。这里提醒一句H743的ADC最高工作时钟是50MHz超过这个值会导致采样结果不稳定这是你在数据手册里能找到的硬指标。有些人看H743主频480MHz想当然地认为ADC时钟也能拉高结果采样数据跳得跟心电图似的。正确的做法是把PLL2配置到200MHz让ADC分配器分到50MHz这个组合业内验证最稳。还要注意一个关键点ADC的采样周期和转换周期是两回事。每个通道的采样时间可以单独设置选择范围从1.5周期到810.5周期不等。刚上手的人容易把采样周期理解成转换周期导致实际采样频率和预期对不上。我试过用8.5周期的采样时间配合12位分辨率单个通道的转换总时长大约是8.512.521个ADC时钟周期。算一下就是21÷50MHz420ns换算成采样率就是约2.38MSPS。这个数字对我来说完全够用。2.2 触发源怎么选规则组、注入组与定时器TRGOH743的ADC有两组通道规则组和注入组。规则组是主采集组适合连续扫描多个通道注入组带优先级适合紧急插入的采集任务。日常做数据流采集90%的情况用规则组就够了。触发源的选择才是关键。每个ADC可以被定时器事件、外部引脚、软件触发等多种方式触发。这里我强烈建议用定时器的TRGO事件来触发ADC。TRGO全称是Trigger Output定时器在计数的过程中可以在特定时刻输出一个触发信号这个信号直接连到ADC的触发输入端。比起软件触发硬件触发的好处是时间精度高不受中断延迟和代码执行顺序影响。我用的定时器是TIM2工作在PWM模式周期设成采样间隔的对应值。比如我想让ADC每秒采样100k次定时器时钟是200MHz那么ARR的值就是200MHz÷100kHz2000。配好之后定时器每到更新事件就输出TRGO脉冲ADC接到脉冲立刻启动一次转换。这样采样间隔的抖动可以控制在几十纳秒以内对工频信号采样、振动波形还原这类场景来说抖动小特别重要。触发源的映射关系也别搞错了。H743里TIM2的TRGO可以触发ADC1、ADC2和ADC3但TIM1、TIM8这类高级定时器的映射关系又不一样。配错的话ADC死活不启动查了半天最后一拍大腿——映射不对。配置时翻一下参考手册里的Table里面列了“ADC trigger connections”一览表对照着选最稳妥。2.3 DMA搬运用的是哪条道DMA1还是DMA2触发源解决之后下一个头疼的问题是DMA通道选择。H743的DMA有两个控制器DMA1和DMA2每个控制器下有一堆Stream数据流。ADC的结果寄存器挂在哪条DMA通道上必须查到具体映射关系然后在CubeMX里精准匹配不然编译能过运行起来DMA就是干的着急搬不到数据。这里提一个容易忽略的点H743的ADC1和ADC2在双模式下的DMA请求路径跟单模式不同。如果你只开ADC1DMA请求走的是DMA1对应通道但如果你要同时用ADC1和ADC2并且让它们通过双模式协同采样DMA请求的挂载点就变了。我第一次尝试双ADC交错采样时就因为在双模式下配错了DMA Stream导致数据流断断续续折腾了一整天才反应过来。我最终的配置方案是走ADC1的单个DMA StreamDMA传输模式设为循环模式。循环模式的好处是DMA搬完一整轮数据后不用CPU介入自动重新开始搬运。你只需要在初始化时给它一个目标缓冲区地址和传输长度它就一直在那儿勤勤恳恳地跑直到你显式停止它。这个设计非常贴合数据流采集的场景——采集工作本身就应该是后台的、持续的。2.4 数据宽度与内存对齐别让硬件帮你“隐式转换”ADC的结果寄存器是32位的但实际有效数据只占其中的16位右对齐时为bit15~bit0左对齐时是bit31~bit16。DMA搬运时数据宽度的设置就变得很微妙。如果你把DMA源地址数据宽度设为字32位目标地址也设为32位那么搬运一次就是4字节缓冲区长度的含义会跟着变。最稳的做法是把DMA数据传输宽度统一为半字16位源地址是ADC_DR的低16位目标地址是uint16_t数组。这样缓冲区长度和采样点数一一对应解析数据时不用做任何移位和掩码操作。我见过有人为了省空间用uint16_t接收DMA配置却是32位宽度结果缓冲区内每隔一个采样点就多出两个无效字节数据全乱了。内存对齐也有讲究。DMA缓冲区最好声明为32位对齐特别是在开Cache的情况下。H743有D-Cache如果你在数据采集过程中让DMA往带Cache的内存区域写数据而CPU又同时去读这块区域就会出现缓存一致性问题。解决办法要么把缓冲区定义在.RAM_D1区域并配置为不缓存要么在读取前做一次SCB_InvalidateDCache_by_Addr()操作。后者更通用但会带来微小的性能开销需要权衡。3. 实操过程与核心环节实现一套能直接跑的代码框架3.1 CubeMX配置要点存档我用STM32CubeMX生成的项目为基础把关键配置说透。芯片选择STM32H743VIT6外设树里依次打开ADC1启用规则组通道选择IN0或IN1这类你实际使用的引脚触发源选择Timer 2 Trigger Out event连续转换模式关掉因为我们要靠定时器来驱动单次转换TIM2时钟源选内部时钟PWM模式或者直接配成Update事件输出TRGODMA设置ADC1的DMA请求Stream选择参考数据手册里ADC1对应的那个方向外设到内存模式循环数据宽度两边都是半字时钟树先把PLL2配置到200MHz然后确认ADC时钟分配器输出50MHz。CubeMX生成代码之后我们要干的第一件事是删掉HAL_ADC_Start()这个调用。为什么因为我们要启用的是DMA采集模式应该用HAL_ADC_Start_DMA()它会自动把ADC和DMA都启动起来而且不会阻塞。在定时器还没启动之前ADC就安静地等在那儿什么都不干。/* 初始化完成之后在main函数中执行 */ HAL_TIM_Base_Start(htim2); /* 启动定时器开始产生TRGO */ HAL_ADC_Start_DMA(hadc1, (uint32_t *)adc_buffer, ADC_BUFFER_LEN);定时器必须先启动吗其实顺序无所谓但先启动定时器再启动ADC的DMA采集时DMA缓冲区里可能存着定时器跑起来之后才产生的第一波数据。对于分析采样时刻的完整性来说这个细节影响不大但强迫症的话可以先启动DMA再启动定时器。3.2 DMA缓冲区与半传输中断的双缓冲策略ADC_BUFFER_LEN设成多大直接关系到数据处理的实时性。缓冲区太小CPU被频繁打断去搬数据缓冲区太大数据延迟就大系统响应速度变慢。一个常见做法是把缓冲区设成两帧用DMA的半传输中断和传输完成中断来交叉处理数据。假设我想每处理256个采样点做一次FFT我就把DMA缓冲区设成512个采样点。DMA搬满256个采样点时触发半传输中断此时CPU处理前256个数据DMA继续往后搬搬满512个时触发传输完成中断CPU处理后256个数据。由于DMA是循环模式这个流程周而复始数据永远在流水线上流动。这种双缓冲策略在音频采集上尤其好用INT16样本流处理起来特别丝滑。3.3 让数据从“一个个数”变成“一帧帧帧”数据流处理的核心思维是不要每次从DMA缓冲区里抠一个点出来算而是凑齐一批数据再统一处理。这就是帧的概念。我用的是回调函数。HAL库会在DMA半传输完成和传输完成时分别调用HAL_ADC_ConvCpltCallback和HAL_ADC_ConvHalfCpltCallback。我在回调里设置一个标志位主循环检测到标志位置位就处理对应的半帧数据。注意中断服务函数里不要做浮点运算和耗时操作只管置标志位即可。volatile uint16_t dma_frame_ready 0; volatile uint8_t frame_index 0; void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc-Instance ADC1) { frame_index 0; dma_frame_ready 1; } } void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc-Instance ADC1) { frame_index 1; dma_frame_ready 1; } } /* 主循环中 */ while (1) { if (dma_frame_ready) { process_frame(adc_buffer[frame_index * 256]); dma_frame_ready 0; } }实际跑下来CPU在100kHz采样率下几乎无感主循环里还能腾出大量时间跑界面刷屏和通信协议。这比之前用中断逐点读ADC结果的方式强太多了程序结构也整体上了一个台阶。3.4 多通道扫描模式下的数据排列如果你要同时采集多路信号比如三相电流加母线电压规则组可以按顺序把多个通道排在序列里。DMA搬出来的数据是一个接着一个的通道值例如通道0、通道1、通道2、通道0、通道1、通道2……在处理时就要按通道数切帧。H743的规则组最多支持16个序列位置但每个序列位置对应的通道号可以重复。实际项目里我一般用4个通道做一轮DMA缓冲区长度设成4的整数倍加对齐。这样每一轮DMA数据正好对应一轮完整的多通道采样。注意双ADC模式下ADC1和ADC2交错采样时DMA拿到的数据排列顺序跟单ADC模式不同。双模式下的数据是32位的高16位来自ADC2低16位来自ADC1。很多人第一次开着双通道模式却发现数据全是乱的多半就是没有对32位数据做拆解。我看过不少论坛帖子都在问这个说实话只要看一遍ADC_CDR寄存器Common Data Register的位描述就明白了。4. 常见问题与排查技巧实录4.1 ADC数据一直为零或者卡死在同一个值这是新手最容易遇到的问题。数据一直为零先检查ADC的通道引脚是否配置成模拟模式。CubeMX里如果忘了把引脚设为ADC_IN的Analog模式GPIO寄存器会默认输出模式读回来的数据自然不是有效值。另一种情况是数据卡死在某个固定值比如4095或者0这时候要怀疑采样保持电容是否被充电到了错误电平。最常见的原因是引脚悬空对于高阻抗的采样电路来说悬空引脚上微弱的漏电流就能让ADC结果漂移不定。解决办法是给外部引脚加一个电容到地或者启用ADC内部的看门狗和偏置校准功能做辅助判断。4.2 DMA搬运的数据跟预期对不上长度还是字节数HAL库的HAL_ADC_Start_DMA()最后一个参数是Length很多人在填这个参数时会犯迷糊。在H743的HAL库实现里这个长度是“数据项数”而不是“字节数”。如果DMA数据宽度是半字那么长度填256代表256个半字占512字节。如果你误把这个长度理解成字节数填了128实际只搬了64个样本后续处理时会发现数据点数不对、频域分析也不对。我之前就栽在这个地方过。后来学聪明了在初始化之后主动读一下DMA的NDTR寄存器调试时打印出来一眼就能确认配置是否跟预期一致。4.3 采样抖动大、波形毛刺多用定时器硬件触发之后理论上采样抖动应该很小。但如果你启动的是“连续转换模式”同时又用了定时器触发两者会打架。连续转换模式下ADC转换完一个通道后会立刻开始下一个完全无视定时器触发脉冲。所以用定时器触发的正确姿势是关闭连续转换模式开启单次转换模式或者“触发模式”。另外ADC参考电压的稳定也很关键。H743的VREF引脚如果没做好滤波采样结果会跟着参考源的噪声起伏。硬件设计上VREF附近一定要放一个0.1uF的陶瓷电容和1uF的钽电容离引脚越近越好。4.4 采样率提不上去DMA忙不过来如果你配置的采样率超过了ADC的实际能力DMA缓冲区里的数据就会变成新旧交错的乱码。ADC完成一次转换需要固定时间比如50MHz时钟下12位转换约21个周期。如果你让定时器每400ns就触发一次转换ADC根本干不完。这种问题在调试时特别隐蔽因为触发信号很干净ADC却没到“就绪”状态就去响应下一次触发。解决办法是以ADC的实际转换时间上限为准反推定时器触发频率上限。别贪把触发频率设置在ADC吞吐率的80%~90%之间留出裕量整个系统会稳定很多。5. 扩展玩法不只是波形采集还能直接对接算法链链路搭好之后你会发现手里的这条数据流特别值钱。因为CPU占用低、数据连续稳定后续不管是做滤波、FFT、PID控制还是故障特征提取都有了可靠的数据源。我用这套方案做过一个三相电机电流采集的小系统。定时器固定10kHz触发ADCDMA把三相电流和母线电压连续搬进缓冲主循环里跑Clarke变换和Park变换再把数据通过串口DMA发送到上位机。整个系统的CPU占用率连15%都不到剩余的资源全部用于跑电机控制算法。放在以前用中断逐点采集的时候这个性能想都不敢想。我实测过同一套代码如果把ADC时钟从50MHz降到25MHz功耗会明显降低但采样精度在大多数场景下感知不到差别。如果你的系统对功耗敏感可以尝试降低ADC时钟代价仅仅是分辨率在高频段略微下降。还可以考虑把三个ADC全部利用起来ADC1采电压、ADC2采电流、ADC3采温度三个ADC独立触发、独立DMA互不干扰。这样传感器数据全部并行采集同步性比单个ADC分时扫描好很多。要说缺点就是对DMA通道资源要求高了用之前先check一下DMA映射表看看哪个Stream还能空出来。我在实际使用中最满意的一点是这套方案的代码风格非常统一。初始化配置集中在一个函数里回调里只置标志位主循环只做帧处理。哪怕隔了三个月回头再看代码也能很快进入状态不用一行行去追实现细节。如果后面想继续深挖还可以试试注入组通道配合外部触发做“紧急优先级采样”或者把采样数据直接通过LTDC显示成实时波形。思路打开了这套机制的潜力会超出你最初的需求。
