嵌入式IO不够用？用ADC分压实现多档开关检测与Modbus浮点传输详解

做嵌入式的小伙伴肯定都有过这种经历板子快画完了发现IO口不够用。我这阵子调试一个带4档旋转开关的小设备就撞上了这个问题。传统接法一个档位一根IO四个档位要占掉4个输入口剩下的引脚还得留给通信、指示灯和按键根本不够分。最后我把4档旋转开关改成了电阻分压加一路ADC采集硬生生省下3个IO口。同一台设备还要通过Modbus RTU把采集数据上报给上位机结果float在16位寄存器里拆来拆去又出了乱码前后折腾了大半天才把字节序理顺。这篇笔记就把这两件事的完整方案、计算过程和踩坑记录写清楚给正在折腾IO规划或者Modbus浮点通讯的朋友做个参考。1. IO不够用4档旋转开关的一路ADC采集方案1.1 场景分析与方案选型先说说我遇到的实际场景。设备面板上有一个4档旋转开关用来切换工作模式手动、半自动、全自动、校准四个状态必须能被MCU实时识别。最开始画原理图的时候我习惯性给每个档位分配一个IO开关拨到哪一档对应的引脚就被拉低或者拉高。电路设计很简单逻辑判断也直观调试时一根线一根线测过去就行。问题出在IO预算上。主控用的是STM32F103系列总共就那么几十个引脚除了旋转开关还要接485收发、状态指示灯、按键、调试串口以及几个传感器输入。等我把所有外设分配完发现手头只剩下一两个空余IO根本不够4个档位的输入。这时候就得换思路。常见替代方案有三个一是用拨码开关加编码器把4个状态编码成2位二进制只需要2个IO但拨码开关手感差、体积大而且4档旋转开关已经定了改硬件不现实。二是用专门的IO扩展芯片比如PCF8574通过I2C读状态占2个IOSDA/SCL但加片子要改板子、加代码杀鸡用牛刀。三就是这次用的方案把档位开关接成电阻分压网络用一路ADC读取不同电压值来反推档位。第三种方案的优势非常明显只占用1个ADC引脚不需要改结构、不需要加芯片成本几乎为零只要在开关引脚上多焊几个电阻就行。它的代价是软件上要做ADC采样、滤波和阈值判断比单纯读IO稍微绕一点但这个复杂度完全可控。我现在做这类产品凡是遇到“多选一”的开关类输入只要不是高速切换场景优先考虑ADC分压IO省下来还能干别的。1.2 电阻分压电路与参数计算电路结构其实就三样东西一个固定上拉电阻、一个ADC采样点、四个档位各自的电阻。公共端接ADC引脚通过一个上拉电阻接到VCC旋转开关的四个档位分别接四颗不同阻值的电阻到GND。开关拨到不同的档位就相当于把对应阻值的电阻接入分压回路ADC引脚读到的电压自然不同。选阻值的时候有两个目标档位之间压差要足够大、便于稳定判断同时电流不能太大、免得白白耗电。我用的参考电压是3.3V上拉电阻选了10kΩ四个档位分别接10kΩ、20kΩ、33kΩ、100kΩ。这些都是E24标准系列采购方便价格便宜。分压计算公式是Vout VCC × R档 / (R上拉 R档)逐档算下来档位接地电阻分压输出12位ADC读数110kΩ1.65V2048220kΩ2.20V2731333kΩ2.53V31424100kΩ3.00V3724相邻档位之间的电压差分别是0.55V、0.33V、0.47V换算成ADC读数相差683、411、582。STM32F103的ADC是12位分辨率这个区分度非常充足即使电阻精度差一点、电源有纹波也不会误判。如果板子空间的功耗敏感可以把上拉电阻加大到47kΩ档位电阻同步放大分压关系不变但电流能降下来代价是ADC引脚输入阻抗对采样稳定性的要求更高采样时间要相应加长。这里有个容易忽略的坑旋转开关从一档拨到另一档的过程中触点会经过短暂的开路或抖动状态ADC会读到一个不稳定的跳变值。软件里必须处理这个瞬态不能读一次就下结论。另外如果MCU的ADC参考电压引脚VREF和供电不是同一个电源分压计算要以VREF的实际电压为基准而不是想当然用3.3V。2. 软件实现采样滤波、档位判断与防抖2.1 ADC初始化与多次采样预处理硬件电路只能保证分压关系正确真正的可靠性要靠软件。我首先把ADC配置成单通道、软件触发、12位精度采样时间拉长到55.5个周期。为什么采样时间很重要因为分压网络等效于一个电阻源驱动ADC内部采样电容采样时间太短会导致电容充电不完全低阻档位还好高阻档位尤其是100kΩ那一路读数会偏低。读取的时候不能直接拿一次转换结果当档位依据至少要连续采样16次。我用的方法是16次采样里去掉一个最大值、去掉一个最小值剩下的14次求和取平均。这样能把毛刺和偶发异常值过滤掉得到的值比较平滑。代码大致长这样#define ADC_SAMPLE_TIMES 16 static uint16_t adc_read_single(void) { ADC_SoftwareStartConvCmd(ADC1, ENABLE); while (!ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC)) { } return ADC_GetConversionValue(ADC1); } static uint16_t adc_read_filtered(void) { uint32_t sum 0; uint16_t max_val 0; uint16_t min_val 4095; for (uint8_t i 0; i ADC_SAMPLE_TIMES; i) { uint16_t v adc_read_single(); sum v; if (v max_val) max_val v; if (v min_val) min_val v; } return (uint16_t)((sum - max_val - min_val) / (ADC_SAMPLE_TIMES - 2)); }这个函数每次返回一个经过预处理的ADC读数后续档位判断就基于这个值。采样周期可以根据实际速度调整我这里是每秒判断一次功耗和响应速度都能接受。2.2 档位判定阈值、滞回与连续确认ADC读数算出来了怎么映射回档位最简单的方法是设三个阈值小于2390认为是1档小于2936认为是2档小于3433认为是3档其余是4档。阈值取的是相邻两档ADC读数中点比如1档和2档的中点是(20482731)/22389.5取整2390。但只用单阈值判断有个问题如果读数正好在阈值附近波动档位会来回跳。比如档位2的实际分压恰好因为电阻偏差偏低了一点读数在2385到2395之间跳系统就会在1档和2档之间反复横跳。解决方法是加滞回区间也就是“上去”和“下来”用不同的阈值。更简单的土办法是连续确认连续5次采样都在同一个档位才认为档位真正切换了。我实际用的是连续确认加基础阈值的组合#define GEAR_TH_1_2 2390 #define GEAR_TH_2_3 2936 #define GEAR_TH_3_4 3433 #define GEAR_CONFIRM_CNT 5 typedef enum { GEAR_UNKNOWN 0, GEAR_1, GEAR_2, GEAR_3, GEAR_4 } gear_t; static gear_t gear_now GEAR_UNKNOWN; static gear_t gear_from_adc(uint16_t adc) { if (adc GEAR_TH_1_2) return GEAR_1; if (adc GEAR_TH_2_3) return GEAR_2; if (adc GEAR_TH_3_4) return GEAR_3; return GEAR_4; } gear_t gear_update(void) { uint16_t adc adc_read_filtered(); gear_t candidate gear_from_adc(adc); static uint8_t confirm_cnt 0; static gear_t last_candidate GEAR_UNKNOWN; if (candidate last_candidate) { if (confirm_cnt GEAR_CONFIRM_CNT) { confirm_cnt 0; if (gear_now ! candidate) { gear_now candidate; /* 档位已变化在这里做状态上报 */ } } } else { last_candidate candidate; confirm_cnt 0; } return gear_now; }这套逻辑跑下来机械抖动的毛刺会被过滤得一干二净。实测中即使我用手快速来回拨开关输出档位也只会按顺序变化不会出现跳变或者卡死。核心思想是模拟量采集永远不要直接映射状态一定要经过滤波和时间上的确认这是搞ADC输入的基本功。2.3 档位状态上报与Modbus联动档位判出来了怎么用如果只是板子上点个灯那直接查一下变量就行。但我的需求是要通过Modbus把档位状态上报给上位机所以我在保持寄存器里专门划了一个地址存放当前档位值就是1到4。这只占一个寄存器非常省空间。这里有一个细节不要每个判断周期都把档位写入寄存器最好只在档位变化的时候写。一方面减少对寄存器区的无意义写入另一方面也方便上位机做事件检测。我在gear_update函数里已经预留了“if (gear_now ! candidate)”这个分支实际工程里就是在这个位置更新Modbus寄存器同时置一个标志位通知主循环需要发送数据或者更新显示。如果后续想把档位信息和浮点参数联动上报比如不同档位对应不同的量程系数这个系数本身是个float那就引出了第二部分的问题float怎么在Modbus里传。3. Modbus里的float为什么总乱码从IEEE 754到字节序3.1 为什么一个float要占两个寄存器Modbus协议的基础单位是寄存器一个寄存器16位。而C语言里的float是32位的按IEEE 754标准存储正好等于两个寄存器。所以要在Modbus里传一个浮点数必须把它拆成两个16位分别放进两个连续的保持寄存器接收方再把两个寄存器拼回去。IEEE 754单精度浮点数的32位结构是1位符号位、8位指数位、23位尾数位。一个数比如100.5在内存里对应的32位十六进制是0x42C90000。实际换算是这样100.5的二进制是1100100.1科学计数法是1.1001001×2^6指数为6加上偏移量127得到133即0x85尾数是10010010000000000000000拼起来就是0 10000101 10010010000000000000000也就是0x42C90000。这个编码规则搞清楚了后面字节序问题就很好理解了。很多新手第一次遇到Modbus浮点乱码第一反应是怀疑485接线、波特率、CRC校验之类的问题折腾一圈发现通讯完全正常问题出在数据解释上。这就是因为float本身是32位而Modbus寄存器是16位中间的拆分和组合规则没对上。3.2 字节序才是最大的坑拆分组合的规则就是字节序最常见的排列模式有ABCD、CDAB、BADC、DCBA四种。假设一个float变量在内存中的4个字节从高位到低位依次是b3、b2、b1、b0b3是最高字节那么模式寄存器0的内容寄存器1的内容备注ABCDb3 b2b1 b0高字在前高字节在前CDABb1 b0b3 b2低字在前高字节在前BADCb2 b3b0 b1高字在前低字节在前DCBAb0 b1b2 b3低字在前低字节在前Modbus协议标准本身是偏向大端的寄存器内部的字节序通常默认高字节在前所以ABCD模式被认为是“标准”模式。但是现实中很多PLC、仪表、传感器厂商有自己的内部约定特别是欧洲一些设备喜欢用CDAB模式也就是把低16位放在第一个寄存器高16位放在第二个寄存器。加上一些上位机组态软件自己还有额外的字节序设置多一层排列组合乱码概率直线上升。用100.5这个数举例它的IEEE 754编码是0x42C90000最高字节b30x42b20xC9b10x00b00x00。如果是ABCD模式两个寄存器读出来是0x42C9和0x0000。如果是CDAB模式读出来就是0x0000和0x42C9。所以只要看Modbus Poll读出来的寄存器原始值立刻就能判断当前设备是哪种排列。3.3 用Modbus Poll快速确认字节序判断字节序的办法很简单根本不需要猜。我在从机寄存器区里专门留了两个测试寄存器初始化的时候把一个已知浮点数比如100.5拆好放进去。联调的时候打开Modbus Poll读取这两个寄存器的原始值方法如下在从机代码里把保持寄存器地址0x1000和0x1001写死为100.5拆分后的两个16位值先按ABCD模式填。打开Modbus Poll连接从机功能码03起始地址0x1000数量2。观察寄存器值如果显示0x42C9和0x0000说明主站按ABCD解释完美。如果显示0x0000和0x42C9说明数据其实是CDAB排列主站和从机有一边需要调整。如果看到0xC942或0x0042这种奇怪的组合说明寄存器地址错位、读写长度不对或者从机代码里float拆分时字节本身已经打乱了。我后来在工程里一直保留这个测试寄存器不只是调试时用产品出厂自检时也能跑一遍确认通讯链路的数据解释一致。网上那些“16进制转float在线工具”很多也支持四种字节序切换配合Modbus Poll的原始值几步就能定位问题。Modbus Poll没注册也能读数据只是功能受限调试基本够用。4. 浮点收发代码联合体、memcpy与位运算的取舍4.1 联合体的直观写法与隐患C语言里把float拆成两个uint16_t很多老工程师第一反应是用联合体typedef union { float f; uint16_t u16[2]; uint8_t u8[4]; } float_map_t;用起来确实简单赋值给f然后读u16[1]和u16[0]就行。但是这种写法有一个平台相关的问题联合体成员的字节布局取决于主机的字节序。在x86和ARM小端模式下u8[0]存的是float的最低字节在大端模式下u8[0]存的是最高字节。如果只在STM32上跑小端模式是固定的代码没问题。可一旦代码被移植到其他平台或者编译器做了特殊的结构体对齐优化联合体成员的对齐和填充可能和预期不一致浮点数据就会悄悄出错。更重要的是严格别名规则。C标准里通过联合体的另一个成员来读取当前活动成员的值在不同编译器下的行为并不完全一致。GCC和Keil实际支持这种用法也跑得好好的但这属于“知道坑在哪才能用”的写法。产品代码里我倾向用更保守、可移植性更强的方式。4.2 推荐memcpy加位运算的可移植写法我推荐的方案是先用memcpy把float按字节拷贝到一个uint32_t变量里然后对这个uint32_t做位运算按需要的字节序拆成两个16位寄存器值。memcpy不关心主机的字节序它做的就是纯字节搬运真正的字节序控制完全由后面的移位和掩码操作决定逻辑清晰换平台也不会翻车。#include string.h /* 以AB-CD模式为例寄存器0存高16位寄存器1存低16位 */ void float_to_modbus(float value, uint16_t regs[2]) { uint32_t bits 0; memcpy(bits, value, sizeof(bits)); regs[0] (uint16_t)(bits 16); regs[1] (uint16_t)(bits 0xFFFFu); } float modbus_to_float(const uint16_t regs[2]) { uint32_t bits ((uint32_t)regs[0] 16) | regs[1]; float value 0.0f; memcpy(value, bits, sizeof(value)); return value; }这段代码在STM32上跑起来把100.5传进去regs[0]得到0x42C9regs[1]得到0x0000和前面表格对得上。如果设备的字节序是CDAB只要把两个寄存器的赋值顺序调换一下也就是regs[0]存低16位、regs[1]存高16位其余逻辑完全一样。如果一台设备需要适配不同上位机或者不同协议版本可以把字节序抽成枚举参数typedef enum { FLOAT_ORDER_ABCD 0, FLOAT_ORDER_CDAB, FLOAT_ORDER_BADC, FLOAT_ORDER_DCBA } float_order_t; void float_to_modbus_ex(float value, uint16_t regs[2], float_order_t order) { uint32_t bits 0; memcpy(bits, value, 4); switch (order) { case FLOAT_ORDER_ABCD: regs[0] (uint16_t)(bits 16); regs[1] (uint16_t)(bits 0xFFFFu); break; case FLOAT_ORDER_CDAB: regs[0] (uint16_t)(bits 0xFFFFu); regs[1] (uint16_t)(bits 16); break; default: /* BADC和DCBA需要再做字节交换不常用这里不展开 */ break; } }实际项目里BADC和DCBA出现概率很低遇到也是先怀疑设备手册看错了。我通常在代码注释里写清楚当前使用的模式免得过几个月自己回来看代码一脸懵。4.3 在FreeModbus工程中的挂载方式常见的基于FreeModbus v1.6移植的STM32工程里寄存器读写是通过一个uint16_t数组模拟的比如usRegHoldingBuf应用层所有数据都映射到这个数组。这时候float和寄存器的交互就是简单调用关系上报时先调用float_to_modbus把float拆进两个数组元素接收时调用modbus_to_float从两个数组元素还原出float。需要注意地址对齐写入float时起始寄存器地址如果是奇数按寄存器编号算要小心后续区域的数据错位。比如float占了寄存器0和1下一个变量就应该从寄存器2开始放不能从1开始。虽然不会崩但数据会互相覆盖而且是那种特别难查的隐蔽bug。我还习惯在代码里把寄存器地址定义成宏浮点参数的起始地址、长度、字节序模式都集中在一个头文件里。这样上位机联调时一旦发现字节序不匹配改一处宏定义就能全局切换不用到处改代码。这个习惯在维护老设备兼容性时特别有用。5. 实测踩坑记录与排查速查表5.1 档位误判与ADC读数跳变第一次联调时旋转开关拨到3档上位机显示成了2档而且偶尔还会跳回3档。排查下来发现不是阈值算错了而是我ADC采样时间设得太短。用示波器看ADC引脚的波形发现100kΩ那一路的电压建立过程很慢每次切换档位后大约有几十毫秒的充放电过程采样早了就读到旧电压的余值。解决方法有两个一是把ADC采样时间拉长到最大档位二是切换档位后延迟一点再进行下一次判断。我两个都做了问题彻底消失。还有一次是档位4附近读数漂移查了半天发现是板子上一颗电阻虚焊。所以这里也提醒一句分压电阻的焊点质量直接影响结果出厂前最好做一次全档位校准测试每个档位的ADC读数落在哪个区间、和理论值差多少记录下来作为出厂参数。5.2 Cortex-M0上强转导致HardFault有次在Cortex-M0内核的芯片上跑代码程序没跑多久就进了HardFault。查反汇编发现是float指针强转成uint16_t指针后直接解引用导致的。Cortex-M0对未对齐访问支持很差float变量在内存里的地址如果不是2字节对齐强转指针后读一个16位值就可能触发硬件异常。解决办法很简单不要做这种强转统一用memcpy。这也是我为什么在浮点收发部分强调用memcpy加位运算而不是指针强转或者联合体。踩过一次坑之后我写嵌入式代码基本不碰指针强转处理多字节数据。5.3 Modbus浮点乱码排查流程如果上位机读出来的浮点数明显不对我建议按下面这个顺序排查不要直接改代码瞎试第一步用Modbus Poll读原始寄存器值。不要看浮点解释结果把两个寄存器的值切到十六进制显示记下来。第二步和目标浮点数的IEEE 754编码对照。比如期望是100.5编码就是0x42C90000。第三步比较两个寄存器和0x42C90000四个字节的对应关系看到0x42C9在第一个、0x0000在第二个是ABCD反过来则是CDAB。第四步确认主站那边的“数据类型”设置和“字节序/字序”设置是否与从机实际发送一致。很多组态软件里这两项是分开配置的单独改对某一项还不能解决。第五步如果原始寄存器值本身就和预期对不上说明问题在从机代码里去查float拆分函数。5.4 常见问题速查表现象可能原因排查方向档位读数跳变、误判旋转开关抖动、ADC采样时间短加滤波、连续确认、延长采样时间档位读数整体偏移分压电阻精度低、VREF不准确换1%精度电阻核对参考电压Modbus浮点乱码字节序不匹配用测试寄存器配合Modbus Poll对比IEEE 754编码Cortex-M0运行异常指针强转导致未对齐访问改用memcpy拷贝数据浮点数据错位但值能对上寄存器起始地址没有对齐检查参数放置地址统一按寄存器编号规划最后分享一个我自己坚持了很久的习惯凡是Modbus从机工程我一定在寄存器表里预留两个专用的测试寄存器初始值就放100.5这个数。联调时先读这两个寄存器字节序对不对、地址对不对、读写长度对不对一眼就能看出来。旋转开关那边阻值能选E24标准系列就不要用非标阻值采购好买Debug也好查。这两条经验帮我少加了不少班也希望能帮正在看这篇笔记的你省点时间。