用2个IO采集4档旋钮状态：嵌入式GPIO编码与Modbus浮点字节序处理

1. 这期笔记要解决的两个实际问题

先说说这周调试遇到的事儿。一个温控面板项目，面板上要放一个四档旋钮，用来切“加热/降温/循环/停止”四种模式。一开始电路设计同学给的是常规接法：旋钮内部四个引脚各接一个 IO，公共端接地，拧到哪一档哪一路就拉低。四个按键一样的接法，电路简单，逻辑也简单。但到了 MCU 选型的时候傻眼了——主控只剩 2 个空闲 IO，一个用作调试串口预留，一个用作外部中断唤醒。四个人凑不出四个引脚。

另一个问题出现在 Modbus 通信联调阶段。面板要上报实时温度，温度值是 float 类型。Modbus 的保持寄存器是按 16 位为单位组织的，一个寄存器塞不下 float，必须拆成两个寄存器。当时我用 Modbus Poll 做主机模拟调试，发现读回来的温度完全不对，25.6 度读出来是个天文数字，一度怀疑是传感器坏了，后来排查了整整一个下午才发现是 float 的字节序拆装搞反了。

这两个问题看起来八竿子打不着，但本质上是同一类问题：在受限条件下做数据转换。一个是硬件资源的受限，两个 IO 要采集四个状态；一个是协议格式的受限，一个 32 位数据要塞进两个 16 位寄存器。这篇文章把两个问题的思考过程和代码方案完整记录下来，方便有同样需求的朋友直接抄作业。

2. 4档旋转开关省IO采集方案：为什么要用2个IO

2.1 旋钮开关的常规接法与痛点

先把背景说透。普通的 4 档旋转开关，比如常见的 KC4 系列，内部结构等同于四组独立的单刀单掷开关，公共端是接在一起的。所以常规设计就是公共端接 GND，四个档位引脚分别接 MCU 的四个 GPIO，并开启内部上拉。旋钮拧到某一档时，该档位引脚被拉低，MCU 检测低电平就知道当前是哪一档。

这种方式的好处是固件逻辑零成本：四个 IO 直接读，低电平就是当前档位，不需要任何编码转换，误判率极低。缺点是 GPIO 占用太凶，一个四档开关就吃掉四个引脚，如果主控本来就紧张（像我这回就剩两个空闲 IO），就只能另想办法。

也有些人用 ADC 方案：公共端接 VCC，四个档位分别接不同阻值的分压电阻到同一个 ADC 引脚，通过采到的电压值判断档位。这个方案只占一个 ADC 引脚，理论上更省 IO。但实际用下来有几个坑：一是 ADC 采样受电源纹波影响，尤其在带加热丝、继电器的工控板子上，干扰大的时候电压波动可能导致误判；二是需要 MCU 带 ADC 外设，有的资源紧缺型芯片（比如某些低价位的 PIC、木兰系列）只有比较器没有 ADC，就没法用；三是挡位切换瞬间，分压网络会出现短暂的中间电压，采样时机没控制好就会跳到错误档位。

我这次主控芯片虽然有 ADC，但引脚也被占满了——ADC 通道全部用于采集 NTC 热敏电阻和湿度传感器，旋钮只能靠数字 IO 解决。所以最终采用的是 2 个 GPIO 编码采集方案。

2.2 编码原理：拨码开关思想，两引脚读四状态

两个 GPIO 能表示多少种组合？二进制算一下，两位一共 2² = 4 种状态：00、01、10、11。刚好对应四档。

核心思路是这样的：把四档旋钮当成一个 2 位编码旋钮，档位顺序按照二进制编码连续排列——1 档对应 00，2 档对应 01，3 档对应 10，4 档对应 11。然后把旋钮的内部引脚做特殊连接，使得拧到任意一档时，公共端与两个采集引脚之间恰好形成对应的电平关系。

