Modbus RTU主站轮询核心在于精确控制3.5字符帧间隔、严防粘包、手写匹配0xA001多项式的CRC16校验（低字节在前），并用状态机管理超时与地址越界防护，禁用流控与校验位以确保帧结构纯净。
单片机用 C++ 做 Modbus RTU 主站轮询，核心不是“能不能”，而是“怎么控时序、怎么防粘包、怎么校验不翻车”——RTU 不是 TCP，没有连接状态，全靠帧间静默间隔和 CRC 保命。
Modbus RTU 主站必须手动处理 3.5 字符时间间隔
RTU 协议规定：两帧之间必须保持 ≥3.5 个字符的静默（silent interval），否则从站会认为是同一帧的续传，直接丢弃或误解析。这个值不能靠 sleep 粗略估算，得按波特率精确算。
- 例如 9600 波特率下，1 字符 = 10 bit（1 起始 + 8 数据 + 1 停止），传输 1 字符耗时 ≈ 10 / 9600 ≈ 1.04 ms，3.5 字符 ≈ 3.64 ms
- 实际代码中建议用
usleep(4000)或更高一点留余量，但别用sleep(1)这种秒级调用——会严重拖慢轮询节奏 - 如果用 HAL 或 CMSIS 库，优先查
HAL_UARTEx_ReceiveToIdle_IT或类似空闲中断接口，比轮询更可靠 - 裸机环境下，务必在发送完一帧后清空 UART 发送完成标志，并等待 TXE + TC 都置位再延时，否则可能只发了半帧就切到延时
CRC16 校验必须手写且严格对齐字节序
RTU 的 CRC 是 Modbus-RTU 专用多项式（0xA001），输入数据不含地址和功能码前的起始位/停止位，只校验地址 + 功能码 + 数据区，且 CRC 低字节在前、高字节在后（小端）。
- 常见错误：用通用 CRC16-CCITT（0x1021）代替；或把整个 UART 缓冲区（含起始位）喂给 CRC 函数
- 正确范围示例：对请求帧
0x01 0x03 0x00 0x00 0x00 0x01，只对这 6 字节计算 CRC，结果如为0x840A，则帧末尾应为0x0A 0x84 - 建议把 CRC 计算封装成独立函数，输入
uint8_t*和len，返回uint16_t，避免每次重复写逻辑 - 调试时可先用 Python 的
pymodbus生成标准帧对比 CRC，确认你的实现没偏移
轮询逻辑要防超时、防重发、防寄存器地址越界
主站在嵌入式环境里资源有限，不能像 PC 上那样开线程等响应，得用状态机驱动轮询，每个从站地址单独维护超时计数器。
立即学习“C++免费学习笔记（深入）”；
- 典型流程：发帧 → 启动定时器（比如 200ms）→ 等接收中断 → 收到完整帧后校验地址+功能码+CRC → 匹配成功则更新数据，失败则标记超时
- 别在未收全帧时反复重发：RTU 从站无 ACK，重发只会让总线更拥堵；应等超时后再发下一帧
- 读保持寄存器时，地址参数是 0-based 还是 1-based？协议文档说“寄存器地址从 0x0000 开始”，但很多设备手册写“起始地址填 40001”，这时你要做转换：
addr_in_frame = addr_from_ui - 40001 - 务必检查
start_addr + reg_count是否超出你分配的缓冲区大小，否则 memcpy 可能越界写到栈或全局变量上
串口配置必须关掉所有自动流控和奇偶校验干扰项
RTU 默认用 8N1（8 数据位、无校验、1 停止位），任何额外的硬件/软件流控都会破坏帧结构，导致 CRC 永远不匹配。
- 初始化 UART 时，强制设置：
parity = NONE、stop_bits = ONE、flow_control = NONE - Linux 下用 termios，注意清除
options.c_cflag &= ~PARENB和options.c_iflag &= ~(IXON | IXOFF) - STM32 HAL 中，确保
huart.Init.Parity = UART_PARITY_NONE，且不使能UART_HWCONTROL_RTS - 接收缓冲区大小建议 ≥256 字节（RTU 单帧最大 256 字节），并用环形缓冲区管理，避免因中断响应慢而丢帧
真正卡住人的地方，往往不是协议没读懂，而是 UART 寄存器没清干净、CRC 表查错了索引、或者静默间隔少延了 0.2 ms 导致从站集体失联。轮询不是发完就完，每一帧都要有明确的状态出口和兜底超时。
