嵌入式实战：4档开关省IO采集与Modbus浮点传输解析

1. 项目概述

1.1 核心需求解析

我在设备端改造时遇到一个很有意思的硬件资源冲突问题：主控芯片的GPIO已经用得七七八八，却要新增一个4档旋转开关用来切换设备的工作模式。如果按常规做法，一个挡位占用一个IO，4档就要吃掉4个引脚，这在引脚紧张的板子上根本行不通。于是就有了这套“省IO采集”方案。

另一个问题出在指令交互上。设备通过Modbus RTU与上位机通信，需要上报浮点型数据，比如温度、电压、频率这类带小数点的物理量。而Modbus的保持寄存器是以16bit为最小单位的，一个float（32bit）放不下，必须拆成两个寄存器存储，上位机再按协议规则还原。这里面的字节顺序如果没处理好，轻则数据错乱，重则两家各说各话，联调半天都对不上。

这篇文章把这两个问题的完整解决过程整理出来：一是4档旋转开关只用1路ADC引脚就完成状态识别的硬件选型和代码实现；二是Modbus中float类型数据的拆分、发送、接收与还原，附C语言和标准Modbus协议规则的对照说明。内容偏实战，适合正在做嵌入式产品联调、或者想了解一下省IO采集思路的朋友参考。

先说清楚一个概念：这两件事看似不相关，但其实是同一个项目里的两个独立子问题，一个是“输入采集”，一个是“数值传输”，一个是本地逻辑，一个是上下位机交互。把它们放在一起写，是因为它们各自的坑都很典型，恰好可以作为一套嵌入式调试笔记来留存。

2. 4档旋转开关省IO采集的硬件思路

2.1 为什么不用4路IO直接采集

最简单粗暴的方案当然是每个挡位接一个IO，MCU读电平判断当前状态。这个方案的优点是逻辑特别简单，代码几行就能写完，而且不存在误判的可能——哪个引脚是高电平，就是哪个挡位。

但缺点也很明显：

• 占用的引脚数量多，4档就是4个引脚，挡位越多越吃不消；
• 需要配置上下拉电阻，否则引脚悬空时状态不确定；
• 如果产品后续要扩展到6档、8档，PCB得改版，代码结构也得跟着改，非常不灵活。

如果你芯片引脚富余、档位又少，这么做没问题。可一旦你的板子像我的这样，GPIO被传感器、继电器、通信接口占得差不多了，还得为新功能腾位置，4路IO方案基本可以直接排除。

我的选择是：用一路ADC采样电压，通过不同的电阻分压值来区分挡位，1个引脚搞定全部状态识别。

这个方案的原理其实很简单：就是给旋转开关的每一档接不同阻值的分压电阻，公共端接ADC采样引脚。开关转到不同位置，ADC读到的电压就不一样，MCU根据电压区间判断当前处于哪个挡位。

2.2 电阻分压网络设计

这是我实际采用的电路结构，供参考：

VCC(3.3V) ──┬── R1 ──┬── ADC引脚 │ │ │ ├── R2 ── 挡位1 │ ├── R3 ── 挡位2 │ ├── R4 ── 挡位3 │ └── R5 ── 挡位4 │ GND

设计的关键在于电阻阻值的选取。一组挡位电压需要满足两个条件：第一，各挡位间电压差足够大，远超ADC的量化误差和电阻精度带来的误差；第二，同一挡位电压落在MCU供电电压范围之内，ADC引脚不能超过VCC。

我用的ADC是12位的，参考电压3.3V，分辨率大约0.8mV/LSB。在元件选型时，我取的是1%精度的贴片电阻，挡位间的电压差至少要留0.5V以上，这样才能保证在任何温度、批次偏差下都不会误判。

具体分压计算用最简单的公式：

V_adc = VCC * R_down / (R_up + R_down)

