第2章：CAN总线基础回顾

各位同学好，我是老张。做汽车电子测试十几年了，CAN总线就像我的老朋友。今天咱们聊聊CAN总线的基础知识。别觉得基础就简单，很多问题恰恰出在基础上。

2.1 CAN协议帧结构

CAN总线上的数据，是以“帧”为单位传输的。就像寄快递，你得有个包裹，包裹上写地址、贴标签。CAN帧也一样，有固定的格式。

CAN帧主要分四种：数据帧、远程帧、错误帧、过载帧。咱们平时打交道最多的，是数据帧。

数据帧长什么样？我画个简图给你看：

SOF | 仲裁场 | 控制场 | 数据场 | CRC场 | ACK场 | EOF

每个字段都有它的作用：

• SOF（帧起始）：一个显性位，告诉总线“我要发数据了”。
• 仲裁场：包含11位（标准帧）或29位（扩展帧）的ID。ID越小，优先级越高。我遇到过一个问题，两个节点同时发数据，结果ID小的那个抢到了总线，另一个只能等。这就是仲裁。
• 控制场：包含数据长度码（DLC），告诉别人我这帧里有多少字节数据。DLC范围是0-8。
• 数据场：0-8字节的实际数据。说白了，这就是你要传的信息。
• CRC场：循环冗余校验，检查数据有没有传错。
• ACK场：应答场。接收节点收到数据后，会在这里发一个显性位，告诉发送方“我收到了”。
• EOF（帧结束）：7个隐性位，表示帧结束。

2.2 CAN报文收发原理

CAN总线是广播式的。什么意思？就是所有节点都能收到总线上发的每一帧数据。但节点只处理自己关心的帧。

收发原理其实不复杂：

1. 发送：节点把数据封装成帧，然后往总线上发。如果多个节点同时发，就仲裁。仲裁失败的节点自动转为接收模式，等总线空闲再重发。
2. 接收：节点不断监听总线。收到一帧后，先检查ID是不是自己关心的。如果是，就收下；如果不是，就丢弃。
3. 错误处理：如果节点发现数据有错（比如CRC校验失败），它会发一个错误帧。发送节点收到错误帧后，会重发数据。

嗯，这里要注意：CAN总线的错误处理机制很强大。我曾经在项目里遇到总线被某个节点“拉死”的情况，就是因为那个节点不停发错误帧。排查了好久才发现是它的晶振频率偏了。

2.3 CAN数据库（DBC）文件解析

DBC文件，说白了就是CAN总线的“翻译官”。它告诉工具：报文里每个bit代表什么含义。

一个典型的DBC文件包含：

• 报文定义：报文的ID、长度、发送节点、接收节点。
• 信号定义：信号的名字、起始位、长度、字节序（Intel/Motorola）、数据类型（有符号/无符号）、缩放因子、偏移量、物理范围。
• 值表：枚举类型的信号，比如0代表关闭，1代表开启。

举个例子，一个车速信号的定义可能是这样的：

SG_ VehicleSpeed : 8|16@1+ (0.01,0) [0|655.35] "km/h"  ECU

我来拆解一下：

• VehicleSpeed：信号名字
• 8|16：起始位是8，长度是16位
• @1+：Intel字节序，无符号数
• (0.01,0)：缩放因子0.01，偏移量0
• [0|655.35]：物理范围0到655.35 km/h
• "km/h"：单位

你想想看，如果没有DBC文件，你看到一串十六进制数，根本不知道它代表什么。有了DBC，工具就能自动把原始数据转换成物理值。

2.4 CAN信号与报文映射

信号和报文的关系，就像信封和信纸。一个报文（信封）里可以装多个信号（信纸）。

信号在报文里的排列方式，取决于字节序和起始位：

• Intel格式：低字节在前，高字节在后。起始位是信号的最低有效位（LSB）。
• Motorola格式：高字节在前，低字节在后。起始位是信号的最高有效位（MSB）。

举个例子，一个16位的信号，值0x1234：

字节序	低字节（Byte0）	高字节（Byte1）
Intel	0x34	0x12
Motorola	0x12	0x34

我个人习惯，在CANoe里用“Signal”窗口查看信号值，用“Trace”窗口看原始报文。两个窗口对照着看，能快速判断DBC解析是否正确。

还有一个常见问题：信号跨字节。比如一个12位的信号，从第4位开始，跨了Byte0和Byte1。这时候字节序就很重要了。Intel格式下，低字节的4位是信号的低4位，高字节的8位是信号的高8位。Motorola格式则相反。

好了，这一章的内容就这些。CAN总线基础虽然简单，但它是后续所有测试工作的基石。下一章，咱们聊聊CANoe的安装和配置，到时候我会分享一些我踩过的坑。