3. CAN总线仲裁机制：线与逻辑、仲裁规则、优先级判定、非破坏性仲裁
大家好，我是你们的嵌入式老司机。今天咱们来聊聊CAN总线里最精彩的部分——仲裁机制。
说实话，我刚开始接触CAN的时候，最困惑的就是这个问题：多个节点同时发数据，总线到底听谁的？会不会乱套？
后来我才明白，CAN的仲裁机制设计得相当巧妙。它既不像以太网那样碰撞了就退避重发，也不像RS485那样需要主从轮询。它用一种叫“非破坏性仲裁”的方式，让优先级高的报文“优雅地”赢得总线使用权。
嗯，咱们一步步拆开看。
3.1 线与逻辑：CAN总线的物理基础
要理解仲裁，先得搞明白CAN总线的物理层是怎么工作的。
CAN总线使用两根线——CAN_H和CAN_L，传输两种逻辑状态：显性（Dominant）和隐性（Recessive）。
| 状态 | CAN_H电压 | CAN_L电压 | 差分电压 | 逻辑值 |
|---|---|---|---|---|
| 显性 | 3.5V | 1.5V | 2.0V | 0 |
| 隐性 | 2.5V | 2.5V | 0V | 1 |
关键来了：显性位会覆盖隐性位。这就是所谓的“线与逻辑”——只要有一个节点输出显性（0），总线就是显性；只有所有节点都输出隐性（1），总线才是隐性。
核心记忆点：显性=0，隐性=1。显性“压过”隐性。这是仲裁的物理基础。
我在一个项目中遇到过总线被某个节点“拉死”的情况。排查了半天，发现是那个节点的CAN收发器坏了，一直输出显性位。结果整个网络都瘫痪了。嗯，这就是“线与逻辑”的副作用——一个坏节点能拖垮所有人。
3.2 仲裁规则：谁的数字小，谁先走
仲裁发生在仲裁场（Arbitration Field），也就是标识符（ID）段。标准帧是11位ID，扩展帧是29位ID。
规则其实很简单：ID值越小，优先级越高。
为什么？因为ID的位是从高位到低位逐位比较的。谁先输出显性（0），谁就赢了。
举个例子，两个节点同时发送：
- 节点A：ID = 0x123（二进制：0001 0010 0011）
- 节点B：ID = 0x456（二进制：0100 0101 0110）
从最高位开始比：
- 第1位：A=0，B=0 → 相同，继续
- 第2位：A=0，B=1 → A输出显性，B输出隐性
- 总线被A拉成显性，B检测到“自己发了1但总线是0”
- B立刻退出，转为接收模式
你看，A的ID更小，所以A赢了。
我的经验：设计ID分配时，一定要把最紧急的报文（比如刹车、安全气囊）分配最小的ID。我曾经见过一个团队把诊断报文分配了0x001，结果紧急控制报文反而被堵住了。这设计，你说气不气人？
3.3 非破坏性仲裁：赢了继续发，输了不受伤
这是CAN总线最牛的地方——非破坏性仲裁。
什么意思？就是仲裁过程中，赢的那个节点继续正常发送，输的那个节点自动转为接收，没有任何数据被破坏。
对比一下以太网的CSMA/CD：碰撞了，所有节点都停，发一个拥塞信号，然后随机退避重发。这效率，你想想看，差了多少？
CAN的非破坏性仲裁，本质上是位仲裁（Bit Arbitration）。每个节点在发送每一位时，都会回读总线电平。如果发现自己发的和总线不一致，就知道自己输了。
输了的节点做什么？
- 停止发送后续位
- 转为接收模式
- 等待下一次总线空闲再尝试
赢了的节点呢？继续发完整个报文，完全不受影响。
注意：非破坏性仲裁只适用于数据帧和远程帧。错误帧和过载帧不参与仲裁，它们有更高的优先级。
3.4 仲裁流程图解
光说可能不够直观，我画了一张图，把整个仲裁流程串起来。
3.5 仲裁中的几个关键细节
搞清楚了基本流程，咱们再挖几个坑。这些坑，我当年都踩过。
3.5.1 远程帧的仲裁
远程帧（Remote Frame）也参与仲裁。它的ID和数据帧的ID在同一个空间里。如果数据帧和远程帧的ID相同，数据帧优先级更高——因为远程帧的RTR位是隐性（1），数据帧的RTR位是显性（0）。
我曾经遇到一个bug：某个节点发了远程帧请求数据，但数据节点没响应。查了半天，发现是ID冲突了，远程帧被另一个数据帧“挤掉”了。嗯，ID分配真是个细活。
3.5.2 扩展帧与标准帧的仲裁
扩展帧（29位ID）和标准帧（11位ID）也能共存于同一总线。仲裁时，标准帧的SRR位是显性（0），扩展帧的SRR位是隐性（1）。所以，标准帧的优先级高于扩展帧。
| 帧类型 | ID位数 | SRR位 | 优先级 |
|---|---|---|---|
| 标准数据帧 | 11 | 无 | 最高 |
| 扩展数据帧 | 29 | 隐性(1) | 中等 |
| 标准远程帧 | 11 | 无 | 次高 |
| 扩展远程帧 | 29 | 隐性(1) | 最低 |
我的建议：除非必要，尽量别混用标准帧和扩展帧。混用会增加仲裁复杂度，也容易出问题。我一般在一个项目里只用一种帧格式。
3.5.3 位时序与同步
仲裁依赖精确的位时序。每个节点都有自己的时钟，但必须通过同步机制保持步调一致。
CAN的同步分两种：
- 硬同步：总线从空闲变为忙碌时，所有节点重新同步
- 重同步：在报文传输过程中，根据相位误差调整采样点
如果位时序配置不对，仲裁可能失败。我见过一个案例：某个节点的晶振偏差太大，导致采样点偏移，仲裁时总检测不到总线电平变化。结果那个节点永远抢不到总线，成了“万年老二”。
3.6 仲裁失败场景分析
虽然CAN的仲裁机制很可靠，但也不是万能的。我总结了几种可能出问题的场景：
- ID分配不合理：多个高优先级节点同时发送，低优先级节点永远抢不到总线。这叫“饿死”。
- 总线负载过高：当总线利用率超过80%时，仲裁冲突频繁，低优先级报文延迟剧增。
- 位时序错误：采样点位置不对，导致仲裁位误判。
- 收发器故障：某个节点的收发器损坏，一直输出显性，导致总线“锁死”。
避坑指南：我曾经在一个项目中，把所有的紧急报文ID都分配在0x100-0x1FF范围内。结果有次总线负载一高，这些报文互相打架，低优先级的紧急报文延迟从1ms飙到了50ms。后来我学乖了，给不同优先级留了足够的ID间隔，并且用DLC（数据长度码）来区分同ID的不同消息。
3.7 本章小结
好了，咱们把仲裁机制捋一遍：
- 线与逻辑：显性（0）压过隐性（1），这是物理基础
- 仲裁规则：ID越小优先级越高，逐位比较
- 非破坏性仲裁：赢家继续发，输家自动退，数据不损坏
- 关键细节：远程帧、扩展帧、位时序都会影响仲裁结果
理解仲裁机制，是开发CAN协议栈的第一步。你想想看，如果连总线怎么“抢”都不清楚，后面写驱动、调bug的时候，那可就抓瞎了。