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