011_仲裁丢失后报文重发的时序分析

011、仲裁丢失后报文重发的时序分析一个让人误判的现场现象前两年做一个多节点分布式采集项目，主控和几个采集从机挂在同一条总线上。调试阶段发现一个很诡异的现象：从机A在总线负载稍高的时候，上报的某一路数据偶尔会跳变一次，跳变后的值跟上一帧完全一样，但时间戳却更新了。更麻烦的是，主机侧的业务逻辑依赖“值变化”来触发告警，结果这个重复帧被当成了一次真实的数据更新，误报了几次。最开始怀疑是采集前端的问题，换了传感器、加了滤波、甚至重写了采集任务调度，都没用。后来拿逻辑分析仪抓总线波形，盯着仲裁段一帧一帧看，才发现问题出在仲裁丢失后的重发时序上——从机A在仲裁丢失后，并没有立即重发，而是等到了一个“看起来合理”的时机才把旧数据重新推上总线，导致主机收到了一帧内容相同但时间戳更新的报文。这个坑让我意识到，仲裁丢失这件事，很多资料只讲了“谁赢了谁继续发”，但丢失之后到底什么时候重发、重发时数据缓冲区里的内容是什么状态，才是真正决定系统行为的地方。仲裁丢失那一瞬间，硬件到底做了什么先把这个过程拆开看。总线上的节点在发送时，会一边发一边读回总线电平。当它发隐性电平却读回显性电平，就知道自己丢了仲裁。这时候硬件通常会做几件事：立即停止发送剩余的数据位和校验位；把发送缓冲区的状态标记为“仲裁丢失”；切换到接收模式，把当前正在进行的这帧报文完整收完；等待总线空闲，然后尝试重新发送。关键就在第四步。“等待总线空闲”这个条件，不同实现之间的差异非常大。有