嵌入式实战：旋转开关省IO采集与Modbus Float字节序解析

这一篇笔记是接在调试记录后面的，上一篇把板子上的电源、主控和通信底子捋顺了，这篇记录两个看着不搭边但实际都在调“资源”的问题：一个是4档旋转开关怎么省IO去采集，另一个是Modbus通信里float怎么拆开再还原。两个问题在同一个项目里碰到，正好都属于“嵌入式现场最常见也最容易反复踩坑”的类型，干脆放一起写，方便自己以后翻，也能给正在调类似东西的朋友一个参考。

先说下背景：手头这块板子是给别人做的小型设备控制器，MCU用的是STM32G0系列，IO资源本来就不宽裕。设备面板上有4个4档旋转开关，需要把档位状态采回来，分别对应几种工作模式。最初设计布板时规划的是每个开关直接接4个IO，公共端拉低、档位端上拉输入，4个开关就是16个IO，算完发现整片MCU直接被掏空，别说还剩下的按键、指示灯、RS485，连下载器都要挤不出来。后来改成4档旋转开关通过编码方式共用一组IO，只留了3根线就全部搞定；同时正好又接到上位机要用Modbus RTU读浮点参数的需求，于是又顺带把Modbus里float的拆分、组装、字节序这些问题彻底研究了一遍，两个问题串成了这篇笔记。

1. 拆解需求：旋转开关省IO的核心思路与Modbus float问题的由来

1.1 省IO到底在省什么，省到什么程度才够用

这里说的“省IO”，不是单纯地少接几根线那么简单，背后是整机的引脚预算分配。普通4档旋转开关（也就是1刀4掷，公共端加4个固定触点）最直接的接法是公共端接GND，其余4个触点上拉到VCC再接IO，MCU读到哪个引脚为低，就说明旋钮转到哪个档位。这个办法的好处是逻辑简单、程序好写、实时性高，不用任何转换电路，但缺点是每一个开关每一档都要占一个IO引脚。4个开关那就是16个脚，换成QFN32封装的MCU直接翻车，换成LQFP48虽然勉强够用，但把所有引脚全用在档位读取上，后续扩展就别想了。

在实际项目中，省IO的目标通常是把“引脚成本”降下来，转换到“电路成本 + 软件复杂度”上。比如4档开关，理想状态是通过编码方案把每个开关的占脚数从4根压到2根，甚至多个开关共用一组IO。因为每个开关只有4个有效状态，理论上用2位二进制就能表示完，这和组合逻辑压缩信息的基本原理是一致的。编程里叫编码、压缩，硬件上就是用编码器或者电阻网络，把多路状态转换到更少的信号线上。

1.2 Modbus里float为什么要拆开，跟主控资源有什么关系

Modbus协议本身设计得比较早，它最基本的读写单元是寄存器，一个寄存器固定是16位，也就是2个字节。但工程里的温度、压力、电压、电流这些模拟量，常用的是32位单精度float，一个数就占了4个字节。4字节放进16位寄存器里放不下，就只能拆成两个寄存器来传。这是Modbus协议侧的硬性限制，不是哪家厂商故意搞复杂。

这个拆分动作从底层原理看就是一次字节序和字序的排列组合问题：32位浮点数按IEEE754标准拆成4个字节，4个字节又按Modbus寄存器两两组合成2个寄存器。先拆字节还是先组寄存器、高字节在前还是低字节在前、高寄存器在前还是低寄存器在前，不同设备厂家给出的排列方式五花八门。调试时如果只看抓包软件里的原始寄存器值，不看设备手册里定义的字节序，很容易出现“读回来一个2.7e-42”这种完全看不懂的数值，实际上就是序反了。

2. 4档旋转开关省IO采集：三种可行方案对比

2.1 直接IO读取的“地板方案”和它的适用边界

先把最传统的做法摆出来，不是为了推荐它，而是为了说明在什么样的情况下这种“奢侈”是合理的。直接IO方案适合IO富余、逻辑极简的场合，比如一个面板上只有一两个旋钮、MCU引脚富余，或者现场工程师对实时响应要求极高、不希望软件里做任何编码转换。这种方案下每个档位对应一个独立中断源，触发是硬件级别的，响应时间可以到微秒级，完全不需要扫描和判定逻辑。

