Modbus从站低间隔轮询为什么丢帧：接收缓冲、帧边界与发送完成

单台设备每秒读一次都正常，改成连续轮询、多地址切换或更短等待后，就出现超时、CRC错误，甚至必须重新上电才能恢复。这类现象不一定是RS485硬件抗干扰不足：接收中断没有及时取走数据、帧处理占用接收缓冲、方向控制提前释放，以及主站发送本身已经违反时序，都可能造成相似结果。

本文面向YQWSK温湿度控制器、带通讯选配的YQCS除湿装置及YQDM电力仪表的开发与联调，讨论Modbus RTU从站的软件可靠性。不同产品支持的波特率、寄存器、功能码及最小响应时间，以各自协议为准；下面的时间算例与接收框架用于分析，不宣称所有益旗产品采用同一款MCU或同一段固件。

一、低间隔必须先说清楚是哪个间隔

“间隔设为1ms”至少可能有四种含义：两次软件写串口之间、请求尾字节到响应首字节、响应结束到下一请求，或同一帧里两个字符之间。把这些时间混在一起，会让测试结果失去可比较性。尤其是USB转串口和网页工具，软件写入时间不等于字节已经从A/B线上发完。

正常单主站RTU测试应先完成当前请求—响应事务，再启动下一事务。故意在从站尚未回复时发下一个请求，属于重叠请求或破坏性时序测试，应单独标注，不能把造成的碰撞直接计入“合法轮询丢包率”。

二、字符时间和总线占用决定了速度下限

字符时间等于每字符位数除以波特率。8E1包含起始位、8个数据位、校验位和停止位，共11位；8N2同样为11位，8N1为10位。Modbus串行规范以相应字符格式定义帧间隔，部分产品协议指定8N1时，应明确这是设备约定，不要悄悄用10位结果替代11位算例。

03读取10个寄存器时，正常响应为地址1字节、功能码1字节、字节数1字节、数据20字节和CRC2字节，共25字节。相同格式下响应占线约28.646ms，单是收发33字节就需要37.813ms，尚未包含帧间静默、从站处理及主站调度。因此不能要求每10ms完成一次这样的完整事务。

上述都是理论线速算例，不是网页工具实测。实际测试应同时保存配置值与观察到的时序；计时精度不够时，只报告软件层间隔，不冒充微秒级线上时序。

三、t1.5与t3.5不是随便加一个延迟

Modbus串行实现指南V1.02规定了RTU字符与帧之间的时间约束。低速场景按字符时间处理；高于19200bit/s时，指南建议采用750µs的字符间超时和1.750ms的帧间延时。二者用途不同，不能因为固定长度请求已收满8字节，就完全忽略后续是否还有数据和有效帧边界。

以9600、11位字符算例，t1.5约1.719ms，t3.5约4.010ms。若固件只用2.5ms一次的定时中断累加接收间隔，时间量化本身就足以显著影响判帧边界。调整某个计数阈值可能让某一台主站暂时稳定，却不等于已经覆盖所有发送相位和波特率。

可采用足够细的时间基准或串口空闲事件配合实际时间戳实现判定，但应先核对芯片空闲事件的真实定义。算法应区分有效接收、帧内超时和等待重新同步；错误帧结束前不要从中间随意截取一段数据当成新的合法命令。

四、业务忙的时候，也要处理串口接收硬件

常见隐患是接收中断进入后先判断“上一条命令还没处理完”，如果忙就直接返回。这看似保护了软件缓冲，实际上可能没有读走UART接收寄存器。后续字符继续到来，有限的硬件接收缓存溢出，某些UART会停止继续接收，形成“偶尔一忙，后面再也不回复”。

正确方向是把“及时服务接收硬件”和“是否接纳为业务命令”分开。即使当前决定丢弃新的请求，也需要按芯片要求处理接收数据、错误标志和溢出恢复。不要把某款PIC的CREN/OERR处理方式直接复制到STC或其他UART；查对应器件手册，确认错误状态、数据读取和接收重启的顺序。

以部分PIC EUSART为例，接收溢出与普通帧格式错误是不同状态，恢复机制应参照其EUSART章节。Microchip的PIC18(L)F1XK22数据手册可作为理解这类外设机制的参考，但并不代表正在测试的产品就采用该芯片。

五、缓冲区所有权比“加大数组”更重要

中断接收下一帧时，主循环可能还在计算上一帧CRC。如果双方共用同一个数组，主循环看到的前半帧和后半帧可能来自不同请求。把数组扩大不会解决所有权冲突；需要明确正在写入的缓冲、等待处理的完整帧以及发送响应的数据分别由谁维护。

双缓冲和环形队列都可以使用，但必须定义队列满时的行为：拒绝新的业务帧、记录过载，并在规定的有效边界恢复。不能溢出后覆盖内存，不能悄悄把半帧与下一帧拼接。小RAM单片机未必适合复杂队列，简单而边界清楚的策略通常更容易验证。

