4、Modbus从站架构设计：从站状态机、请求解析、响应生成、异常处理
好，咱们今天聊聊从站。主站是发号施令的，但从站才是真正干活的。一个从站设计得不好，整个网络就等着崩溃吧。我见过太多项目，主站代码写得花里胡哨，从站却一塌糊涂，结果通讯三天两头断。说白了，从站才是Modbus网络的基石。
4.1 从站核心状态机
从站本质上就是一个有限状态机。别被「状态机」三个字吓到，其实就是个循环，不断问自己三个问题：
- 有没有收到新请求？
- 请求对不对？
- 怎么回？
我个人习惯把从站状态机分成四个核心状态：
| 状态 | 说明 | 典型动作 |
|---|---|---|
| IDLE | 空闲等待 | 监听串口或网络，等待帧头 |
| RECV | 接收中 | 按字节积累数据，检查帧间隔超时 |
| PROC | 处理中 | 解析请求、执行操作、生成响应 |
| SEND | 发送中 | 将响应帧发出，等待发送完成 |
嗯，这里要注意：IDLE状态下必须做超时复位。我在项目中遇到过，从站收到半个帧就卡住了，结果整个网络都跟着遭殃。所以每次进入IDLE，我都会把接收缓冲区清空，计数器归零。
关键设计原则：状态切换必须用定时器做看门狗。任何一个状态停留超过50ms，强制跳回IDLE。这是血的教训换来的。
4.2 请求解析：从字节流到指令
收到一帧数据后，解析工作就开始了。你想想看，Modbus帧结构其实很简单：地址、功能码、数据、校验。但坑就藏在细节里。
解析流程我建议按这个顺序来：
- 地址校验：先看是不是发给自己的。不是？直接扔掉，别浪费CPU。
- 帧长度检查：RTU模式下，根据功能码就能算出最小长度。比如读线圈(0x01)，固定8个字节。少了？直接报错。
- CRC校验：这是最后一道防线。我见过有人先校验再查地址，结果广播地址的帧全被当成错误扔了。
- 功能码识别：只支持你实现了的功能码。不支持的就返回异常码01。
个人经验：我曾经在一个项目里，从站同时支持RTU和ASCII两种模式。解析时先判断第一个字节是0x3A(冒号)还是其他，以此区分模式。这个判断一定要放在最前面，否则ASCII帧会被当成RTU帧解析，CRC校验永远过不了。
4.3 响应生成：快、准、稳
响应生成其实比请求解析更讲究。为什么？因为主站等着你的回复，你慢了，主站就超时重发，网络就乱了。
响应帧的结构：
从站地址(1字节) | 功能码(1字节) | 数据(N字节) | CRC校验(2字节)生成响应时，我习惯用「零拷贝」策略。什么意思？就是直接在发送缓冲区里组装，不经过中间变量。比如读保持寄存器：
// 伪代码示例
void build_read_holding_registers_response(uint8_t* buf, uint16_t* regs, uint8_t count) {
buf[0] = slave_addr; // 地址
buf[1] = 0x03; // 功能码
buf[2] = count * 2; // 字节数
for(int i=0; i<count; i++) {
buf[3 + i*2] = regs[i] >> 8; // 高字节
buf[4 + i*2] = regs[i] & 0xFF; // 低字节
}
uint16_t crc = calc_crc(buf, 3 + count*2);
buf[3 + count*2] = crc & 0xFF;
buf[4 + count*2] = crc >> 8;
}你看，数据直接往缓冲区里填，省了一次内存拷贝。在低端MCU上，这能省下几十微秒。
注意：多寄存器操作时，一定要检查地址范围。我曾经遇到过，主站请求读地址0x0000到0xFFFF，从站直接崩溃了。所以响应前必须做边界检查：起始地址+寄存器数量不能超过实际存储区。
4.4 异常处理：优雅地拒绝
异常处理是从站设计中最容易被忽视的部分。很多人觉得「反正主站会重试」，结果把整个网络搞瘫痪。
Modbus定义了11种异常码，但常用的就这几个：
| 异常码 | 名称 | 触发条件 |
|---|---|---|
| 01 | 非法功能码 | 收到不支持的功能码 |
| 02 | 非法数据地址 | 请求的寄存器/线圈地址超出范围 |
| 03 | 非法数据值 | 请求的数据数量超出限制 |
| 04 | 从站设备故障 | 硬件错误，比如EEPROM读写失败 |
| 06 | 从站设备忙 | 正在处理上一个请求，无法响应 |
异常响应帧的格式：
从站地址(1字节) | 功能码|0x80(1字节) | 异常码(1字节) | CRC校验(2字节)举个例子，如果主站发了个功能码0x07，而从站不支持，那就返回：
0x01 0x87 0x01 0xXX 0xXX
// 地址1, 功能码0x87(0x07|0x80), 异常码01, CRC这里有个细节：异常响应里的功能码，最高位要置1。这是Modbus协议规定的，主站靠这个区分正常响应和异常响应。
避坑指南：我曾经在一个项目里，从站收到非法请求后直接不回复。结果主站等超时，重发三次，然后报「从站离线」。后来改成返回异常码02，主站收到后立刻知道是地址错了，直接跳过。整个通讯效率提升了一大截。
4.5 实战中的几个坑
最后分享几个我踩过的坑，你们遇到了能少走弯路：
- 广播地址0x00不要回响应：Modbus规定广播帧不需要回复。如果你回了，总线上多个从站同时发数据，直接冲突。
- 写操作要加互斥锁：如果从站同时支持Modbus和本地控制，写寄存器时一定要加锁。否则Modbus刚写完，本地逻辑又改了，数据就乱了。
- 异常码04要慎用：这个码表示「设备故障」，主站收到后通常会报警甚至停机。除非真的硬件坏了，否则别乱用。我一般只在EEPROM校验失败时才返回04。
- 响应超时设置：从站处理请求的时间，最好控制在10ms以内。如果超过20ms，主站那边可能已经超时重发了。
好了，从站架构的核心就这些。说白了就是：收得准、解得对、回得快、错得明。下一章咱们聊聊多设备组网，那才是真正考验设计能力的地方。