其中R_down是接地侧电阻，R_up是接VCC侧电阻。我给4个挡位分别设计了不同的接地电阻，公共上拉电阻R1取10kΩ，接VCC侧。各挡位电阻取值和理论分压如下：

这里有个很关键的小细节：电阻阻值不能选得太接近，否则挡位间电压差太小，加上ADC本身的噪声和电阻误差，很容易出现误判。我特意把相邻挡位的电压差都拉大到了200mV以上，实际用下来非常稳定。

2.3 ADC引脚采样的代码实现

2.3.1 初始化配置

以STM32的HAL库为例，ADC配置成单通道、连续采样模式。不需要DMA，一个挡位切换不是高频操作，轮询采样就够用了，省得把简单问题复杂化。

void ADC_Init(void) { ADC_ChannelConfTypeDef sConfig = {0}; hadc1.Instance = ADC1; hadc1.Init.ScanConvMode = DISABLE; hadc1.Init.ContinuousConvMode = ENABLE; hadc1.Init.DiscontinuousConvMode = DISABLE; hadc1.Init.ExternalTrigConv = ADC_SOFTWARE_START; hadc1.Init.DataAlign = ADC_DATAALIGN_RIGHT; hadc1.Init.NbrOfConversion = 1; HAL_ADC_Init(&hadc1); sConfig.Channel = ADC_CHANNEL_0; sConfig.Rank = 1; sConfig.SamplingTime = ADC_SAMPLETIME_239CYCLES_5; HAL_ADC_ConfigChannel(&hadc1, &sConfig); }

采样时间我特意选了最长的239.5个周期，目的是让ADC内部采样电容充分充电。旋转开关的触点本身有接触电阻，如果采样时间太短，电容没充满就开始转换，读出来的值会偏小，特别是开关触点氧化或者轻微脏污的时候，误差更大。宁可牺牲一点采样速度，也要保证数据的稳定性。

2.3.2 挡位识别逻辑

挡位识别不能简单地用“采样值等于某个数”来判断，因为ADC有量化误差、电源纹波、电阻温漂这些因素，读到的数值一定是在理论值附近波动的。正确做法是给每个挡位设一个区间，落在区间内就判定为对应挡位。

#define ADC_CH1_LOW 300 #define ADC_CH1_HIGH 450 #define ADC_CH2_LOW 580 #define ADC_CH2_HIGH 780 #define ADC_CH3_LOW 1250 #define ADC_CH3_HIGH 1480 #define ADC_CH4_LOW 1900 #define ADC_CH4_HIGH 2200 uint8_t GetSwitchGear(void) { uint16_t adc_val = ReadADC_Average(8); uint8_t gear = 0; if ((adc_val >= ADC_CH1_LOW) && (adc_val <= ADC_CH1_HIGH)) { gear = 1; } else if ((adc_val >= ADC_CH2_LOW) && (adc_val <= ADC_CH2_HIGH)) { gear = 2; } else if ((adc_val >= ADC_CH3_LOW) && (adc_val <= ADC_CH3_HIGH)) { gear = 3; } else if ((adc_val >= ADC_CH4_LOW) && (adc_val <= ADC_CH4_HIGH)) { gear = 4; } else { gear = 0; // 无效状态，可能是开关在切换过程中 } return gear; }

中间那个“0”状态不是多余的，它专门用来处理开关旋转过程中的过渡阶段。机械开关在切换瞬间，触点会经过一个断开再接通的过程，这个瞬间ADC采样值会落到两个挡位区间之间，直接判定就尴尬了。返回0可以让上层逻辑把这种过渡状态当成“当前挡位无效”处理，等采样值稳定了再更新状态。

2.3.3 滤波处理

我实测过，裸读ADC时单次采样值会有±10~20LSB的波动，这是正常的，毕竟内部有噪声、外部有电磁干扰。如果拿单次值去判断挡位，在挡位边界附近时很容易跳变。所以我做了两层滤波。