六、地址正确、长度8字节，还不足以执行命令

03和06的常见RTU请求恰好为8字节，不代表所有功能都是8字节，也不代表第8个字节一到就可以改参数。执行前必须确认完整性、CRC、地址、支持的功能码、寄存器范围、数量及参数值。长度判断应与功能码一致，不受上一次请求遗留长度影响。

坏CRC或损坏的串行帧应按协议丢弃，不能误执行写入。合法寻址但功能或参数不支持时，应按该产品所实现的协议返回对应异常。广播、保留地址和不属于本机的请求要分别处理；若产品协议未支持广播写入，不要为了测试方便假定地址0可以随便写。

对于只支持03/06的除湿器协议，0x10多寄存器写入不能算正常业务成功用例。可以在隔离测试环境下用于验证不支持功能的处理，但评价目标是拒绝与恢复正确，而不是要求设备完成协议之外的写入。

七、发送寄存器空，不等于最后一个停止位已发完

半双工RS485必须在发响应时驱动总线，在响应完整发完后释放。UART发送数据寄存器可以继续装字节的标志，往往早于最后一个字符真正离开移位寄存器。如果此时就关闭DE，末尾数据或CRC可能被截断；如果DE迟迟不释放，又可能占住下一次请求的总线。

固件应核对实际芯片的“发送缓冲可写”和“移位发送完成”两个语义，再结合收发器使能/关闭延迟安排方向控制。以某些PIC外设的TXIF与TRMT命名为例，它们并不是同一件事。不能把“把最后一个字节写进TXREG”当成物理发送完成。

验证时同时观察TX、DE和A/B最有帮助；只有软件发送日志，不能证明线路最后一位已经完整。若收发器支持本机发送回读，还应明确回显字节是否进入接收解析器，避免把自己的响应误当请求。

八、用两套测试报告分别评价性能与恢复能力

写入测试可能改变阈值、地址、波特率，甚至驱动真实负载。应选择台架上经确认可写的参数，保存旧值并回读恢复；涉及实际执行器的测试先隔离负载。反复写入非易失存储器还需要考虑写入寿命，不能把无休止06写入当成普通通讯读压力测试。

每组异常输入后，插入已知合法的只读请求，记录恢复成功与耗时。仅证明坏帧没有应答还不够：设备如果从此停止接收，仍然是恢复失败。恢复门限应由项目需求和固件能力定义，不用未经测试的固定毫秒值作为承诺。

九、真实从机和模拟从机混合时，分清压力施加到哪里

如果工具在浏览器内直接生成三个模拟从机的响应，只有一个地址发往真实串口，那么真实总线并没有经历四台物理从机的全部通信。它适合验证调度、界面和报告流程，不能直接称为“四台从机总线压力”。要评价真实设备受到的线速占用，应以实际发送到串口的帧为准。

即使将访问其他地址的请求也发上真实总线，没有物理从机回复时，也不能把软件生成的响应当成线上回包；反过来，一个连接在真实总线上的从机通常仍会接收到其他地址请求的字节，这可以用于检查地址过滤与接收服务能力。报告应区分真实发送、真实接收和软件模拟三个来源。

可用多从机轮询主站建立地址与读取任务，用UART/RS485时序工具辅助核对字符与帧时间，再用串口助手保存原始帧。各工具实际能力以页面为准；软件工具无法生成真实电磁干扰，也不能替代逻辑分析仪验证线上的微秒时序。

十、报告不要只写“成功率99.9%”

至少分开记录：真实发起事务数、首次成功数、重试后成功数、完全超时数、CRC错误、异常响应、数据内容不符、设备复位迹象和异常输入后的恢复结果。合法异常响应证明协议端有反应，但不等于业务读取成功；同一事务重试三次，不能按三次独立业务成功统计。

响应时间要定义起止点，平均值之外可报告P95、P99和最大值，同时写明样本数量与计时层级。读到数据还要检查地址、功能码、字节数和映射，必要时使用可控变化量判断是否为陈旧数据。RTU没有TCP式事务标识，同地址同功能的迟到响应尤其需要主站严格串行化和超时恢复策略。

例如一万次合法事务首次失败10次、重试后全部成功，应同时写首次成功率99.9%和最终成功率100%，并保留这10次失败的原始记录。零失败也只说明这组配置、样本和运行时间内未观察到失败，不证明所有现场条件都可靠。

最终可维护的结论应是：“在什么格式、波特率、读写范围和实际间隔下，设备表现如何；何种异常输入后是否恢复；线上证据和软件日志是否一致。”这样才能把优化接收中断、调整缓冲交接和改善主站调度的收益分别验证出来。

本文由温州益旗电气有限公司原创发布，转载请注明出处：yqelect.com。