STM32F030 ADC采集：轮询、中断与DMA实现及多通道配置详解

这几年用STM32F030做小设备ADC采集这块来来回回试过轮询、中断、DMA三种写法。刚开始图省事全是轮询反正采集频率不高。直到有一次做8路电压采集把定时器、显示、按键都挤在一个循环里轮询那点延时直接让界面卡成PPT才认真把F030的ADC机制从头到尾捋了一遍。F030是一颗Cortex-M0内核的入门级MCU48MHz主频价格便宜、供货充足很多电源、家电、电池管理、传感器采集项目都在用。它的多通道ADC是很多开发者入门时第一个接触的模块但恰恰是这块ADC让不少人吃了亏。网上一搜F030 ADC问题最多的就是“扫描模式读不出每一路数据”“DMA怎么配都不动”“换了F103的代码直接翻车”。这些问题归根结底是对F030这一代ADC的硬件行为不够了解。这篇文章不打算给那种“照着抄就行”的配置流水账而是把三种实现方式各自的原理、代码、适用场景和容易踩的坑摊开来说。无论你是刚拿到这块芯片想跑通第一个ADC例程还是做了几年嵌入式想把采集模块做得更稳这篇应该都能给你一些参考。1. 为什么F030的ADC值得单独写一篇很多有F1或G4经验的人拿到F030第一反应是拿老代码改改就能用。实际上一旦在F030上跑多通道扫描问题马上就来。因为F0这一代ADC的行为和F1有明显差异。1.1 F030在ST ADC生态里的特殊位置F030的ADC是12位SAR型规则组最多能排16个转换序列位内部有温度传感器和Vrefint参考电压通道外部通道根据封装不同常见的有11到15路。跟F1相比它少了注入通道一组但这不影响常规采集。最大的差异在事件行为上。F1的ADC在扫描模式下EOCEnd of Conversion只在整条序列全部转换完成后置位这是老玩家的思维定式。但F0系列的ADC_CFGR2寄存器里有一个EOCS位可以选择EOC的产生时机默认值0表示整条序列完成才置位写成1就变成每个通道转换完成都会触发一次EOC。这个位直接决定轮询和中断方式能不能拿到完整的多通道数据。还有个硬指标F0的ADC时钟上限是14MHz。48MHz主频下ADC预分频器最低也只能除以4得到12MHz。有些人照抄F1的习惯把分频设成2ADC时钟直接到了24MHz系统看起来在跑但转换结果的精度会明显下降因为内部比较器根本没法在这么短的时间内稳定建立。1.2 直接决定实现方式的三个硬件细节第一ADC的DMA请求是逐通道触发的。扫描模式下每完成一个通道转换ADC就会向DMA发送一次请求DMA把DR寄存器里的16位数据搬到内存。所以扫描DMA是天作之合缓存的顺序天然对应扫描序列里Rank的顺序不需要额外处理。第二F030的DMA请求映射非常固定ADC1的DMA请求只能映射到DMA1的Channel 1。不要拿F103的映射表往上套F103里ADC1可能是DMA1的Channel 1但你做惯F1以后容易把这个当成常识然后在F030上配置成Channel 2之类的数据死活不动还以为是DMA没配好。第三F0系列DMA是简化版没有F4那种硬件双缓冲模式。很多人搜“dma双缓冲”想直接在F030上套用会失望。但是在循环模式下配合半传输中断完全可以用软件思路模拟出双缓冲效果后面DMA章节我会展开。这三个细节基本决定了本文的走向轮询适合简单单通道中断适合中低频逐通道DMA才是多通道连续采集的最终归宿。2. 轮询实现思路最直白但这两处最容易翻车轮询的本质是软件触发一次转换然后CPU死等EOC标志置位置位后读取数据寄存器DR。对单通道来说这个流程没有任何问题代码也最简洁。2.1 单通道轮询代码与转换时间估算先看最基础的单通道软件触发实现/* 轮询读取单个ADC通道 */ uint16_t read_adc_ch(uint32_t channel) { /* 选择通道清除旧的就绪状态 */ ADC1-CHSELR (1UL channel); /* 启动一次软件触发转换 */ HAL_ADC_Start(hadc); /* 等待EOC超时100毫秒保护 */ if (HAL_OK HAL_ADC_PollForConversion(hadc, 100)) { return (uint16_t)HAL_ADC_GetValue(hadc); } return 0xFFFF; }这段代码在调试阶段非常好用。CubeMX配置好ADC以后先用这个函数验证通道和参考电压是否正确再谈其他。转换时间是可以手算的。假设你在CubeMX里把ADC预分频设为448MHz主频得到12MHz ADC时钟。每个通道的转换时间等于采样周期 12个固定周期。比如采样周期配成13.5个ADCCLK那么单个通道的转换时间就是T_conv (13.5 12) / 12MHz 2.125us如果采样周期配成239.5那就变成T_conv (239.5 12) / 12MHz 20.958us这个估算有个很实际的作用多通道总转换时间就是所有通道之和。8通道用13.5周期采样每轮扫描大约17us。如果系统里有一个10kHz的中断任务轮询方式每轮要花17us干等占掉约17%的CPU这还没算上其他开销。所以轮询方式在通道数上来以后CPU浪费相当可观。2.2 扫描模式下EOC的行为陷阱这是F030轮询多通道时最大的坑也是网上讨论最多的点。默认情况下EOCS位是0扫描模式下EOC只会在整条序列全部转换完成后置位。问题是DR寄存器只有一个每个通道转换完都会把结果覆盖写进去。等你看到EOC置位再去读DR里面只剩最后一个通道的值了。很多新手会写出这样的代码/* 错误示范扫描3个通道试图每轮依次读取 */ uint16_t buf[3]; HAL_ADC_Start(hadc); for (int i 0; i 3; i) { if (HAL_OK HAL_ADC_PollForConversion(hadc, 100)) { buf[i] HAL_ADC_GetValue(hadc); } }表面上循环了三次实际上第一次PollForConversion就已经在等整条序列结束后面几次读到的全是最后一个通道的值。最终结果就是buf[0]、buf[1]、buf[2]三个数长一个样。想在轮询下拿到逐通道数据必须把F030的特性利用起来设置EOCS位让EOC在每个通道转换完后产生/* 使能逐通道EOC每次转换结束都会置位EOC */ ADC1-CFGR2 | ADC_CFGR2_EOCS; HAL_ADC_Start(hadc); for (uint32_t i 0; i 3; i) { /* 等待一个通道转换完成 */ while (LL_ADC_IsActiveFlag_EOC(ADC1) 0) { } buf[i] LL_ADC_GetData(ADC1); }注意改成逐通道EOC以后使用顺序必须和扫描序列顺序一致。如果扫描序列是Rank1通道5、Rank2通道0、Rank3通道7那么buf[0]就是通道5的数buf[1]是通道0的数buf[2]是通道7的数不是按通道号排序的。2.3 轮询真正适合的场景轮询不是一无是处它的优点就是简单直观出问题好排查。我现在的习惯是任何新板子拿回来第一步都是先用轮询方式把每个通道读一遍确认硬件通路正常然后再往中断或DMA迁移。适合用轮询的项目通常有这几个特征单通道或者通道数很少采集频率在几百赫兹以内单片机主循环没有太多其他实时任务。比如做一个按键扫描加一路电位器采集的小工具轮询完全够用没必要为了“显得高级”而上DMA。3. 中断实现不再空转等待但别让M0频繁进出中断中断方式的想法很简单ADC转换完成产生EOC事件触发中断CPU在中断回调里读取DR。这样一来CPU在等待转换期间可以去干别的事效率比轮询高。3.1 EOC中断与回调函数的使用在CubeMX里把ADC的全局中断打开再在代码里做两件事启动ADC转换然后在HAL_ADC_ConvCpltCallback里处理数据。单通道中断采集的启动代码/* 启动ADC转换使能中断 */ HAL_ADC_Start_IT(hadc);回调函数里读取结果volatile uint16_t adc_value 0; void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc-Instance ADC1) { adc_value HAL_ADC_GetValue(hadc); } }主循环就完全不用管ADC了只需要消费这个volatile变量。相比轮询CPU利用率明显提升因为等待转换的这段时间被释放出来了。3.2 扫描模式下想要逐通道数据需要动CFGR2默认EOCS0时扫描模式下整条序列完成才进一次中断而DR里只剩最后一个通道的数据。所以如果你在CubeMX里配了3通道扫描然后指望中断回调里连续读3次HAL_ADC_GetValue结果是和轮询犯错一样的——读到的全是最后一路。解决办法还是改EOCS位。在初始化完了以后直接对寄存器操作hadc.Instance-CFGR2 | ADC_CFGR2_EOCS;这样每个通道转换完成都会触发一次EOC中断中断频率和通道数成正比。回调里维护一个通道索引volatile uint16_t adc_buf[3]; volatile uint8_t adc_index 0; void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc-Instance ADC1) { adc_buf[adc_index] HAL_ADC_GetValue(hadc); adc_index (adc_index 1) % 3; } }这时候要特别注意HAL_ADC_GetValue内部会读DR并清理一些状态标志不要在中断回调里做滤波、均值、浮点运算这些耗时操作先把数据存下来回到主循环再慢慢算。3.3 中断和DMA的分界线在哪里有人会问CAN总线接收到底是中断好还是DMA好串口接收是中断好还是DMA好这个问题在ADC这里也成立逻辑是一致的。关键看事件频率。在连续转换和16MHz级的ADC时钟下如果开启逐通道EOC中断每个通道转换只要2us左右就触发一次中断。3通道连续扫描中断频率能到470kHz左右。Cortex-M0内核进出一次中断需要压栈、出栈、跳转就算不跑复杂的用户代码有效开销也在1到2us量级。这样算下来CPU几乎全被中断占满实际能做的其他任务非常有限。当然如果采样率不高比如用定时器每隔1ms触发一次ADC转换那次中断频率只有1kHz中断方式完全没问题响应还快。所以选中断还是DMA核心判断标准是“单位时间内事件次数”和“CPU有没有其他实时任务”。F030这类入门级MCU主频才48MHz没有硬件浮点资源本来就紧张。多通道、高频率、还要跑通信协议栈的场景中断方式很容易成为压垮系统的最后一根稻草。这也是为什么很多老工程师在F0上做多通道采集几乎不问直接上DMA。4. DMA实现CubeMX里几个勾选就能让数据自己跑DMA方式下ADC每个通道转换完成都会产生一个DMA请求DMA硬件自动把DR里的结果搬运到内存缓冲区搬运过程完全不需要CPU参与。配合连续转换和DMA循环模式ADC会源源不断地把最新数据填进缓冲区CPU只需要在需要的时候去缓冲区读。4.1 CubeMX里必须勾上的选项在CubeIDE或CubeMX里配置F030的ADC时有几个选项对DMA方式至关重要。ADC配置页ScanConvMode选Enable开启扫描模式Continuous Conversion Mode选Enable让ADC在触发一次后持续不断地转换不需要反复软件触发NumberOfConversion设为通道数比如3每个Rank里配置对应通道和采样周期DMA Continuous Requests选EnableDMA配置页添加ADC1的DMA请求Mode选CircularData Width选Half Word这里解释一下“DMA Continuous Requests”。翻译成“连续请求”有点抽象实际意思是ADC在连续转换模式下每个通道转换完成都会产生DMA请求而且这个请求是持续的。如果这个选项没勾上即使ADC在连续转换DMA也可能只响应第一批转换请求之后缓冲区就不更新了。我见过好几个例程ADC明明在跑DMA缓冲区却一动不动最后查下来就是这个选项没勾。还有一点DMA的通道映射不需要你手选CubeMX会根据F030的请求映射表自动选择DMA1的Channel 1。但如果你是自己从零写寄存器而不借助CubeMX记住ADC1对应DMA1_Channel1不要想当然套F103的经验。4.2 缓冲区数据顺序与长度配置生成代码后核心就是调用HAL_ADC_Start_DMA#define ADC_CH_NUM 3 volatile uint16_t adc_buf[ADC_CH_NUM]; void adc_dma_init(void) { HAL_ADC_Start_DMA(hadc, (uint32_t *)adc_buf, ADC_CH_NUM); }这里最关键的是缓冲区排列顺序。前文提过adc_buf[0]对应扫描序列Rank1的通道adc_buf[1]对应Rank2的通道以此类推。也就是说顺序由你在CubeMX里配置的Rank顺序决定跟通道号大小无关。举个例子如果Rank1是通道5Rank2是通道0那么adc_buf[0]是通道5的电压adc_buf[1]是通道0的电压。主循环取值的时候别搞混了。第三个参数“ADC_CH_NUM”表示一次传输的长度必须大于等于扫描序列长度。如果这里填错了比如扫描3个通道但只填2DMA搬运第二个通道数据后就会认为传输完成触发Cplt回调而第三个通道的数据永远不会被搬运。数据长度填多了也有问题可能把第二轮或多余的数据继续搬进来导致缓冲区和扫描序列对不齐。4.3 半传输中断模拟双缓冲F030的DMA没有硬件双缓冲但在循环模式下DMA支持半传输中断。它的原理是DMA每搬完缓冲区一半的数据触发一次HalfCplt回调搬完整个缓冲区再触发一次Cplt回调。利用这个机制可以把缓冲区分成前后两个半区一个半区在填数据的时候CPU去处理另一个半区的数据形成流水线。这和双缓冲思路很接近。#define ADC_BUF_SIZE 12 volatile uint16_t adc_buf[ADC_BUF_SIZE]; volatile uint8_t sem_half 0; volatile uint8_t sem_full 0; void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc-Instance ADC1) { sem_half 1; } } void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc) { if (hadc-Instance ADC1) { sem_full 1; } }主循环里看到sem_half置位就处理adc_buf[0]到adc_buf[ADC_BUF_SIZE/2 - 1]这一半看到sem_full置位就处理后半段。这样做的好处是ADC和DMA始终在后台连续填数CPU只处理已经填好的半区数据不需要担心缓冲区被改写。需要注意的是半传输中断对缓冲区长度有一定要求。DMA的半传输事件是按当前传输计数来判定的缓冲区太短比如只有2个通道时半传输事件依然会触发但处理间隔太短可能来不及消费。实际使用中建议把缓冲区设置成长度偶数且容量足够大比如64或128。4.4 Overrun和DMA中断的协作DMA循环模式有一个很容易被忽视的隐患Overrun即溢出。当ADC已经完成一次转换但上一次转换结果还没来得及被DMA搬走DR寄存器里的旧数据就会被新数据覆盖ADC置位OVR标志。在DMA连续搬运的情况下只要DMA的响应速度足够快通常不会Overrun。但如果系统进入了低功耗模式、DMA被更高优先级操作抢占、或者缓冲区长度配置异常导致DMA提前停止Overrun就会发生。一旦OVR置位后续转换数据是否可靠就很难说要停止、清标志、重新启动。处理Overrun的代码逻辑void handle_adc_error(void) { if (HAL_ADC_GetError(hadc) HAL_ADC_ERROR_OVR) { /* 先停止DMA搬运 */ HAL_ADC_Stop_DMA(hadc); /* 清除溢出标志 */ __HAL_ADC_CLEAR_FLAG(hadc, ADC_FLAG_OVR); /* 重新启动 */ HAL_ADC_Start_DMA(hadc, (uint32_t *)adc_buf, ADC_CH_NUM); } }顺带说一个和串口DMA相通的经验。网上经常有人问“stm32串口hal库使用dma发送数据不能连续发送”这类问题一半出在DMA模式配置成了Normal而不是Circular或者没有等待前一次传输完成就再次启动。ADC的DMA也同理如果你想连续采集就必须用循环模式如果用了Normal模式每次传输完成后DMA计数归零你需要先停止再重新配置否则第二次HAL_ADC_Start_DMA可能直接失败。这也是为什么我在做连续采集时只考虑Circular模式。5. 三种方式的横向对比与选型建议到这里三种方式的实践细节都过了一遍下面用一个表把关键指标拉齐方便做决策。5.1 五个维度的指标对照对比项轮询中断DMACPU占用高等待期间忙等中取决于中断频率极低搬运由硬件完成多通道支持能力弱需改EOCS或手动切通道中EOCS1时可逐通道获取强自动按扫描顺序搬运代码复杂度低适合快速验证中回调加索引管理中重点在CubeMX配置实时响应差CPU被阻塞好转换完成立即响应好DMA完成中断响应及时典型场景单通道低频、调试中低频、事件触发采集多通道连续采集、音频、振动还有一个维度容易被忽略就是调试排错难度。轮询出了问题非常直观断点一停看返回值就能定位。DMA一旦数据不动你要排查的点会多一些DMA映射对不对、循环模式开没开、Continuous Requests勾没勾、缓冲区长度和Rank数量是否一致。所以我前面强调新板子先用轮询跑通再切换到DMA不要一上来就是DMA出问题会加倍消耗时间。5.2 具体项目场景怎么选如果是做一个单通道温湿度采集器读取频率每秒几次轮询足够简单可靠。如果是做一个2到4通道的中低速采集设备比如健康监测类的小盒子采样率几百赫兹以内用中断方式代码不算复杂还能留一半CPU给显示和按键。如果通道数到了6路以上或者采样率要到几千赫兹或者你还在同一个CPU上跑蓝牙协议栈、Modbus通信、电机控制这类任务直接上DMA循环模式。这样CPU负载从百分之三四十降到个位数多出来的算力可以做更重要的事。关于“CAN总线一般中断接收还是DMA接收”这类问题思路是一样的。判断依据不是哪个技术听起来高级而是数据到达频率和CPU实际能承担的上下文切换开销。对F030这类入门级M0来说多通道ADC长时间连续工作几乎是DMA的主场。5.3 实测中的个人建议我自己在F030上做多通道采集时默认方案就是扫描DMA循环。不过有几个细节我会特别注意。第一主循环读adc_buf之前确认这次读到的数据是完整的一轮扫描结果。尤其在循环DMA下缓冲区可能正在被写入如果直接读前3个元素有可能读到新旧交错的组合。稳妥做法是让一轮扫描数据之间保持原子性比如等一个Cplt回调再处理整段缓冲区或者用半传输中断切分半区。第二多通道采集时建议把采样周期适当调大比如默认的13.5或者更大不要一上来就1.5周期。通道交替切换时信号源内阻和外部滤波电容会影响建立时间采样周期太短会导致串扰和读数不稳。这一点在F030的文档里没有特别强调实际项目里我吃过亏。第三如果对实时性要求高可以在HAL_ADC_ConvCpltCallback回调里只置一个标志不做任何运算。这个回调本身是被DMA中断触发的如果在这里面跑滤波还是会拖慢中断响应。把算法全部放到主循环里处理避免在高优先级中断里做低优先级的事。最后一点经验在一次量产的电池保护板项目里我最初用中断方式采集6路电压采样率2kHzM0的负载已经明显偏高主循环里的LED显示和按键偶尔会卡顿。后来换成DMA循环加半传输中断处理主循环负载降了一大截卡顿消失而且因为CPU被解放出来整个系统的任务调度也稳定不少。很多嵌入式问题不是芯片性能不够而是我们把CPU花在了不该由它花的地方。ADC的硬件搬运能力就摆在那边轮询和中断作为理解和过渡很重要但真正要跑多通道连续采集放心大胆去用DMA。