第一层是软件均值滤波，连续读8次，去掉最大最小各1次，剩下6次取平均。这样能去掉大部分随机噪声和偶发的尖峰脉冲。

uint16_t ReadADC_Average(uint8_t times) { uint32_t sum = 0; uint16_t min_val = 4095; uint16_t max_val = 0; uint16_t val = 0; uint8_t i = 0; for (i = 0; i < times; i++) { HAL_ADC_Start(&hadc1); HAL_ADC_PollForConversion(&hadc1, 10); val = HAL_ADC_GetValue(&hadc1); HAL_ADC_Stop(&hadc1); if (val > max_val) max_val = val; if (val < min_val) min_val = val; sum += val; } sum -= min_val; sum -= max_val; return (uint16_t)(sum / (times - 2)); }

第二层是状态确认，连续两次识别到同一个挡位才算有效。这样做的目的是防止开关触点抖动导致挡位瞬间跳变，尤其在设备运行中如果因为抖动误判挡位，可能会触发错误逻辑，后果就比较麻烦。

2.4 省IO方案的注意事项

这套方案的坑主要藏在硬件和判定的边界上，我提几个重点：

第一，电阻精度一定要选好的。如果你用5%精度的电阻，误差可能会把相邻挡位的电压区间直接压到几乎没有余量，这会让整个方案的基本盘不稳。我用的是1%贴片电阻，批量生产也不会出太大偏差。

第二，ADC参考电压必须是稳定的。如果你的VCC本身波动大，比如电池供电且电量下降时电压持续跌落，那么分压网络的电压会跟着变化，挡位判断区间也得动态调整。最简单的方法是直接在程序中留一个“ADC校准”指令，设备上电时测得各挡位实际ADC值并存入Flash，后续判断就用校准值，这样即使参考电压有偏差也影响不大了。

第三，PCB布局时，分压电阻和ADC引脚之间不要走太长太细的走线，否则容易引入噪声。ADC引脚附近尽量铺地，以及旋转开关的连线如果长了，最好用屏蔽线或双绞线，避免感应干扰。

注意：旋转开关接线时，公共端一定要接对。我见过有人把公共端和挡位端接反了，结果开关怎么转，ADC读到的值永远是一个电压——因为公共端变了，分压网络形态就变了。

3. 实操过程剖析

3.1 从原理图到实际接线

画好原理图后，我建议在打样前先做一块面包板验证。

面包板搭建的步骤不复杂：

1. 准备一个4档旋转开关，确认引脚定义。大多数旋转开关是单刀多掷结构，有一个公共端C，和若干个挡位端S1-S4。
2. 按前述分压网络，公共端C接10kΩ上拉电阻到3.3V，同时接ADC引脚。
3. S1接1kΩ到GND，S2接2kΩ到GND，S3接4.7kΩ到GND，S4接10kΩ到GND。
4. 用万用表测量各挡位下ADC引脚的电压，确认和设计值一致。

这一步很重要，因为市售旋转开关的内部结构可能和你设计的引脚顺序不一样，你不实测一遍，很难发现引脚定义搞错了。我用万用表测出来挡位1的实测电压是0.31V，和理论值0.30V非常接近，说明电阻精度和电路连接都没问题。

接着烧录程序，用串口打印ADC采样值和识别出的挡位。逐档旋转开关，确认每个挡位都能被正确识别，且在挡位边界处不会出现误判。

我把这个过程记录到了一张表格里：

4个挡位全部识别正确，且挡位间的采样值间隔都在300LSB以上，余量很充足，现场批量使用也不用担心误判。

3.2 代码中挡位判断的边界处理

挡位判断的区间宽度设置也值得单独说一下。区间太窄会有一个隐患：产品在批量生产时，不同板子之间的电阻误差、参考电压误差叠加后，同一挡位的实际采样值可能不一样。如果你的区间是按照“理论值±20LSB”来设计的，整个方案的裕量就太小了。