但这套方案在工程里最大的风险是“资源不可再生”，板子一旦把IO全接了旋钮，后面想加个模拟量采集、想串个小屏幕，就只能改板。所以设计阶段做IO预算时，我一般会优先把方案定为“能用两根线绝不用四根”，把一个引脚当两个用甚至当八个用，把省出来的引脚留给更关键的信号。这也是我本篇笔记里优先介绍后面两种省IO方案的原因。

2.2 编码型旋钮开关：硬件自带2位格雷码，直接省一半IO

最理想的省IO方案是从源头把开关选型换掉。市面上有专门的编码型旋转开关，内部把4个档位通过机械结构映射成2路格雷码输出，公共端加2根信号线就够了，外壳上照样有个旋钮能拧，手感、定位和普通多档开关一致。这种开关引脚定义一般是1根公共端、2根编码输出，不同的档位对应不同的二进制组合：00、01、11、10，相邻档位只有一位变化，这也是格雷码的好处，拧动过程中不会出现乱码抖动。

使用格雷码输出的注意点：

• 读出2位电平后，需要查表或者做一次格雷码到二进制的转换，不能直接把2位值当中档位索引。
• 公共端接GND、编码输出接上拉到VCC是常规接法，MCU配置成输入上拉模式即可，内部弱上拉如果不够稳，要外部加4.7k到10k的上拉电阻。
• 档位切换时如果读到非法组合，要做等待稳定处理，不能立即响应。

我在选型时优先推荐这种开关，因为它本质上是把“省IO”做进了硬件里，软件开销小、实时性好。坏处是物料型号不如普通多档开关通用，如果采购渠道受限或交期紧张，就要退回到下面的电阻分压方案。

2.3 ADC电阻分压方案：一根引脚采集4个档位

如果手里没有编码型旋钮，只有最普通的单刀多掷开关，又想省IO，那ADC分压是比较经典的通用办法。原理很简单：每个开关的4个固定触点分别接不同阻值的电阻，公共端接到同一个ADC通道，不同档位把不同的电阻接入分压电路，于是ADC脚上的电压随档位变化。MCU读取一次模拟量，再按电压区间判断当前档位，一个开关占用1个模拟输入引脚，完整实现4档读取。

具体电路可以这样搭：公共端接ADC_IN，4个档位触点上分别接R0、R1、R2、R3到VCC，公共端经下拉电阻Rg到GND。当旋钮拧到第n档时，对应的Rn和Rg构成分压，ADC读到的电压就是 VCC * Rg / (Rn + Rg)。选电阻时让4个档位对应的电压尽量均匀分布在0.3VCC到0.8VCC之间，留出足够间隔，避免电阻误差和ADC噪声导致档位误判。我给一个实际用过的电阻配置供参考：VCC=3.3V，Rg=10k，R0=1k、R1=2k、R2=4.7k、R3=10k，算下来4档电压大约是3.0V、2.75V、2.24V、1.65V，相邻档位电压差都在0.5V以上，用12位ADC采样后判定区间做挡位判断非常靠谱。

这个方案的特点是一个开关只占一条ADC引脚，还能多个开关再接不同ADC通道。如果通道有限，还能配合模拟开关做分时复用，代价是软件复杂一些。

2.4 4个开关共用总线的分组选通玩法

如果主控连复用的多个ADC通道都紧张，可以再进一步，让多个开关共用同一条数据线。思路和键盘矩阵类似：把4个开关的编码输出全部接到同一组数据线上，再用2根地址线作为选通信号，分时选中某个开关，让它把当前的档位状态输出到总线。因为同一时刻只有一个开关被使能，总线上的数据就是当前被选中开关的状态。这样4个开关就只占3个IO（2根地址线 + 1根数据线），如果旋转开关用的是2位编码输出，数据线就是2根，总占5个IO，依然远少于16个IO。

这个方案的实现细节在软件里要注意地址稳定后再采集数据，特别是地址线经过不同的走线长度会有延时差，如果不等稳定就直接读数据线，可能出现串扰读错档位。一般做法是先切换地址线、等几个微秒、再把数据线上拉或者下拉稳定后读取，这个等待时间放在延时里实现即可。

3. 省IO旋转开关的软件采集与防误判处理

3.1 ADC分压方案的档位区间判定算法