硬件上怎么实现呢？最常见的做法是使用编码旋钮，内部不是四组独立的开关，而是两个刀位，每个刀位有两组触点（常开/常闭），通过凸轮结构保证拧动时两个刀位的通断状态按 00→01→10→11 的顺序切换。这类旋钮在国内市场有现成的型号，具体可以找供应商要规格书，确认“2 位二进制编码输出”即可。如果手头只有普通四组独立开关的旋钮，也有办法：拆开外壳，把四个刀位触点按照编码真值表重新接线——1 档只闭合引脚 A 和引脚 B 都不接公共端，2 档只闭合 A，3 档只闭合 B，4 档两个都闭合，实际上就是把四组开关重新做组合逻辑，把“只接通其中一路”变成“同时接通组合后的两路”。这活儿需要一点手工能力，但原理不复杂。

最终 MCU 端的电路就非常简单了：GPIO_A 和 GPIO_B 都配置为输入模式并开启内部上拉，旋钮公共端接 GND。拧到 1 档时 A、B 都悬空，读到都是高电平,对应二进制 11；2 档时 A 接地、B 悬空，读到 A=0、B=1，对应 01；3 档时 A 悬空、B 接地，读到 A=1、B=0，对应 10；4 档时 A、B 都接地，读到 00。注意这里的编码顺序取决于你硬件接线的定义，固件里做一张映射表就行，后面代码部分会详细说。

提示：如果 MCU 内部上拉阻值较大（常见 30~50kΩ），在强干扰场合建议外部并联 10kΩ 上拉电阻，否则长线连接时容易受感应噪声影响导致档位误判。

2.3 为什么不用1个IO？格雷码与极限压缩的讨论

肯定会有人问：两个 IO 还是嫌多，能不能用一个 IO？理论上可以——用一个 ADC 引脚加 4 个不同阻值的分压电阻，或者用一个引脚加 4 个不同频率的振荡电路。但纯数字 IO 只靠一个引脚没法区分四种状态，因为数字 IO 只有 0 和 1，单线只能表示两种状态。

也有人提过用 PWM 输入捕获的方式，一个 IO 接一个由旋钮切换不同电容的 RC 振荡器，MCU 测频率来判断档位。这方案确实只需 1 个 IO，但硬件成本高了（要加运放或比较器整形），软件也要多开一个定时器输入捕获通道，对于大多数应用来说属于过度设计。工程上讲究“够用就好”，2 个 IO 换 4 个状态，性价比已经很高。

在档位切换的平滑性上，如果对旋转过程有严格要求（不允许相邻档位切换时出现中间误码），可以考虑格雷码编码——相邻档位只有一位变化，比如顺序用 00→01→11→10。这样即使旋钮在切换瞬间出现了抖动，也只是在相邻编码之间跳变，不会从 00 直接跳到 11。格雷码在编码器领域是标配思路，放在旋钮采集上同样适用。代价是旋钮内部凸轮结构的触点排列得按格雷码顺序做，部分现成型号就是格雷码输出，选型时多问一句供应商就行。

3. 旋钮状态采样的完整代码实现

3.1 硬件初始化：两个GPIO的配置细节

以我用的 STM32F103 标准库为例，先看 GPIO 初始化。两个引脚配成输入上拉模式：

#define KNOB_A_GPIO_PORT GPIOA #define KNOB_A_GPIO_PIN GPIO_Pin_0 #define KNOB_B_GPIO_PORT GPIOA #define KNOB_B_GPIO_PIN GPIO_Pin_1 void Knob_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); GPIO_InitStructure.GPIO_Pin = KNOB_A_GPIO_PIN | KNOB_B_GPIO_PIN; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IPU; // 上拉输入 GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(KNOB_A_GPIO_PORT, &GPIO_InitStructure); }

注意 GPIO_Mode_IPU 是上拉输入，如果硬件上外部已经接了上拉电阻，也可以用浮空输入 GPIO_Mode_IN_FLOATING。但我的经验是：能用内部上拉就尽量用内部上拉，少一个外部电阻少一个故障点，内部上拉在大多数环境下足够可靠。

3.2 消抖处理：为什么不能直接读引脚