我在实际项目中把边界设成理论值±15%左右，例如挡位1的理论值是372，区间就设为300-450。这样即使遇到电阻偏差较大的批次，也能保证可靠识别。代价是挡位2的理论值682，而挡位1的区间上限是450，中间有232LSB的空白区域，这在4档场景下完全够用。

3.3 用示波器确认采样稳定性

在验证过程中我还用示波器看了一下ADC引脚的波形。旋转开关在切换瞬间，波形会有明显的抖动——高低电平来回跳几次后才稳定。这个现象是机械开关的抖动特性，和档位间的电容充放电也有关系。

我给ADC引脚并联了一个0.1uF的滤波电容，波形立刻好了很多，抖动幅度明显减小。这个电容既是硬件滤波，也减轻了软件滤波的负担。如果板上空间允许，这个电容一定不要省。

还有个细节是ADC引脚的采样电容充放电。如果旋转开关的线比较长，比如超过20cm，分布电容会改变分压点的等效阻抗，导致ADC读数偏低。这种情况可以在软件里做个比例校准，或者缩短走线长度。

4. 完整实操流程与核心环节实现

4.1 整体流程框图

这部分我们以实际项目主线串联一遍：上电初始化、采集ADC、识别挡位、打包数据、走Modbus上报。整个流程不复杂，但每一段都有值得注意的细节。

MCU上电 │ ├─ 初始化ADC、UART、Modbus寄存器表 ├─ 读取当前挡位（ADC采样+滤波+区间判断） ├─ 更新Modbus寄存器区的挡位状态字 ├─ 周期采集浮点数据（温度/电压等） ├─ 将float拆分成两个16bit寄存器存放 └─ 等待Modbus主机查询 │ ├─ 收到03功能码（读保持寄存器） ├─ 按协议返回寄存器数据 └─ 上位机按float规则还原数据

画这个流程不是为了凑篇幅，而是想把整个执行链路理清楚——从输入采集到数据上送，中间任何一个环节的格式不对，最终结果都是错的。接下来逐步拆解。

4.2 旋转开关挡位的采集流程

ADC采集部分前面已经贴过核心代码，这里讲一个工程上经常被忽略的环节——除抖定时器。

机械旋转开关在操作时，从用户“拧”的动作发生到触点稳定接触，通常需要几十毫秒。如果在触点还没稳定时就去做挡位判断和业务逻辑处理，很容易出现误动作。

我在代码里用一个简单的状态机来处理：

uint8_t Debounce_GetGear(void) { static uint8_t last_gear = 0; static uint8_t confirm_gear = 0; static uint32_t last_time = 0; uint8_t cur_gear = GetSwitchGear(); if (cur_gear != last_gear) { last_time = HAL_GetTick(); last_gear = cur_gear; } else if ((cur_gear != confirm_gear) && ((HAL_GetTick() - last_time) > 50)) { confirm_gear = cur_gear; } return confirm_gear; }

这个状态机的思路是：只有当某个挡位值持续50ms不变，才认为它是稳定状态。这样既避免了瞬间抖动导致的误判，又不会让响应延迟太久。用户旋转开关后，最多50ms就能看到状态更新，体感和速度都能接受。

4.3 Modbus寄存器区的数据结构设计

Modbus寄存器区的设计是整个通信链路的地基。如果寄存器地址规划得乱七八糟，后面写上位机对应表时一定会乱。

我习惯在代码中定义一个结构体，来映射Modbus的保持寄存器地址：