分压方案虽然硬件简单，软件判定却有个容易踩坑的地方：不要用“电压等于某个值”去判断档位，而要用区间判断。因为ADC采样受电源波动、电阻精度、温度漂移影响，同一个档位在不同板子上采出来的值不可能完全一致。我的做法是先把ADC原始值读回来，再根据事先标定好的区间表查档位。

假设ADC是12位、满量程4095，VCC=3.3V，那么表里的几个分界点可以这样设计：

• 档位0典型原始值约3720，区间取3500~3900。
• 档位1典型原始值约3410，区间取3200~3500。
• 档位2典型原始值约2780，区间取2500~3000。
• 档位3典型原始值约2048，区间取1850~2300。

注意区间之间留出5%左右的滞回余量，防止档位卡在两个区间的临界点上反复抖动。代码里用if-else从低到高逐段判断即可，不需要查表也能保持足够清晰，IO占用和代码执行时间都可以忽略不计。

3.2 开关状态读取的去抖与乱码防护

机械旋转开关在转动过程中，触点会经历短暂的断开、接触、弹跳过程，这段时期内读到的电平是不稳定的。处理办法和按键去抖类似，但比按键更要小心，因为旋钮转一个档位可能包含多次跳变。

我的现场经验是“连续采样确认”比“延时跳过”更可靠。所谓连续采样确认，就是在一个短窗口内多次读取状态，只有连续几次结果一致才认为档位切换完成。比如检测到档位值变化后，连续读10次、每次间隔1ms，全为同一个值才更新有效档位。如果中途有跳变，就重新计时。这种做法的好处是不会因为一次毛刺误动作，也能滤掉旋钮转动过程中必然经过的中间档位。

实际上4档旋转开关在转动时，如果编码型会经过相邻档位的非法编码组合，普通多掷开关会经过断开状态，这些中间状态都要靠连续采样过滤掉。我在程序里是单独封装了一个switch_state_update()函数，专门管“原始电平 -> 去抖确认 -> 档位索引”这一条链路，主循环每次只调这个函数，不让业务逻辑直接读GPIO或ADC，后期排查问题会轻松很多。

3.3 非法档位与硬件断开的软件兜底

省IO方案还有一个必须处理的场景：开关在两个档位之间停住，或者触点氧化接触不良，导致读取到的电压落在任何已知档位区间之外。程序面对这种情况不能按最后一个有效档位继续执行，否则设备可能在不该运行的模式下运行。

我给分压方案加的兜底逻辑是：ADC读到的值如果哪个区间都不落，就记一次无效计数，连续3次无效就判定为“档位无效”，设备进入安全状态，停止输出并向上位机报状态。这样即便现场有人把旋钮拧到一半，也不会出现控制器在未定义模式下乱动作的问题，这一点在工业现场很关键。

4. Modbus float拆分与还原：先搞懂IEEE754和寄存器顺序

4.1 IEEE754单精度float的二进制结构

float在计算机里是按IEEE754标准存储的，32位分为3部分：1位符号位、8位指数位、23位尾数位。比如1.0这个数，在内存里是3F 80 00 00这样4个字节（大端显示时）。Modbus要传这个值，就得把这4个字节按一定顺序塞进2个16位寄存器里。

这里很多新人容易绕晕的是“移位”和“字节序”是两个层面的问题：一是float内部位域怎么排，二是4个字节在传输时谁先谁后。位域排布是标准定的，大家都一样；字节序却是设备厂商定的，五花八门。调试Modbus浮点数据时，90%的问题出在字节序/寄存器序上，而不是float本身的位运算算错了。

4.2 大端小端和寄存器字序的四种组合

假设一个float变量内存里的4个字节用A、B、C、D表示，A是最低地址字节。Modbus里存放时，常见方式有如下几种：

实际调试时，如果数据手册里没写明寄存器顺序，最快的办法是先用Modbus Poll读回两个寄存器的原始值，比如读到1.0时寄存器原始值是3F80和0000，那就是方式1；如果是0000和3F80，那就是方式2。这个发现过程我在下面的实操步骤里会详细讲。

4.3 float在Modbus寄存器里的标准映射关系

再具体一点，以方式1（大端，寄存器内高字节在前）为例：float数值1.0对应的4字节是3F 80 00 00，拆成两段就是0x3F80和0x0000，所以寄存器1存0x3F80，寄存器2存0x0000。上位机或者主站读回这2个寄存器后，需要先按同样的顺序拼回4字节，再按IEEE754解释成浮点数。

