010、总线负载率升高后优先级反转的观察一个让人后背发凉的现场去年冬天，一个做运动控制设备的团队找我帮忙看问题。他们的系统里有一个主控单元和三个执行节点挂在同一条总线上，平时跑得好好的，响应时间稳定在几百微秒。但客户那边有个工况，一旦同时启动多轴联动，操作面板上的急停响应就会从几十毫秒突然劣化到四五百毫秒，偶尔还会丢帧。他们一开始怀疑是总线速率不够，把波特率往上提了一档，结果更糟——丢帧更频繁了。又怀疑是线缆太长、终端电阻不匹配，折腾了一圈硬件，现象依旧。最后他们把抓包数据发给我，我看了一眼就发现了一个很典型但很少被拿出来讲的问题：高优先级报文确实在总线空闲时能优先发出去，但在总线负载率超过某个阈值之后，低优先级报文占着总线不放，高优先级报文反而要等更久。这就是优先级反转在总线层面的表现。它不是操作系统里那个经典的信号量反转，但本质一样：优先级机制在负载升高后失效了，甚至帮了倒忙。先搞清楚总线仲裁到底怎么工作的大部分现场总线用的是基于优先级的逐位仲裁机制。每个报文有一个标识符，标识符数值越小优先级越高。当多个节点同时开始发送时，它们逐位比较标识符，谁先发出显性位谁就赢得仲裁，输的那个节点自动退让，等下一轮再试。关键在于：仲裁只发生在“同时开始发送”的时候。如果一个低优先级报文已经赢得了仲裁并正在传输数据段，此时高优先级报文才准备好要发，那它只能等——等当前这一帧完整传完，总线回到空闲状态，才能参与下一轮仲裁。这就是第一个隐形陷阱：优先级只决定“竞争时的胜出者”，不决定“正在传输的帧可以被抢占”。总线不是可抢占的调度器，
010、总线负载率升高后优先级反转的观察一个让人后背发凉的现场去年冬天，一个做运动控制设备的团队找我帮忙看问题。他们的系统里有一个主控单元和三个执行节点挂在同一条总线上，平时跑得好好的，响应时间稳定在几百微秒。但客户那边有个工况，一旦同时启动多轴联动，操作面板上的急停响应就会从几十毫秒突然劣化到四五百毫秒，偶尔还会丢帧。他们一开始怀疑是总线速率不够，把波特率往上提了一档，结果更糟——丢帧更频繁了。又怀疑是线缆太长、终端电阻不匹配，折腾了一圈硬件，现象依旧。最后他们把抓包数据发给我，我看了一眼就发现了一个很典型但很少被拿出来讲的问题：高优先级报文确实在总线空闲时能优先发出去，但在总线负载率超过某个阈值之后，低优先级报文占着总线不放，高优先级报文反而要等更久。这就是优先级反转在总线层面的表现。它不是操作系统里那个经典的信号量反转，但本质一样：优先级机制在负载升高后失效了，甚至帮了倒忙。先搞清楚总线仲裁到底怎么工作的大部分现场总线用的是基于优先级的逐位仲裁机制。每个报文有一个标识符，标识符数值越小优先级越高。当多个节点同时开始发送时，它们逐位比较标识符，谁先发出显性位谁就赢得仲裁，输的那个节点自动退让，等下一轮再试。关键在于：仲裁只发生在“同时开始发送”的时候。如果一个低优先级报文已经赢得了仲裁并正在传输数据段，此时高优先级报文才准备好要发，那它只能等——等当前这一帧完整传完，总线回到空闲状态，才能参与下一轮仲裁。这就是第一个隐形陷阱：优先级只决定“竞争时的胜出者”，不决定“正在传输的帧可以被抢占”。总线不是可抢占的调度器，
