RS485通讯协议代码详解：一个Modbus RTU主站工程师的真实手记
你有没有在凌晨三点盯着示波器，看着RS485总线上一串跳动的差分信号发呆？
有没有在产线调试时，明明帧结构对了、CRC也校验通过了，但从站就是“装死”不回包？
有没有因为DE引脚关早了10微秒，导致最后一字节发送失败，而反复烧录固件直到天亮？
这不是玄学——这是Modbus RTU主站在真实工业现场落地时，每个嵌入式工程师都踩过的坑。今天我不讲协议标准文档里的定义，也不堆砌术语，只和你聊聊：一个能跑在STM32上、扛得住电磁干扰、连得上老式电表、修得了现场故障的Modbus RTU主站，到底是怎么写出来的。
从一根双绞线开始：为什么RS485成了工业现场的“沉默骨干”
先说个现实：你手上那块STM32F407开发板，UART引脚直接接RS485芯片（比如SP3485），再拉一根双绞线出去——这看似简单的一环，恰恰是整个通信链路最脆弱、最容易被忽视的一环。
RS485不是“插上线就能通”的USB。它靠的是差分电压摆幅（±1.5V～±6V）对抗共模噪声，靠的是终端匹配电阻（120Ω）抑制信号反射，靠的是严格的方向切换时序避免总线冲突。这些细节不会出现在HAL_UART_Transmit()的API说明里，但它们决定了你的设备能不能在变频器旁稳定运行三年。
✅ 实测经验：在某水泥厂现场，去掉两端120Ω终端电阻后，9600bps下误码率从0飙升至12%；加回后，连续72小时无CRC错误。
所以别急着写Modbus帧，先确认三件事：
- 总线两端是否已焊接120Ω贴片电阻？
- DE/RE控制引脚是否独立、未与其他外设复用？
- MCU的地与RS485收发器的地之间，是否做了单点连接（而非浮空或多点接地）？
这些物理层的“土办法”，往往比优化CRC算法更能解决90%的通信失败。
Modbus RTU帧：不是字节拼接，而是时间契约
很多人以为Modbus RTU就是“地址+功能码+数据+CRC”拼一起发出去。错。它本质上是一份基于时间的隐式契约。
- 帧边界不由起始位/停止位定义，而由≥3.5个字符的静默期判定；
- 帧内字符间隔必须＜1.5个字符时间，否则从站认为帧已损坏；
- 地址域（1字节）、功能码（1字节）、数据域（N字节）共同参与CRC计算，CRC本身不参与校验；
- 所有16位字段（如寄存器地址、数量）必须高位在前（Big-Endian），这是RTU强制规定，不是可选项。
这就意味着：你在构造读保持寄存器请求（0x03）时，如果把寄存器地址0x1234写成{0x34, 0x12}，从站会去读0x3412号寄存器——而这个地址很可能根本不存在。
// ❌ 错误示范：小端写法（常见于没细读Spec的新手） req->data[0] = start_reg & 0xFF; // 低字节先放 req->data[1] = (start_reg >> 8) & 0xFF; // 高字节后放 // ✅ 正确写法：Big-Endian，Modbus RTU唯一合法顺序 req-