typedef struct { uint16_t gear_status; // 地址0x0000: 当前挡位 uint16_t float_h; // 地址0x0001: 温度值高16bit uint16_t float_l; // 地址0x0002: 温度值低16bit uint16_t voltage_h; // 地址0x0003: 电压值高16bit uint16_t voltage_l; // 地址0x0004: 电压值低16bit uint16_t freq_h; // 地址0x0005: 频率值高16bit uint16_t freq_l; // 地址0x0006: 频率值低16bit uint16_t crc_check; // 地址0x0007: 状态/校验信息 } ModbusReg_t;

用结构体映射寄存器表的好处是代码可读性强。通信层需要修改某个变量时，直接操作结构体对应的字段，不需要在多个函数之间传递裸指针和偏移量，省心也省事。

4.4 Modbus RTU的帧格式说明

Modbus RTU帧格式是我在实际项目中常用的一种，这里做一个快览——它是串口通信中最常见的协议形态之一，字节序和校验规则对后面的float拆分有直接影响。一个完整的请求帧由从站地址、功能码、数据区和CRC16校验构成。

请求帧（主机 → 从机，读保持寄存器，功能码0x03）： [从站地址1B] [功能码1B] [起始地址2B] [寄存器数量2B] [CRC16 2B] 响应帧（从机 → 主机）： [从站地址1B] [功能码1B] [字节数1B] [数据N*2B] [CRC16 2B]

比如主机要读从站地址为1的设备、从寄存器0x0001开始的2个寄存器，请求帧就是：

01 03 00 01 00 02 CRC_L CRC_H

从设备收到这条指令后，返回：

01 03 04 44 AA 33 CC CRC_L CRC_H

这里的44 AA 33 CC就是两个寄存器的原始字节，具体怎么还原成float，要看上位机和下位机约定的字节序规则。这一块是很多嵌入式现场联调最容易出问题的地方，下面单独展开讲。

5. Modbus中float的拆分与还原

5.1 float在内存中的存储格式

PLC或者单片机的C语言里，一个float变量占4个字节，按照IEEE 754标准来存储。这4个字节的含义如下：

• 第1位：符号位（0正1负）
• 第2-9位：指数位（8bit）
• 第10-32位：尾数位（23bit）

举个例子，温度值25.5℃存储为float类型，在内存中就变成了4个字节。具体多少取决于编译器和平台的大小端模式，但本质都是这4个字节的组合。

很多人不理解Modbus的float拆分为何麻烦，其实根源就一句话：Modbus寄存器是16bit为单位的，一个32bit的float必须塞进两个连续的保持寄存器里。

这里就产生了一个不可或缺的约定问题：

• 两个寄存器，哪个存高16位，哪个存低16位？
• 寄存器内部，是高字节在前还是低字节在前？
• 上位机程序用什么样的字节序去解释？

这三层只要有一层不一致，读数就是乱的。

5.2 将float拆成两个16bit寄存器

最常用也最推荐的方法是用联合体（Union）做类型双关，让编译器替你把float的4个字节拆开。在C语言里，union的所有成员共用同一块内存地址，写入float，按uint16_t读，就能拿到高低两个16bit数据。

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

发送端代码如下，把温度值拆分进两个寄存器地址：

Float32_Type temp; temp.f = current_temperature; reg_table.float_h = temp.u16[0]; // 高16bit reg_table.float_l = temp.u16[1]; // 低16bit

这样写完，寄存器表里就存好了拆分后的数据。上位机读取时，再按对应的字节序拼回去，就能得到正确的float。

5.3 用移位运算手工拆分的方案

有些工程师不喜欢用union，觉得不同编译器的内存布局可能有差异，更倾向于用纯移位运算手动拆分。这种写法不依赖任何内存布局，代码可移植性最高，也更直观。

void FloatToRegs(float value, uint16_t* reg_h, uint16_t* reg_l) { uint32_t temp = 0; // 把float的bit pattern取出来存到uint32_t里 temp = *(uint32_t*)&value; // 高16位 *reg_h = (uint16_t)(temp >> 16); // 低16位 *reg_l = (uint16_t)(temp & 0xFFFF); }

还原方向也一样：

float RegsToFloat(uint16_t reg_h, uint16_t reg_l) { uint32_t temp = 0; float result = 0.0f; temp = ((uint32_t)reg_h << 16) | (uint32_t)reg_l; result = *(float*)&temp; return result; }

这个方案的核心思路就是先把float的位模式整体搬运到uint32_t变量里，再用整数移位去切分高低16bit。整个过程完全由代码控制，不依赖平台的大小端，也不依赖编译器的union内存布局，在跨平台项目里更稳妥。

注意：*(uint32_t*)&value这种写法利用了指针类型转换，虽然常见于嵌入式代码，但严格来说在个别编译器下可能触发strict aliasing的未定义行为。如果你追求极致的规范，可以用memcpy来搬运字节，它在所有平台上都是定义良好的。

用memcpy的实现如下：

void FloatToRegs(float value, uint16_t* reg_h, uint16_t* reg_l) { uint32_t temp = 0; memcpy(&temp, &value, 4); *reg_h = (uint16_t)(temp >> 16); *reg_l = (uint16_t)(temp & 0xFFFF); }

实际工程中用哪种都行，单片机的GCC/Keil环境一般不走极端优化，union和指针转换都很常见。但如果你在写跨平台库，例如同时给STM32和PC上位机用同样的C源码，那么memcpy方案是最不容置疑的。

5.4 大小端模式的选择与传播

Modbus协议规范本身没有强制规定float在寄存器组内必须按什么字节序排列，这导致了一个很尴尬的局面：不同厂商的设备可能用不同的顺序存储float。结果就是同样的数据，A家的设备读出来是对的，B家的设备按同样方式读就是乱码。

常见的排列模式有两种：

模式A（高字在前）： 寄存器N = 数据高16bit 寄存器N+1 = 数据低16bit 模式B（低字在前）： 寄存器N = 数据低16bit 寄存器N+1 = 数据高16bit

我的建议是：在项目中固定使用“高字在前”，也就是高16bit放前一个寄存器。原因很简单：Modbus寄存器地址本身是从低到高排列的，把高字节放前面，更符合人类从左到右阅读16进制数据的习惯，而且上位机调试时直接看寄存器表，也能一眼看出大致的数值范围。

同时还要区分寄存器内部的字节序：每个16bit寄存器内部，数据是高位字节在前还是低位字节在前。对于大多数单片机默认的小端模式，而Modbus报文传输遵循大端字节序（Big-Endian），这里就牵扯到一个很隐蔽的坑：你往寄存器里写入0x1234，发到串口上，到底是先发0x12还是先发0x34？

标准答案是：Modbus RTU的规定是高字节先发，也就是先发0x12再发0x34。如果你的串口驱动直接发送一个uint16_t变量，且你的MCU是小端模式，那么内存里低地址是0x34，按字节发送时先发的反而是0x34，这样数据就反了。

所以正确做法是：发送寄存器数据前，必须手动把uint16_t按大端顺序拆成两个字节发送：

void UART_SendU16(uint16_t data) { uint8_t buf[2]; buf[0] = (data >> 8) & 0xFF; // 高字节 buf[1] = data & 0xFF; // 低字节 HAL_UART_Transmit(&huart, buf, 2, 10); }

这一条可以直接收藏，属于Modbus调试里最经典也最容易犯的错之一。

5.5 上位机还原float的示例代码

上下位机的规则一旦一致，上位机还原就很简单了。下面以C#为例，演示从两个ushort寄存器还原float：

ushort reg_h = 0x44AA; ushort reg_l = 0x33CC; uint temp = ((uint)reg_h << 16) | reg_l; float value = BitConverter.ToSingle(BitConverter.GetBytes(temp), 0); Console.WriteLine(value);

这段代码的核心思路是：先把两个16bit寄存器拼成一个32bit的整数，再通过BitConverter把这32bit的位模式解释成float。结果应该是25.5（假设原始float就是25.5）。

如果上位机是Python的，就更直接：

import struct reg_h = 0x44AA reg_l = 0x33CC temp = (reg_h << 16) | reg_l value = struct.unpack('>f', temp.to_bytes(4, 'big'))[0] print(value)

注意struct.unpack('>f', ...)中的>代表按大端序解释，这和Modbus协议的高字节先发规则是对应的。

5.6 两种常用工具实测抓包验证

推荐两个工具给你：Modbus Slave和Modbus Poll。一个用来模拟从站设备（接收指令），一个用来模拟主站（发送指令）。这两个工具配合使用，是Modbus联调时最标准的验证方式。

我实际测试的流程是：

1. 打开Modbus Slave，新建一个从站，从站地址设为1，寄存器起始地址0x0001，寄存器数量4。
2. 在Modbus Slave的寄存器表格里手动填入两个寄存器的值：地址0x0001填0x44AA，地址0x0002填0x33CC。
3. 打开Modbus Poll，设置相同的从站地址、功能码03、起始地址0x0001、寄存器数量2。
4. 点击连接，Modbus Poll会按设置的格式把两个寄存器的值合成一个float显示出来。

这个流程最大的价值在于：不依赖真实的设备，就能验证上位机的字节序设置是否正确。如果Modbus Poll显示出来的值和预期一致，说明上位机的解析逻辑没问题；如果不一致，那就是上下位机字节序约定不一致。

你可以把Modbus Poll的显示格式设置为Float ABCD或Float CDAB，切换对比，就能直观理解不同字节序对数据的影响——同一个寄存器内容，不同的字节序设置，解析出来的结果完全不一样。

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

6.1 挡位识别偶发跳变的排查过程

我的第一版代码在实验室里跑了一整天都正常，一到现场就出问题：旋转开关转到挡位2，设备偶尔会识别成挡位1，虽然概率很低，大约千分之一，但这种偶发性故障最难查。

排查步骤是这样的：

1. 先看ADC采样原始值，发现跳变瞬间的采样值确实落到了挡位1的区间。也就是说，不是判断逻辑的区间设置有误，而是ADC确实读到了偏低的电压。
2. 用示波器抓ADC引脚的波形，发现挡位2的理论电压是0.55V，但跳变瞬间波形上出现了一个很低的下冲，瞬间跌破0.45V。
3. 分析原因：旋转开关在转动时，触点先断开，此时ADC引脚通过10kΩ上拉电阻被拉到3.3V；接着触点接通挡位2，ADC引脚电压被拉低到0.55V。在这个切换过程中，线路上的寄生电感和电容形成了谐振，产生了短暂的下冲脉冲。
4. 解决办法：ADC引脚并联0.1uF滤波电容，同时加大软件滤波，把均值滤波次数从4次增加到8次。这样即使有瞬间的下冲，均值滤波也能把它平滑掉。

这个案例的启示是：机械开关的抖动问题，软硬件要协同解决。只靠硬件滤波，成本高且效果有限；只靠软件滤波，遇到强干扰时又不够稳。两手一起抓，效果才最理想。

6.2 浮点数据上位机显示不对的排查思路

上位机通过Modbus读取温度，显示出来的数值是天文数字，比如1.879e+20这种，或者干脆就是个负的很大数。这个问题的排查顺序可以按下面几步来：

1. 先用Modbus Poll直连从站，读取原始的寄存器值。如果原始值是0x44AA33CC，说明下位机发送的数据是正确的，问题出在上位机的解析逻辑。
2. 检查上位机的字节序设置。0x44AA33CC按不同的解释方式，会得到完全不同的结果：

有没有想过一个极常见的情况：你收到的寄存器值是0x000044AA，但其中有一个寄存器其实是别的变量而不是浮点数的组成部分。所以第三步是确认寄存器地址映射对不对，有没有偏移一位。

2. 检查上位机是不是按int类型解析了。如果把一个float的位模式当成int去打印，出来的数值往往会非常大——所以上位机变量类型必须是float或者double。
3. 检查字节序后再检查寄存器地址映射。如果读取的起始地址和下位机存放的地址差了1个寄存器，那么高16bit和低16bit就错位了，还原出的float自然就是乱的。

这套排查流程适用于大多数Modbus浮点数对不上的场景，建议收藏备用。

6.3 常见问题速查表

6.4 一个让我印象深刻的调试案例

有一次联调，对方上位机显示的电压值总是偏差2.5%左右。我一开始怀疑是电阻分压精度不够，或者ADC采样有问题，查了很久都没找到原因。

后来仔细看对方上位机代码才发现，他们把读取到的原始寄存器值先除以10再显示，这是因为他们以前用的某个传感器输出的是1/10V的单位。换了新设备后，他们忘了把这段转换逻辑改掉，导致所有读数都差了10倍。这虽然是个极低级的错误，但恰恰说明一个问题：上下位机的数据约定，不只是字节序，还包括量纲和缩放系数。联调前先把这些规则全部对齐，能省掉很多无意义的排查时间。

所以我在每次对接设备协议时，都会先写一份简单的协议文档，内容包括：

• 寄存器地址映射表
• 每个寄存器的数据类型（uint16、int16、float）
• float的字节序规则（高字在前还是低字在前）
• 数值单位与缩放系数
• 异常状态对应的特殊值

这份文档不贵写，但后面调试时节省的时间远超写文档的投入。嵌入式联调最大的敌人就是“约定不一致”，提前把约定书面化，是成本最低的避坑方式。

7. 后续扩展建议

4档旋转开关省IO采集的方案，扩展性其实比表面看起来更好。如果你后续档位从4档增加到8档，不需要增加任何IO引脚，只需要增加分压电阻的数量，然后重新设定判断区间即可。代码层面也只需要增加几个区间判断分支，改动量很小。

不过8档及以上时，需要考虑一个约束：在有限的电压区间内，挡位越多，每个挡位的判定区间必然变窄。3.3V供电、8个挡位，每个挡位分到的电压跨度只有400mV左右，扣除电阻误差和温度漂移，实际可靠判定的余量会明显变小。这时有两个调整方向：

• 换更高精度的电阻，比如0.5%甚至0.1%精度，把分压误差压到最小；
• 增加参考电压的稳压措施，比如用专门的基准源芯片给ADC供电，确保参考电压不随负载波动。

如果你是做锂电池供电设备，这种分压方案的功耗也要关注。分压网络的电阻值如果太小，静态电流会比较大。我这里用的10kΩ+10kΩ组合，在3.3V下静态电流不到0.2mA，基本可以忽略。如果电池供电且设备长期待机，可以把电阻值提高到100kΩ级别，静态电流降到微安级，但要注意ADC输入阻抗的需求——STM32的ADC输入阻抗要求在几kΩ到几十kΩ之间，阻值太高会导致采样值偏低，需要仔细核算。

关于Modbus的float传输，也可以考虑扩展支持int32类型和double类型。处理思路完全一样，只是拆分出来的寄存器数量从2个变成2个或4个。我项目里后来还加了一个功能：根据需要上报32位整数，用的是同一套拆分逻辑，只是省去了IEEE 754的位模式转换，更简单一些。

如果你想把省IO采集方案工程化得更彻底，还可以给每个挡位的ADC区间做成可配置的，通过Modbus寄存器下发阈值，这样即使现场出现电压偏差，也不需要改固件——这种设计在现场维护时真的能救命。

最后再分享一个小技巧：分压电阻网络的挡位切换，如果产品里没有旋转开关而是拨码开关，也是完全通用的。拨码开关的接触更稳、寿命更长，有些工况下比旋转开关更合适。判断逻辑和电路结构一模一样，只是开关本体换了外形而已。