第3章 CAN总线仲裁机制

第3章：CAN总线仲裁机制——位仲裁原理、优先级判定、非破坏性仲裁

好，咱们今天聊聊CAN总线里最核心、也最巧妙的一个机制——仲裁。

说实话，我刚接触CAN的时候，最让我着迷的就是这个仲裁机制。你想想看，多节点同时往总线上发数据，居然不会冲突，还能自动分出谁先谁后。这在其他总线里几乎是不可能的。我当年在搞一个弹载数据采集系统时，就因为这个机制，省掉了一大堆复杂的调度逻辑。

3.1 为什么需要仲裁？

CAN总线是共享介质的。所有节点都挂在两根线上（CAN_H和CAN_L）。如果两个节点同时开始发送，信号就会在总线上叠加。如果没有仲裁机制，数据就全乱了。

但CAN的设计者很聪明。他们搞了一套“非破坏性位仲裁”机制。说白了，就是让优先级高的节点继续发，优先级低的节点自动退出发送。整个过程不会破坏任何数据。

嗯，这里要注意：仲裁只在总线空闲时，多个节点同时开始发送的情况下才会发生。如果总线正在传输，其他节点只能乖乖等着。

3.2 位仲裁原理——线与逻辑

仲裁的基础是“线与”逻辑。CAN总线有两种状态：显性（Dominant）和隐性（Recessive）。

显性电平：逻辑0，CAN_H比CAN_L高约2V。它能覆盖隐性电平。
隐性电平：逻辑1，CAN_H和CAN_L电压差接近0V。它会被显性电平覆盖。

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

我在项目中遇到过一个问题：有个节点总线上老是出现莫名其妙的错误帧。查了半天，发现是某个节点的CAN收发器坏了，一直输出显性电平，把整个总线都拉死了。这就是“线与”逻辑的副作用——一个坏节点能拖垮整个网络。

核心要点：仲裁时，每个节点都会同时发送自己的标识符（ID），并监听总线电平。如果自己发的是隐性（1），但总线上是显性（0），说明有更高优先级的节点在发数据。自己就立刻停止发送，转为接收模式。

3.3 优先级判定——ID就是优先级

CAN的优先级由标识符（ID）决定。ID越小，优先级越高。因为ID的高位先发送，显性位（0）越多，越早占据总线。

举个例子：

节点	ID（二进制）	优先级
节点A	0001 0101	最高（高位全是0）
节点B	0010 0011	中等
节点C	0100 0110	最低

假设三个节点同时开始发送。第一位，A发0，B发0，C发0。总线是0，大家继续。第二位，A发0，B发0，C发1。总线是0（因为A和B的0覆盖了C的1）。C发现自己发了1但总线是0，立刻退出仲裁。第三位，A发0，B发1。总线是0，B退出。最后A赢得仲裁，继续发送剩余数据。

整个过程，A的数据没有受到任何破坏。这就是“非破坏性”的含义。

个人经验：我建议在设计系统时，把实时性要求高的消息（比如舵机控制、发动机点火）分配小ID。把状态监测、日志记录等非关键消息分配大ID。我曾经在一个项目中，把火控指令的ID设成了0x001，把温度传感器的ID设成了0x7FF。结果火控指令永远优先，哪怕总线负载率到了90%，关键指令也能准时送达。

3.4 非破坏性仲裁的细节

非破坏性仲裁有几个关键点，我当年踩过坑，跟大家分享一下。

3.4.1 仲裁场

CAN标准帧的仲裁场包括：

SOF（帧起始）：1位显性，同步所有节点。
ID（标识符）：标准帧11位，扩展帧29位。
RTR（远程传输请求位）：数据帧为显性（0），远程帧为隐性（1）。

注意：RTR位也会参与仲裁。数据帧的优先级高于远程帧。因为数据帧的RTR是0，远程帧是1。0能覆盖1。

3.4.2 仲裁失败后的行为

节点在仲裁中失败后，会立刻停止发送，并转为接收模式。它不会重试，而是等待下一次总线空闲。这个“立刻停止”很重要。如果节点反应慢了，就可能破坏正在传输的数据。

