一、CAN总线基础：从物理层到仲裁机制

各位同学，咱们今天聊聊CAN总线。说实话，搞嵌入式Linux网关开发，CAN总线是绕不开的坎。我在项目里见过太多人，驱动死活调不通，最后发现是连CAN的基本原理都没吃透。嗯，咱们就从根上捋一遍。

1.1 CAN协议概述——为什么是CAN？

CAN（Controller Area Network）是德国Bosch公司上世纪80年代搞出来的。初衷很简单——汽车里线束太多，又重又容易出故障，能不能用两根线把所有的ECU串起来？

结果呢？CAN不仅做到了，还成了工业、机器人、医疗设备的事实标准。我个人习惯把CAN比作一个“智能会议室”：谁有话要说，直接开口，没人抢就继续说；有人同时开口，级别高的自动留下，级别低的闭嘴退让。这个机制，咱们后面细讲。

1.2 CAN物理层特性——两根线上的门道

CAN物理层用的是差分信号。说白了，就是两根线（CAN_H和CAN_L）上的电压差来决定逻辑0还是逻辑1。

咱们看个具体数值：

信号状态	CAN_H电压	CAN_L电压	差分电压
显性（逻辑0）	3.5V	1.5V	2.0V
隐性（逻辑1）	2.5V	2.5V	0V

这里有个关键点：显性电平会“覆盖”隐性电平。你想想看，只要有一个节点拉低总线，整个总线就是显性。这就是CAN仲裁的物理基础。

CAN的通信速率和总线长度有关系。速率越高，总线就得越短。比如1Mbps时，总线长度一般不超过40米；降到125kbps，可以拉到500米左右。这个在项目布线时要提前想好。

1.3 CAN数据帧结构——报文里藏着什么？

CAN的数据帧，我习惯把它拆成几个部分来看。咱们以最常用的标准帧（11位ID）为例：

帧起始(1bit) | 仲裁场(12bit) | 控制场(6bit) | 数据场(0~8byte) | CRC场(16bit) | 应答场(2bit) | 帧结束(7bit)

拆开来看：

• 帧起始（SOF）： 1个显性位，告诉所有人“我要发数据了”
• 仲裁场： 11位ID + RTR位。ID越小，优先级越高
• 控制场： IDE位 + 保留位 + DLC（数据长度，0~8）
• 数据场： 最多8字节。为什么是8？早期设计时觉得够用，现在嘛……有时候确实不够
• CRC场： 15位CRC + 1位定界符，校验数据完整性
• 应答场： 接收节点在ACK槽拉低，告诉发送方“我收到了”
• 帧结束： 7个隐性位，收工

除了数据帧，CAN还有远程帧（请求数据）、错误帧（出错了通知大家）、过载帧（忙不过来，等等）。不过日常开发中，数据帧占了95%以上的通信量。

1.4 CAN总线仲裁机制——谁先说话？

这个机制是CAN最精妙的设计。多个节点同时发送时，怎么决定谁先发？

答案是：逐位仲裁，ID小的赢。

过程是这样的：

1. 所有想发送的节点同时发出帧起始位（显性）
2. 然后逐位发出自己的ID
3. 每个节点在发送位的同时，监听总线电平
4. 如果自己发的是隐性（1），但总线上是显性（0），说明有更高优先级的节点在发——自己立刻退出
5. 剩下的节点继续，直到只剩一个

你想想看，这个过程完全是分布式的，不需要中央调度器。而且仲裁不损失任何带宽——赢的节点继续发完整帧，输的节点等总线空闲再重试。

为什么会这样设计？因为显性位（0）覆盖隐性位（1）。ID越小，前面0越多，在仲裁中就越占优势。嗯，就是这么简单粗暴。

下面这张图把CAN的核心知识体系串起来了：

这张图把CAN的四个核心知识点串在了一起。从中心向外展开，每个分支下面还有关键子项。你调试的时候，遇到问题就对着这张图排查——物理层查电阻和电平，数据帧查ID和CRC，仲裁查优先级设计。我自己的经验是，90%的CAN通信问题都能在这四个方向里找到根因。