最近在学习CAN总线，原先一直不太明白，若有A，B 2个节点同一时刻一起向总线上发送数据，CAN总线是怎么仲裁的，来让A，B其中一个节点退出，保证高优先级的节点优先传输，今天又在网上查了一些资料，总算搞明白了一些。
在CAN总线上，若同一个时刻，既有节点向总线上发送隐形电平（1），也有节点发送显性电平（0），那么此时总线上表现出来的为显性（0）。
当总线空闲时，有多个节点同时需要发送报文，那么每个节点的发送器将会对发送位的电平和被监控的总线电平做比较，如果电平相同，那么该节点可以继续发送，如果发送的为一“隐性”电平（1），但是监控到一“显性”电平（0），那么该节点失去仲裁，必须退出发送状态，只到下一次总线空闲的时候在参与总线的仲裁竞争。
由以上也可以看出，当有多个节点同时争夺总线的控制权，ID最小的那个节点将会胜出，所以在CAN总线上，节点的ID越小，优先级越高。
先列举2种特殊情况，根据仲裁来判断优先级。
1. 若在同一时刻，标准格式的报文与扩展格式的报文同时抢占总线，且它们的基础ID相同，则发标准格式的报文节点就会PK成功。这是因为扩展格式在基本ID后，紧接着是SRR位，与IDE位，且这两位都是隐性位。而在标准格式中，这两位分别对应的位为RTR与r1，其中RTR既可以为隐性位，也可以为显性位，，但是r1必须为显性位。由仲裁规则可以此时标准帧必定胜出。
2. 同理，如果在同一时刻，具有相同格式，且具有相同ID的数据帧与远程帧争夺总线控制权，那么数据帧必定胜出。因为RTR显性表示数据帧，隐性表示远程帧。
今天又发现了一个问题，前几天也是在21IC的论坛上看见有这样一条帖子，上面说如果有2个节点具有相同的ID，同时向总线上发送不同的数据帧，那么这两个节点将会继续仲裁数据场，只到有一方退出。开始我也是这样认为的，但是下午在看到CAN-bus规范V2.0上，关于应答场（ACK）部分的时候，想到了， 如果真是如上所述，就会出现一种比较奇怪的现象：
即如果总线上，只有A,B 2个节点，当前只有A节点发送报文，B节点再接收，按照以上的观点，那么将会发生什么呢？在应答场（ACK）应答间隙（ACK SLOT）的时候，A节点将会发送一个“隐性”位（1），但是同时，B节点却会发送一个“显性位”（0）来以示应答（这里假设B节点正确接收到有效的报文），那么此时总线上表现出来就是“显性”（0）了。但是A却是发送的是“隐性”（1）啊，那么按照上述说法，此时A节点就要退出总线了，也就不在发送应答界定符（ACK DELIMITER）(显性1)，了，此时总线上就会一直保持显性（0）状态，只到位错误的发生。
因此，以上说法是不成立的，其实由CAN-bus规范V2.0的P8页上有如下语句：
Arbitration
Whenever the bus is free, any unit may start to transmit a message. If 2 or more units
start transmitting messages at the same time, the bus access conflict is resolved by
bitwise arbitration using the IDENTIFIER. The mechanism of arbitration guarantees that
neither information nor time is lost. If a DATA and a REMOTE with the
same IDENTIFIER are initiated at the same time, the DATA prevails over the
REMOTE . During arbitration every transmitter compares the level of the bit
transmitted with the level that is monitored on the bus. If these levels are equal the unit
may continue to send. When a ’recessive’ level is sent and a ’dominant’ level is
monitored (see Bus Values), the unit has lost arbitration and must withdraw without
sending one more bit.
由以上红色部分可知，参与逐位仲裁的位只有仲裁场！！！
那么如果有2个节点具有相同的仲裁场，但是他们的数据场不同，将会发生什么呢？我感觉可能在数据场之间可能会产生位错误（Bit Error）,接收完CRC序列后，可能会发生一个应答错误，或者一个CRC错误。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