我曾经调试过一个国产CAN控制器，发现它在仲裁失败后，居然还多发了两个位。结果就是总线错误，所有节点都进入了总线关闭状态。后来换了芯片才解决。所以，选型时一定要关注控制器的仲裁响应时间。

避坑指南：我曾经在一个项目中，把两个节点的ID设成了相同的值。结果两个节点同时赢得仲裁，同时发送数据，总线直接乱套。CAN协议要求每个节点的ID必须唯一。如果ID重复，仲裁机制就失效了。设计时一定要做好ID分配表，避免冲突。

3.5 仲裁与实时性

CAN的仲裁机制天然支持实时性。高优先级消息总能抢占总线。但这也带来一个问题：如果高优先级消息太多，低优先级消息可能永远发不出去。这叫“优先级反转”或“饿死”。

我建议的做法是：

给每个消息分配一个最大发送周期。如果超时未发送，就临时提高它的优先级（通过改变ID或使用特殊机制）。
使用CAN的“时间触发”模式（如TTCAN），在固定时间槽内发送消息，避免优先级竞争。
在弹载系统中，关键消息（如制导指令）的ID要预留足够小的值。非关键消息（如自检结果）可以容忍延迟。

3.6 代码示例：仲裁过程模拟

下面是一个简单的C语言模拟，展示仲裁过程：

// 模拟CAN仲裁过程
#include <stdio.h>

// 节点结构体
typedef struct {
    unsigned int id;      // 11位ID
    int is_transmitting;  // 是否正在发送
} CAN_Node;

// 仲裁函数
int arbitrate(CAN_Node *nodes, int num_nodes) {
    int winner = -1;
    int bus_level = 1;  // 隐性电平
    
    // 逐位仲裁（从高位到低位）
    for (int bit = 10; bit >= 0; bit--) {
        bus_level = 1;  // 假设总线为隐性
        
        // 每个节点发送当前位
        for (int i = 0; i < num_nodes; i++) {
            if (nodes[i].is_transmitting) {
                int bit_value = (nodes[i].id >> bit) & 0x01;
                // 显性位（0）覆盖隐性位（1）
                if (bit_value == 0) {
                    bus_level = 0;
                }
            }
        }
        
        // 检查每个节点是否退出仲裁
        for (int i = 0; i < num_nodes; i++) {
            if (nodes[i].is_transmitting) {
                int my_bit = (nodes[i].id >> bit) & 0x01;
                // 我发了1但总线是0，说明有更高优先级节点
                if (my_bit == 1 && bus_level == 0) {
                    nodes[i].is_transmitting = 0;  // 退出仲裁
                    printf("节点 %d 在bit %d 退出仲裁\n", i, bit);
                }
            }
        }
    }
    
    // 找到获胜者
    for (int i = 0; i < num_nodes; i++) {
        if (nodes[i].is_transmitting) {
            winner = i;
            break;
        }
    }
    
    return winner;
}

int main() {
    CAN_Node nodes[3] = {
        {0x155, 1},  // ID: 0001 0101 0101
        {0x223, 1},  // ID: 0010 0010 0011
        {0x446, 1}   // ID: 0100 0100 0110
    };
    
    int winner = arbitrate(nodes, 3);
    if (winner >= 0) {
        printf("节点 %d 赢得仲裁，ID = 0x%03X\n", winner, nodes[winner].id);
    } else {
        printf("没有节点赢得仲裁\n");
    }
    
    return 0;
}

这个代码模拟了11位ID的逐位仲裁过程。你运行一下就能看到，ID最小的节点（0x155）最终获胜。

3.7 总结与建议

CAN的仲裁机制，说白了就是“谁小谁先走”。这个机制简单、高效、非破坏性。在弹载系统中，它保证了关键指令的实时性。

我个人习惯在设计初期就做好ID分配表。把ID分成几个区间：

0x000 - 0x0FF：紧急指令（火控、制导）
0x100 - 0x3FF：实时数据（姿态、速度）
0x400 - 0x7FF：非实时数据（温度、电压）

这样，即使总线负载很高，紧急指令也能第一时间通过。嗯，这就是CAN仲裁的魅力所在。

📚 课程目录