拼接代码的逻辑可以这样理解：先准备一个联合体或者字节数组，把寄存器1的高字节放到字节0、低字节放到字节1，寄存器2的高字节放到字节2、低字节放到字节3，然后用memcpy把4字节的位模式当成float解释。这一步是纯粹的位模式搬运，不涉及数学运算，只要字节序对，出来的值就是准的。

5. Modbus float拆分还原的代码实现

5.1 从两个寄存器还原float（大端读取函数）

下面给一个我常用的C语言实现，适用于“大端寄存器顺序 + 寄存器内高字节在前”的方式，也就是最常见的Motorola格式。代码用uint16_t的联合体来避免数组下标越界和一些编译器告警，也更容易阅读：

#include <string.h> #include <stdint.h> typedef union { float f; uint8_t bytes[4]; } float_bytes_t; float modbus_get_float_bigendian(const uint16_t *regs) { float_bytes_t fb; fb.bytes[0] = (uint8_t)(regs[0] >> 8); fb.bytes[1] = (uint8_t)(regs[0] & 0xFF); fb.bytes[2] = (uint8_t)(regs[1] >> 8); fb.bytes[3] = (uint8_t)(regs[1] & 0xFF); return fb.f; }

调用方式：主站从从站读回的2个寄存器值放在regs[0]和regs[1]里，调用后直接返回还原好的float。这个实现依赖联合体做位模式转换，C标准里看是implementation-defined，但几乎所有真实MCU编译器（GCC、Keil、IAR）都支持，工程上用没问题。如果想让代码更严格，可以用memcpy代替联合体：

float modbus_get_float_bigendian(const uint16_t *regs) { uint8_t bytes[4]; float result; bytes[0] = (uint8_t)(regs[0] >> 8); bytes[1] = (uint8_t)(regs[0] & 0xFF); bytes[2] = (uint8_t)(regs[1] >> 8); bytes[3] = (uint8_t)(regs[1] & 0xFF); memcpy(&result, bytes, sizeof(result)); return result; }

两种都可以，第二种是严格符合标准写法，在嵌入式和上位机之间移植更稳。我自己发布的代码通常用第二种，因为万一以后要拿到别的编译平台上编译，最少不会在联合体这个点上出幺蛾子。

5.2 小端寄存器顺序的还原函数

如果设备手册写的或者实测下来是“小端模式”，也就是寄存器1里放的是低16位，那按上面函数的字节顺序要反过来：

float modbus_get_float_littleendian(const uint16_t *regs) { uint8_t bytes[4]; float result; bytes[2] = (uint8_t)(regs[0] >> 8); bytes[3] = (uint8_t)(regs[0] & 0xFF); bytes[0] = (uint8_t)(regs[1] >> 8); bytes[1] = (uint8_t)(regs[1] & 0xFF); memcpy(&result, bytes, sizeof(result)); return result; }

写这种函数时，我会特意把中间步骤展开而不是用一堆宏去封装，目的就是让现场同事在维护代码时能一眼看懂哪一字节来自哪个寄存器，不用对着宏定义推理半天。从工程可维护性的角度，这种“啰嗦但直白”的写法反而比我一开始用的那种花哨技巧要靠谱。

5.3 把float拆成两个寄存器用于Modbus写操作

从站要上报float参数时，方向相反：float -> 4字节 -> 2个寄存器。下面给出大端格式的拆分函数：

void modbus_set_float_bigendian(float value, uint16_t *regs) { uint8_t bytes[4]; memcpy(bytes, &value, sizeof(bytes)); regs[0] = ((uint16_t)bytes[0] << 8) | bytes[1]; regs[1] = ((uint16_t)bytes[2] << 8) | bytes[3]; }

这个函数在主站、从站端都能用：从站内部要把float写到保持寄存器，调用它；主站收到上位机的设定值，要往下写，也调用它。只要保证通信两端用的是同一种字节序格式，数值就是对的。

5.4 主机端字节序差异与跨平台注意事项

嵌入式MCU大多是ARM Cortex-M，主机序是小端，但Modbus协议本身不规定寄存器内字节序，只规定“寄存器按地址递增”。所以写代码时，最重要的就是“内存里的字节序”和“协议里的字节序”分开对待，不能因为本地是小端就直接用memcpy把float的两个字拷贝到寄存器数组，那样出来的寄存器内容往往和协议要求不一致。

