企业官网建设流程全解析

020、远程帧与数据帧混用时的响应冲突

一个让我通宵改代码的夜晚

前年做一套分布式采集设备，主控和六个采集节点跑在一条总线上，速率不高，线也不长，实验室里跑了一整个白天都稳如老狗。晚上十一点多，我把新写的轮询逻辑烧进去，问题来了——主控每隔两秒会随机丢一次节点响应，丢的那次没有任何规律，换节点、换线序、换终端电阻都试过，示波器抓波形也看不出明显异常。

那一晚我一度怀疑是收发器批次问题，甚至把板子拆了重新走线。天亮前我把逻辑分析仪挂上去，抓了整整一屏报文，才看到一个反直觉的现象：某个节点在收到主控的远程帧之后，回了一帧数据，但紧接着又自发地补了一帧数据，两帧间隔不到一个位时间。而主控那边，刚好把第二帧当成了下一轮的响应，于是整个轮询序列错位，后面全部对不上。

问题根源就是这篇文章要讲的：远程帧和数据帧混用时的响应冲突。这不是配置错误，也不是硬件故障，而是协议层一个非常隐蔽的时序陷阱。公开资料里讲远程帧，通常只告诉你“远程帧用于请求数据”，但几乎没人讲清楚：当请求方和被请求方对“谁该在什么时候发”理解不一致时，总线会发生什么。

先把这个坑的物理现场还原出来

远程帧的机制本身不复杂：一帧远程帧里，标识符和正常数据帧一样，但数据长度码可以填期望的字节数，数据场为空。节点收到这个标识符的远程帧后，如果它负责提供该标识符对应的数据，就应该回一帧同标识符的数据帧。

问题出在“应该”这两个字上。协议只规定了应该回，没有规定必须回、什么时候回、回几帧。这就给实现留下了巨大的自由空间，而自由空间就是事故空间。

我当时那套