机械旋钮和按键一样存在触点抖动问题。拧动旋钮的瞬间，触点会因为机械弹跳产生一连串的快速通断，持续时间大约 5~20ms。如果在这个窗口内直接读 IO，可能读到中间状态——比如从 1 档往 2 档拧，读到一次 A=0、B=0（中间悬空）然后又跳回 B=1，这就是典型的抖动误码。

解决抖动最稳妥的办法是软件延时消抖：首次检测到电平变化后，等上 20ms 再重新读取一次，如果两次读到的值一致才认为档位有效。如果还是不一致，就继续等待，直到连续两次采样结果相同。

还有一种进阶做法是连续多次采样取多数表决，比如在 10ms 内连续采样 5 次，取 3 次以上的相同值作为最终结果。这种方法对高速旋转的场景更友好，但代码复杂度略高。我这回用的是最简单的“首次触发 + 20ms 延时 + 二次确认”，实测不管快拧慢拧都稳定。

uint8_t Knob_ReadRaw(void) { uint8_t val = 0; if (GPIO_ReadInputDataBit(KNOB_A_GPIO_PORT, KNOB_A_GPIO_PIN) == Bit_RESET) val |= 0x01; // A 接地，记为 1 if (GPIO_ReadInputDataBit(KNOB_B_GPIO_PORT, KNOB_B_GPIO_PIN) == Bit_RESET) val |= 0x02; // B 接地，记为 1 return val; // 取值范围 0~3 } uint8_t Knob_ReadDebounced(void) { uint8_t first_val = Knob_ReadRaw(); delay_ms(20); uint8_t second_val = Knob_ReadRaw(); if (first_val == second_val) return first_val; else return 0xFF; // 表示抖动中，无效 }

一个小提示：延时消抖期间不要用阻塞式 delay，否则在带 RTOS 的系统里会卡住其他任务。我在实际项目里是用一个 20ms 的定时器中断或者 RTOS 的软件定时器来做轮询，这里为了展示逻辑清晰用了 delay_ms，正式代码请改为非阻塞方式。

3.3 档位映射表：硬件接线与逻辑编码解耦

前面提到了，不同型号的旋钮、不同的接线方式，读到的原始值映射到档位的对应关系可能不一样。所以我强烈建议不要在业务代码里直接写 if (raw == 0) return MODE_STOP 这类硬编码，而是做一张映射表：

typedef enum { MODE_HEAT = 0, MODE_COOL = 1, MODE_CIRCULATE = 2, MODE_STOP = 3, MODE_INVALID = 0xFF } Knob_Mode_t; // 映射表：下标是 Knob_ReadDebounced 返回的原始值，内容是档位 const Knob_Mode_t knob_mode_map[4] = { MODE_STOP, // 原始值 0 -> 停止 MODE_HEAT, // 原始值 1 -> 加热 MODE_CIRCULATE, // 原始值 2 -> 循环 MODE_COOL // 原始值 3 -> 降温 }; Knob_Mode_t Knob_GetMode(void) { uint8_t raw = Knob_ReadDebounced(); if (raw == 0xFF) return MODE_INVALID; return knob_mode_map[raw]; }

映射表的写法有立竿见影的好处：如果后续换了旋钮型号，或者硬件改了接线，只需要改这张表，业务逻辑一行不用动。调试时也方便，直接在表里改数值就能验证不同档位下系统行为是否正确。这是我踩了好几次坑才养成的习惯——所有硬件相关的编码映射必须抽离成配置项，不能散落在业务代码里。

3.4 档位变化检测：只在变化时响应业务

在很多应用场景里，旋钮从“加热”切到“停止”需要触发一次停机动作。如果主循环每次都执行档位对应的动作，可能会出现重复触发的问题。比如加热模式每次循环都会开加热丝，切到停止后该关断，但因为读到的是停止档，逻辑上可能没问题；但如果“进入某档位时执行一次初始化操作”，就得检测变化边沿。

Knob_Mode_t g_last_mode = MODE_INVALID; void Knob_Task(void) { Knob_Mode_t current_mode = Knob_GetMode(); if (current_mode == MODE_INVALID) { return; // 抖动中，忽略本次采样 } if (current_mode != g_last_mode) { // 档位发生变化，执行一次模式切换动作 App_OnModeChanged(g_last_mode, current_mode); g_last_mode = current_mode; } // 如果不需要边沿触发，只是持续执行当前模式，可以在这里继续 App_OnModeLoop(current_mode); }

这里有个细节：旋钮在某一档停留期间，Knob_Task 每次调用 Knob_GetMode 都会返回相同的档位值。如果 App_OnModeChanged 里做了比较重的初始化操作（比如重新配置加热 PID 参数），那只有在档位真正变化时才会触发，不会频繁执行。

4. Modbus中float数据的拆分与还原

4.1 背景：Modbus寄存器单位是16位，float是32位

聊完旋钮，进入第二个问题：Modbus 通信中 float 的字节序处理。

先明确一个基础概念：Modbus 协议的基本数据单位是寄存器（Register），每个寄存器 16 位。一个 float 类型在 C 语言里是 32 位（4 字节），所以要把一个 float 放进 Modbus 的保持寄存器，必须拆成两个 16 位寄存器。具体来说，一个 32 位 float 由 4 个字节组成，比如 25.6 这个数在 IEEE 754 标准下内存里是 0x41CCCCCD，拆开就是 0x41CC 和 0xCCCD，分别放入两个保持寄存器。

这里有一个天然容易出错的地方：float 在内存中的字节排列顺序。x86 架构是小端模式，低字节在低地址；而很多单片机（比如 STM32 Cortex-M 内核）默认也是小端。但 Modbus 协议本身在网络上传输时，规定高位字节在前（大端模式）。这两种字节序一碰撞，数据就乱了。

举个栗子，25.6 这个数在 STM32 的内存里实际存储为（假设地址从低到高）：CD CC CC 41。如果把这段内存直接拆成两个 16 位寄存器，会得到 0xCDCC 和 0xCC41。在主机端（通常是 PC，也是小端）解析时，如果不做任何转换，拿到 0xCDCC 和 0xCC41 拼回 float，根本对不上号。

提示：凡是遇到“浮点数通过 Modbus 读出来是一个巨大或者极小的数”这类问题，90% 是字节序搞错了。剩下 10% 是寄存器地址偏移错了。排查顺序建议先查字节序，再查地址。

4.2 常用方案一：用共用体（Union）直接拆分

最直观的拆分方案是利用 C 语言的 union 特性。union 的所有成员共享同一块内存，写一个 float 进去，byte 数组读出来就是 float 的原始内存字节。配合 16 位寄存器变量，可以轻松拆分。

typedef union { float f; uint16_t u16[2]; uint8_t u8[4]; } Float32_Union;

然后写入 Modbus 保持寄存器时这样操作：

Float32_Union temp; temp.f = temperature; // temperature 是 float 类型的温度值 // 假设要把温度写到保持寄存器的第 0 和第 1 个寄存器 holding_regs[0] = temp.u16[0]; holding_regs[1] = temp.u16[1];

在 PC 端的上位机接收时，同样定义一个 union，把两个寄存器塞回去：

Float32_Union temp; temp.u16[0] = holding_regs[0]; temp.u16[1] = holding_regs[1]; float temperature = temp.f;

这个方式写起来最短，但有一个隐患：union 的内存布局是和编译器以及硬件平台相关的。在 STM32（小端）上 u16[0] 对应的是 float 的低 16 位，也就是低地址的那两个字节。如果哪天换了平台（比如大端的网络处理器或者一些 DSP 芯片），u16[0] 拿到的不一定是预期的那半个 float。代码移植性比较差。

所以 union 方案适合“单片机和上位机都是同一字节序、且未来不换平台”的封闭系统。一旦牵扯到跨平台，建议用下面的手写字节操作方案。

4.3 常用方案二：手工按字节拆装，彻底搞清楚字节序

手工拆分的好处是代码意图明确，每一个字节放哪里一目了然，而且可以灵活调整字节序。

先说定义。IEEE 754 单精度浮点数，32 位从高到低分别是：1 位符号位 S，8 位指数位 E，23 位尾数位 M。内存中 4 个字节的排列有两种常见顺序：

• 大端模式（Big-Endian）：内存高地址存低位字节，一个 float 的 4 个字节在地址中的顺序从低到高是 [byte3][byte2][byte1][byte0]，也就是符号位和指数高位在前。
• 小端模式（Little-Endian）：内存低地址存低位字节，顺序从低到高是 [byte0][byte1][byte2][byte3]。

Modbus 通常采用大端字节序（也叫网络字节序），高位字节在前发送。所以你从 STM32（小端机）采集到 float 后，要把内存中的字节顺序反过来放入两个 16 位寄存器，才能保证对端的主机按大端方式解析时能还原正确的浮点数。

具体实现：

// 将 float 拆成两个 Modbus 保持寄存器（大端寄存器序） void Float_To_Regs(float value, uint16_t *reg_high, uint16_t *reg_low) { uint8_t bytes[4]; memcpy(bytes, &value, 4); // 取 float 的原始内存字节 // 小端机取出: bytes[0] 是低地址字节，bytes[3] 是高地址字节 // 按大端寄存器序，reg_high 放高 16 位，reg_low 放低 16 位 *reg_high = (uint16_t)((bytes[3] << 8) | bytes[2]); *reg_low = (uint16_t)((bytes[1] << 8) | bytes[0]); }

还原时反过来：

// 从两个 Modbus 保持寄存器还原 float float Regs_To_Float(uint16_t reg_high, uint16_t reg_low) { uint8_t bytes[4]; // 从寄存器中把字节拆回内存，按照小端机的物理布局放回 bytes[3] = (reg_high >> 8) & 0xFF; bytes[2] = reg_high & 0xFF; bytes[1] = (reg_low >> 8) & 0xFF; bytes[0] = reg_low & 0xFF; float result; memcpy(&result, bytes, 4); return result; }

这套代码只依赖 memcpy，不依赖平台，无论大端小端都能正确工作。关键在于理解：不管内存里怎么排，最终发送到 Modbus 网络的寄存器中，两个寄存器的高低位顺序是确定的（大端）。只要你在寄存器层面保证了这个顺序，对端按同样规则解析就行。

不少读者会问：如果我的端也是小端机，直接用 union 拆出的 u16 顺序，是不是也行？答案是：如果两端都是小端机，且上位机也按小端解析，确实能对上。但 Modbus 协议本身是设备无关的协议，通信双方可能是 PLC（大端）、单片机（小端）、PC（小端），你不知道对端是什么架构。最稳妥的做法是不论本机字节序如何，发送出去的都按 Modbus 标准的大端寄存器序来，这也是为什么我推荐手工字节操作的原因。

4.4 两种方案对比与选型建议

直接给结论：

我个人的习惯是：只要是做 Modbus 通信，一律用手工字节操作方案。哪怕当前只有一个固定上位机，后续项目也大概率会复用这段代码，到时候对接 PLC 或者触摸屏，就不用回头再改字节序。

4.5 实操演示：Modbus Poll 验证浮点数收发

为了验证拆分还原是否正确，我习惯用 Modbus Poll 作为主机模拟工具。它支持以浮点数格式直接查看保持寄存器的值，这样不需要在 PC 上写代码就能快速验证从机发上来的 float 是否正常。

具体操作是：Modbus Poll 中连接设置选好串口参数（波特率、数据位等），功能码选 03 读保持寄存器，寄存器地址填从机存放温度的起始地址，数量填 2（因为一个 float 占两个寄存器）。然后在“Display”菜单里选择“Float”显示格式，如果从机发送的字节序正确，这里会直接显示 25.6 这样的正常值；如果显示乱码，可以先切到“Hex”模式，查看两个寄存器原始的数据值，再对照代码确认字节顺序。

实测时我有一次遇到这样的情况：从机代码里发的是高寄存器 0x41CC、低寄存器 0xCCCD，但 Modbus Poll 用 Float 模式显示出来却是 -4.206e-14 这种奇怪的值。排查发现上位机解析时把两个寄存器的顺序填反了——上位机认为先收到的是低 16 位。这在某些组态软件里是可以配置的，比如组态王、力控、MCGS 的 Modbus 驱动里往往有“字节顺序”或“字顺序”选项，需要和从机端保持一致。遇到这类情况，先在组态软件的变量属性里找“高低字交换”之类的设置项，一般能解决。

5. 浮点传输的进阶：32位数据与16位寄存器的映射策略

5.1 保持寄存器地址分配：一个float需要几个寄存器地址

根据 Modbus 协议，保持寄存器地址通常以 1 为单位递增。如果你要传一个 float，必须连续占用 2 个寄存器地址。比如你给温度分配的起始地址是 0x0000，那么高 16 位放 0x0000，低 16 位放 0x0001。对端读的时候必须按 2 个寄存器连续读取，不能只读一个。

这里有一个工程上常见的困惑：我看到有些老工程师习惯把 float 拆成两个整型来传，比如把 25.6 乘以 100 变成 2560 存入一个寄存器，对端收到再除以 100。这种定点数方法在某些场景下确实有用，尤其是只显示一位小数、值域固定的场合（比如温湿度、电压电流），可以省一半的寄存器，也避免了字节序问题。但缺点也明显：精度受限、范围受限，如果数据要参与复杂计算（比例控制、PID），定点数转换会引入误差。

我个人的判断标准是：如果数据只是给上位机显示，不参与运算，用定点数够了；如果数据要参与控制逻辑（比如环形 PID 调节），直接用 float 传输，别自找麻烦。

5.2 大端小端、AB CD 与 CD AB 的说法

在 Modbus 社区混久了，经常听到老工程师讨论 AB CD 还是 CD AB。这里的 A、B、C、D 分别表示一个 float 的 4 个字节从高到低排列：A 是最高字节，D 是最低字节。

• AB CD 顺序：寄存器 1 存 AB，寄存器 2 存 CD，也就是高字节在前，大端方式。这是 Modbus 的“默认”顺序，也是大多数 PLC（西门子、三菱）采用的顺序。
• CD AB 顺序：寄存器 1 存 CD，寄存器 2 存 AB，高字节在后。部分国产仪表、某些组态软件默认使用这个顺序。

如果你遇到对端读上来的浮点数错乱，先查对端用的 AB CD 还是 CD AB。这里有一个让我记忆犹新的坑：一块第三方的温湿度变送器，手册上写着 Modbus 协议，寄存器地址表里一个参数占 2 个寄存器。我用 AB CD 方式解析，湿度始终不对，后来把 CD AB 也试了一次，一下就通了。从那以后我养成了一个习惯：对接任何第三方 Modbus 设备，第一件事是查手册里关于字节序的说明，或者直接两种顺序都试一遍。

5.3 注意事项：对齐一致性、寄存器数量与固定偏移方式

在多个 float 连续传输时（比如同时传温度、湿度、压力三个量，共 6 个寄存器），还需要注意两点。

第一，寄存器偏移必须是偶数。如果一个 float 从地址 1 开始放，那么它占 1 和 2；下一个 float 从 3 开始，占 3 和 4。这是常规做法。但有些人写代码时图省事，直接按数组顺序连续拆放，万一起始地址是奇数（比如从 1 开始），就会出现一个 float 跨越“字边界”，放在 1/2，下一个放在 3/4，看似没问题，但如果你在中间插入一个 16 位整型变量（比如从地址 2 开始），就会把前一个 float 的高 16 位和低 16 位拆开，对端读取时很容易读错位。所以我建议所有 float 数据的起始地址统一从偶数开始，保持“2 字节对齐”，这能避免很多低级错误。

第二，多用“固定偏移量”的方式填充数据，不要动态排列。比如协议里定义：地址 0-1 温度，地址 2-3 湿度，地址 4-5 压力，地址 6-7 预留。即使当前没有压力传感器，地址 4-5 也是填 0，而不是把湿度的低 16 位挪到地址 4。这样后续增加新设备或第三方对接时，寄存器地址表不会乱套。

6. 常见问题与排查技巧实录

6.1 旋钮档位采集不稳定：抖动误判的排查

遇到档位采集不稳定，优先怀疑三个方向：

第一个是旋钮本身的触点质量。便宜的旋钮触点镀层薄，氧化速度快，用几个月后接触电阻变大，内部上拉可能拉不动，导致该拉低的引脚读不出来。排查方法：用万用表直接量触点间电阻，正常应该小于 1Ω，如果几十欧甚至上百欧，就是触点氧化了，只能换旋钮。

第二个是消抖时间不够。旋钮的抖动时间比按键长，尤其是手感偏软的旋钮，可能达到 30ms。如果消抖延时设 10ms 甚至 5ms，就可能读到中间状态。我的经验是旋钮消抖保守一点，20~30ms 比较稳，也不影响用户体验。

第三个是布线问题。如果旋钮到 MCU 的线比较长（超过 20cm），且没有走地线隔离，容易受周围继电器、加热丝等感性负载的干扰。解决方法是引脚加 10kΩ 外部上拉，或者串联 1kΩ 限流电阻并并在引脚对地加 100nF 电容滤波。

6.2 Modbus float 读取出错：五种典型表现

把我在调试中遇到的 float 错乱情况整理成一张速查表：

最后一种情况比较隐蔽。如果你的代码里是先写高 16 位寄存器，再写低 16 位寄存器，而主机恰好在两次写之间发起读请求，主机就可能读到“新高+旧低”的混合数据。解决办法是：从机端在更新 float 时，先把数据拆到临时变量，然后一次性把两个寄存器都填好再允许主机读取；或者先写低 16 位后写高 16 位，这样即使打断，主机读到的也是旧值，不会读出错乱的新组合。这种“先低后高”的顺序在很多通信协议中都是一种经典防撕扯技巧。

6.3 组态软件/触摸屏常见的“swap”设置

如果你接的不是自己写的上位机，而是组态王、WinCC、MCGS 这些组态软件或触摸屏，它们通常会在变量的寄存器配置里提供一个叫“字节交换”或“字交换”的选项，英文常见于 “Byte Swap”、“Word Swap”、“DWord Swap”。这本质上就是 AB CD / CD AB / BADC 这些排列顺序的可选开关。

我的建议是：先把自己从机端的顺序固定为标准大端 AB CD，然后在组态软件里做适配。如果组态软件显示不对，依次尝试改变交换设置，很快就找到正确组合。不需要在从机端反复改代码。

6.4 调试工具选择与抓包技巧

最后讲讲调试工具。Modbus Poll 和 Modbus Slave 是我最常用的两个工具。Poll 是模拟主机，可以同时轮询多个从站；Slave 是模拟从站，方便你测试上位机逻辑。配合虚拟串口工具（比如 Virtual Serial Port Driver），可以在没有真实硬件的情况下先做纯软件联调。

还需要一个工具就是串口监视器。我用 AccessPort 或者 Free Serial Port Monitor 抓取串口上实际发出的字节，看报文帧里寄存器值的顺序是否符合预期。比如从机发送一条读保持寄存器的响应帧，帧里的数据段如果是 CD CC CC 41 开头的，说明当前发出来的就是小端内存顺序，跟 AB CD 大端预期不符合，再从代码里找哪里需要反转。抓包看原始十六进制是最快的排查方式，比凭空猜字节序靠谱得多。

7. 一点个人体会

两个问题写下来，回头看看其实都是“工程化思维”的练习。旋钮省 IO 这件事，很多人第一反应是加芯片扩展（比如 74HC165 并行转串行），第二反应是 ADC 分压，却忽略了对需求本身的重新审视——四档状态本质是两位信息，两个 IO 刚好装下。Modbus float 拆装则是对通信协议的规则吃透——先搞清楚字节序标准，再写代码，就不会被“读出来是乱码”这类问题反复消耗时间。

调试过程中我最深的体会有两条。第一条，硬件相关问题，先用万用表量、用示波器看，别急着改代码；软件相关问题，先抓原始数据，别急着猜逻辑。第二条，能写成映射表、配置表的东西，不要硬编码在业务逻辑里，这次是旋钮档位，下次可能是字节序，留好配置入口，后续维护的人会感谢你。

如果这篇文章能帮你少走一次弯路，那就值了。