我早期踩过的一个坑：在STM32上写Modbus从机，主机是西门子PLC。我用本机小端直接做了个union把float当成2个uint16_t拿去回，结果西门子那边读到的数值全是乱的。后来查手册、用Modbus Poll实测，才发现设备只要按照协议要求输出大端排列，PLC那边读回来就能正常显示。从那以后，但凡和Modbus float相关，我都是走上面写的显式字节搬运函数，绝不做“取巧”。

6. 调试实录与避坑清单

6.1 现场实录：Modbus poll里读出2.7e-42是怎么定位的

有一次设备联调，上位机通过Modbus Poll读取从站的电压值，正常范围内应该是0~100.0，但读出来的是2.7e-42这种奇奇怪怪的极小值，有时候又是几百亿的巨额数值。我第一反应是寄存器地址填错了，把寄存器的偏移地址加1试了还是那样。后来让现场同时把两个原始寄存器的HEX值发过来：读到的寄存器原始值一个是0000、一个是4040左右。对照一下浮点数1.0的编码，我意识到数字本身是对的，但被我这边的还原函数按大端解释了，而设备实际输出的是小端。

把Modbus Poll里的寄存器顺序确认后，用上面第5.2节的小端还原函数一替换，数值立刻恢复正常。这种问题的特征是“量级对不上、符号乱、数值离谱”，基本可以断定是字节序而不是通信故障，不用怀疑硬件。

6.2 Modbus poll和Modbus slave联调的小技巧

调试Modbus float时，我一般会开两个软件：Modbus Poll当主站，Modbus Slave当从站，两边同时监视，快速验证字节序定义。有一个小技巧：在Modbus Slave里手动写入一个已知浮点数的原始字节，比如1.0对应的大端寄存器值3F80和0000，然后用Modbus Poll去读。如果读出来是1.0，说明主从两侧的约定一致；如果读出来不是1.0，就调整Poll侧的解析格式或从站里的字节放置顺序，直到一致为止。这个“用已知值测未知序”的方法，比对着手册猜要快得多。

6.3 其他容易翻车的点整理

整理一份我实际踩过或者帮别人排查过的Modbus float问题清单：

• 寄存器地址偏移：有些设备手册里地址写成40001这种PLC地址，实际Modbus PDU里是0000，差1就会错位。
• 寄存器数配置错误：读float时功能码读寄存器数量要设为2，设成1会只读到半个float。
• 字序相反的两个寄存器值正好是反的：有的设备是先低后高，有的先高后低，不能只靠还原函数硬扛，要在项目配置里写明。
• 浮点精度显示问题：上位机把float转字符串显示时，别直接设置太多小数位，比如读到3.14，有些显示控件设置精度不对会变成3.1400001，这是正常现象，不是采集错。
• 从站更新寄存器时序：从站在主站读取瞬间正在更新float的两个寄存器，会导致主站读到半个新值半个旧值，变成乱数。解决办法是在中断里先禁掉更新，或者从站使用双缓冲。

6.4 旋转开关和Modbus float放在一起调试时的整体心得

这次的旋转开关省IO方案和Modbus float拆分，在代码层面最终汇总到一个逻辑里：设备要把旋钮档位转成一个参数，比如把开关位置映射成模式编号，然后通过Modbus float寄存器上报给上位机。我是这么衔接的：开关去抖确认后得到一个0~3的档位索引，再把档位索引转成浮点数，经modbus_set_float_bigendian写进保持寄存器，上位机读出来就能直接显示“当前模式3”。整个过程看似跨越了硬件采集和协议解析两块，实质上都是在处理“状态如何用最少的资源表达出来”，一个是硬件引脚上的状态表达，一个是协议帧里的数据表达。

个人体会比较深的一点：嵌入式调试很多麻烦不是单个环节有多难，而是每个环节里“顺序”一错、全盘皆输。旋钮的档位顺序、电阻分压的电压区间、Modbus的寄存器顺序，本质上都是序的问题。只要把“序”这个核心抓在手里，不管是省IO还是float拆分，都是可以用同一套思路解决的：先把状态空间梳理清楚，再确认映射关系，最后动手写代码。这套思维习惯保持下来，后面再遇到什么I2C地址高7位低1位、SPI时钟相位设置、CAN数据跨字节拼接，都能很快定位到问题。