2. CAN总线基础：从物理层到错误处理
各位同学，今天我们来聊聊CAN总线。说实话，CAN总线在汽车电子领域就像空气一样无处不在。我做OBD数据采集这些年，几乎每天都在跟它打交道。你想想看，一辆现代汽车里可能有几十个ECU，它们之间怎么通信？靠的就是CAN总线。
这一章我会从最底层的物理层讲起，一直聊到错误处理。嗯，内容不少，但都是干货。我建议你跟着我的思路走，别跳着看。
2.1 CAN总线物理层：信号怎么在线上跑
CAN总线物理层，说白了就是决定信号怎么在两根线上传输的规则。我刚开始接触CAN时，总觉得这东西很玄乎。后来拆了几个ECU，拿着示波器一量，其实没那么复杂。
CAN总线用两根线：CAN_H和CAN_L。它采用差分信号传输。什么是差分信号？就是两根线上的电压差来表示逻辑状态。
- 显性电平（Dominant）：CAN_H比CAN_L高约2V。此时总线电压差约为2V。逻辑上代表"0"。
- 隐性电平（Recessive）：CAN_H和CAN_L电压几乎相等（约2.5V）。电压差接近0V。逻辑上代表"1"。
关键点：显性电平会"覆盖"隐性电平。也就是说，只要有一个节点发送显性电平，总线就呈现显性状态。这个特性是CAN总线仲裁机制的基础。
我在项目中遇到过一个问题：某次测试时，CAN总线突然通信中断。查了半天，发现是CAN_H和CAN_L线接反了。嗯，这种低级错误，犯过一次就再也不会犯了。
CAN总线的终端电阻也很重要。标准要求两端各接一个120Ω电阻。为什么？为了消除信号反射。我记得有次在实验室，忘了接终端电阻，结果总线上的波形乱七八糟，数据根本收不到。
| 参数 | 高速CAN（ISO 11898-2） | 低速CAN（ISO 11898-3） |
|---|---|---|
| 最大速率 | 1 Mbps | 125 kbps |
| 总线长度（1 Mbps时） | 约40米 | 约500米 |
| 终端电阻 | 120Ω（两端） | 不需要 |
| 显性电平差 | 约2V | 约1.5V |
我的经验：做OBD数据采集时，建议使用高速CAN。因为OBD-II标准要求500 kbps的速率。低速CAN虽然抗干扰能力强，但速率太低，不适合实时数据采集。
2.2 CAN总线数据帧结构：报文长什么样
CAN总线上的数据以"帧"为单位传输。最常见的帧类型是数据帧。我刚开始看CAN帧结构时，觉得挺复杂。其实你把它拆开看，就几个关键部分。
一个标准CAN数据帧（11位ID）包含以下字段：
- SOF（Start of Frame）：1位显性电平，表示帧开始。
- 仲裁场：11位标识符（ID）+ 1位RTR位。ID决定了消息的优先级。
- 控制场：6位，包含IDE位、保留位和DLC（数据长度码）。
- 数据场：0-8字节，实际要传输的数据。
- CRC场：15位CRC校验码 + 1位CRC界定符。
- ACK场：2位，用于确认接收。
- EOF（End of Frame）：7位隐性电平，表示帧结束。
为什么会设计成这种结构？说白了，就是为了保证可靠性和实时性。我举个例子，CRC校验能检测出传输错误，ACK机制能确保消息被正确接收。
扩展帧（29位ID）：除了标准帧，还有扩展帧。扩展帧的ID有29位，可以支持更多节点。但说实话，在OBD数据采集中，标准帧已经够用了。我很少见到OBD-II用扩展帧的。
// CAN数据帧结构示例（标准帧）
// 假设我们要发送一个OBD请求：读取发动机转速
// ID: 0x7DF（OBD请求的广播ID）
// DLC: 8（数据长度）
// Data: 02 01 0C 00 00 00 00 00
// 帧结构如下：
// SOF: 0（显性）
// ID: 011 1110 1111（0x7DF）
// RTR: 0（数据帧）
// IDE: 0（标准帧）
// 保留位: 00
// DLC: 1000（8字节）
// Data: 00000010 00000001 00001100 00000000 ...
// CRC: 15位校验码
// ACK: 1位应答 + 1位界定符
// EOF: 1111111（7位隐性）避坑指南：我曾经在解析CAN数据时，忽略了DLC字段。结果数据长度不对，解析出来的值全是错的。记住，DLC告诉你有多少字节是有效数据，别把后面的填充字节也当成数据。
2.3 CAN总线仲裁机制：谁先说话
CAN总线是多主总线。什么意思？就是多个节点可以同时发送数据。那问题来了：如果两个节点同时发送，总线会不会乱套？
不会。CAN总线有仲裁机制。说白了，就是通过ID来比大小。ID越小，优先级越高。
仲裁过程是这样的：
- 所有节点同时发送SOF位（显性）。
- 然后逐位发送ID。每个节点在发送的同时，监听总线电平。
- 如果某个节点发送了隐性电平（1），但总线上是显性电平（0），说明有更高优先级的节点在发送。这个节点立即停止发送，转为接收模式。
- 最终，ID最小的节点赢得仲裁，继续发送剩余数据。
你想想看，这个机制有多巧妙。不需要额外的仲裁线，不需要中央调度器，全靠电气特性自动完成。我每次想到这个设计，都觉得发明CAN总线的人真是个天才。
重要结论：在OBD数据采集系统中，请求帧的ID通常为0x7DF（优先级较低），而响应帧的ID为0x7E8-0x7EF（优先级较高）。这意味着ECU的响应比请求更重要，能优先发送。
我在项目中遇到过一个问题：多个ECU同时响应OBD请求时，会不会冲突？答案是：不会。因为每个ECU的响应ID不同（0x7E8对应ECU1，0x7E9对应ECU2...），仲裁机制会自动处理优先级。
2.4 CAN总线错误处理：出错了怎么办
CAN总线最让我佩服的一点，就是它的错误处理机制。说实话，汽车环境很恶劣，电磁干扰、温度变化、振动，都可能让数据传输出错。但CAN总线能保证数据可靠性，靠的就是这套错误处理机制。
CAN总线定义了5种错误类型：
- 位错误（Bit Error）：发送节点发送的电平与监听到的电平不一致。
- 填充错误（Stuff Error）：连续6个相同电平，违反了位填充规则。
- CRC错误（CRC Error）：接收节点计算的CRC与发送的CRC不一致。
- 格式错误（Form Error）：帧格式不符合规范。
- ACK错误（ACK Error）：发送节点没有收到ACK应答。
为什么会设计这么多错误类型？说白了，就是为了精确定位问题。我记得有次调试，发现总线上一直接收到错误帧。用CAN分析仪一看，是CRC错误。再查，发现是某个ECU的晶振频率偏移了。嗯，这种问题，没有错误类型分类，根本查不出来。
CAN总线的错误处理还有一个厉害的地方：错误计数和状态转换。每个节点都有两个计数器：
- TEC（发送错误计数器）
- REC（接收错误计数器）
根据计数器的值，节点会进入三种状态：
| 状态 | 条件 | 行为 |
|---|---|---|
| 错误主动（Error Active） | TEC < 128 且 REC < 128 | 正常发送和接收，检测到错误时发送主动错误帧 |
| 错误被动（Error Passive） | TEC > 127 或 REC > 127 | 可以发送和接收，但检测到错误时只发送被动错误帧 |
| 总线关闭（Bus Off） | TEC > 255 | 完全断开与总线的连接，不再发送任何数据 |
警告：我曾经遇到过一个问题：某个ECU频繁发送错误帧，导致整个CAN总线通信瘫痪。查了半天，发现是那个ECU的CAN控制器出了问题，TEC一直增加，最终进入总线关闭状态。但问题是，它进入总线关闭前，已经严重影响了其他节点的通信。
所以，我的建议是：在设计OBD数据采集系统时，一定要监控总线的错误帧数量。如果发现某个节点频繁出错，及时隔离它，别让它拖垮整个系统。
错误帧的结构也很简单：
- 主动错误帧：6位显性电平（错误标志）+ 8位隐性电平（错误界定符）。
- 被动错误帧：6位隐性电平（错误标志）+ 8位隐性电平（错误界定符）。
你想想看，主动错误帧的6位显性电平，会破坏正在传输的正常帧。所有节点检测到这个错误后，都会丢弃当前帧，然后重新发送。这就是CAN总线的"出错重传"机制。
我的经验：在OBD数据采集系统中，建议开启CAN控制器的自动重传功能。这样，当发生错误时，硬件会自动重传，不需要软件干预。但要注意，如果错误频繁发生，重传会占用大量总线带宽。这时候，你需要检查总线物理层是否有问题。
好了，这一章的内容就到这里。CAN总线的基础知识，说白了就是物理层怎么传信号、数据帧长什么样、仲裁怎么比大小、错误怎么处理。这些内容，你在做OBD数据采集时，几乎每天都会用到。下一章，我们会聊OBD协议的具体实现，包括PID、诊断服务这些内容。