4. CAN总线仲裁机制：线与逻辑、仲裁过程、ID优先级决定

大家好，我是你们的讲师。今天我们来聊聊CAN总线里一个非常核心的机制——仲裁。说实话，很多工程师做CAN开发好几年，对收发数据很熟练，但真要问一句“总线冲突时到底怎么解决的”，往往就卡住了。

我刚开始接触CAN的时候，也犯过糊涂。那时候我调试一个多节点系统，总线上时不时丢帧，查了半天找不到原因。后来才发现，是我对仲裁的理解不够深，ID分配出了问题。嗯，今天咱们就把这块彻底讲透。

4.1 为什么需要仲裁？

CAN总线是共享介质。多个节点挂在同一对双绞线上，谁都能发数据。那问题来了——如果两个节点同时往总线上发数据，会怎样？

你想想看，如果A节点发“1”，B节点发“0”，总线上的电平到底是多少？

这就引出了CAN总线的一个关键设计：线与逻辑。

4.2 线与逻辑：显性位与隐性位

CAN总线有两种电平状态：

• 显性位（Dominant）：逻辑0，差分电压约2V。它能“覆盖”隐性位。
• 隐性位（Recessive）：逻辑1，差分电压约0V。它会被显性位覆盖。

说白了，就是“0”比“1”强势。只要有一个节点发0，总线就是0。所有节点都发1，总线才是1。

我在项目中遇到过一种情况：某个节点因为硬件故障，一直往总线上发显性位，结果整个网络都瘫痪了。这就是“总线锁死”现象。所以，仲裁机制虽然强大，但硬件可靠性同样重要。

4.3 仲裁过程：逐位对决

CAN的仲裁发生在帧起始（SOF）之后，控制场之前，具体来说就是仲裁场（11位标准ID或29位扩展ID + RTR位）。

过程是这样的：

1. 所有准备发送的节点，同时往总线上发送自己的ID位。
2. 每个节点在发送每一位后，都会回读总线电平。
3. 如果自己发的是隐性位（1），但读到的是显性位（0），说明有更高优先级的节点在发0。
4. 这个节点立即退出仲裁，转为接收状态。
5. 剩下的节点继续发送下一位，直到只剩一个节点胜出。

整个过程是无损的——胜出的节点继续发送完整报文，失败的节点自动退出发送，不会破坏总线数据。

4.4 ID优先级决定：数字越小，优先级越高

CAN的ID本身没有优先级属性，但仲裁机制让数值最小的ID拥有最高优先级。

为什么？因为ID是从高位到低位逐位发送的。数值小的ID，高位出现0的位置更早，所以能更快地“压制”其他节点。

举个例子：

节点	ID（二进制）	ID（十进制）	仲裁结果
节点A	000 0101 0101	0x055	胜出
节点B	000 0110 0110	0x066	失败
节点C	000 1000 1000	0x088	失败

你看，节点A的ID是0x055，节点B是0x066。从第6位开始，A发0，B发1，A胜出。节点C的ID更大，更早退出。

4.5 扩展帧仲裁：29位ID的较量

CAN 2.0B引入了扩展帧，ID长度从11位变成了29位。仲裁过程更复杂一些：

• 标准帧的仲裁场：11位ID + RTR位
• 扩展帧的仲裁场：11位基础ID + SRR位 + IDE位 + 18位扩展ID + RTR位

关键点在于：标准帧的优先级高于扩展帧。因为标准帧在IDE位发显性位（0），而扩展帧发隐性位（1）。

所以，如果你在混合系统中，标准帧总能“抢”在扩展帧前面发送。

4.6 仲裁机制流程图

下面这张图展示了两个节点同时发送时的仲裁过程。我特意把关键节点和判断逻辑画了出来，方便你理解。

4.7 仲裁相关的几个关键点

最后，我总结几个实际开发中容易忽略的点：

• RTR位也参与仲裁：数据帧的RTR位是显性（0），远程帧是隐性（1）。所以数据帧优先级高于远程帧。
• 扩展帧的SRR位：扩展帧在SRR位发隐性（1），标准帧在对应位发显性（0）。所以标准帧永远优先。
• 仲裁不占用额外时间：仲裁和ID发送是同时进行的，没有额外开销。
• 总线负载越高，仲裁越频繁：当总线利用率超过70%时，仲裁冲突会明显增加。我建议你留出30%的余量。