前言
上一期，我们详细介绍了 CAN 的物理层、波特率、采样点、Bit Timing 以及仲裁机制。
很多朋友留言问：
既然经典 CAN 最快只有 1Mbps，现在越来越多车型开始使用 CAN FD，它到底快在哪里？BRS 又是什么？
今天，我们就把 CAN FD 一次讲透。
-
为什么需要 CAN FD？
经典 CAN 从诞生到今天已经用了几十年。
它最大的优点：
- 成熟
- 稳定
- 成本低
- 抗干扰能力强
但是它也有两个天然瓶颈：
① 数据长度太小
经典 CAN：
Data Length
0 ~ 8 Bytes
很多现代 ECU：
一次要发送：
- Camera状态
- Radar状态
- OTA信息
- 诊断数据
- ADAS信息
8 Byte 根本不够。
必须拆很多 Frame。
效率很低。
② 波特率太低
经典 CAN：
125k
250k
500k
1Mbps
对于 OTA、诊断刷写、日志上传：
速度明显不足。
于是：
CAN FD 出现了。
图1：CAN vs CANFD:数据长度对比
-
CAN FD 到底比 CAN 多了什么？
最大的两个升级：
✅ 更大的 Payload
Classic CAN
8 Bytes
↓
CAN FD
12
16
20
24
32
48
64 Bytes
最大：
64 Byte。
直接提升 8 倍。
第二个升级：
Data Phase 可以高速发送。
例如：
Arbitration
500kbps
但是：
Data Phase
2Mbps
5Mbps
8Mbps
甚至更高。
这也是 CAN FD 名字的来源：
Flexible Data-rate
即：
可变数据速率。
-
CAN FD 最大的秘密：仲裁和数据分开了
这是理解 CAN FD 最重要的一张图。
CAN FD Frame
————————————————————>
Arbitration Control Data CRC
500k 500k 5M 5M
注意：
真正高速的：
只有：
Data + CRC。
前面的：
ID 仲裁阶段。
仍然保持：
经典 CAN 速度。
为什么？
因为：
仲裁必须保证：
所有 ECU 都能正确看到总线状态。
速度太高：
传播延迟就会导致仲裁失败。
所以：
仲裁：
慢。
数据：
快。
兼顾：
可靠性 + 性能。
图2：CAN FD 帧结构(Frame Format)
-
什么叫 BRS（Bit Rate Switch）？
很多 AUTOSAR 配置里：
都会看到：
BRS = TRUE
新人经常不知道什么意思。
其实非常简单：
BRS：
就是：
Bit Rate Switch（波特率切换）。
可以理解成：
500k
↓↓↓
5Mbps
Frame 发送过程中：
自动切换速度。
例如：
开始发送
↓
ID仲裁
500k
↓
BRS位置
↓↓↓↓↓
切换
5Mbps
↓
Data
CRC
↓
结束
↓
恢复500k
整个过程：
完全自动完成。
-
如果关闭 BRS 会怎样？
例如：
CAN FD
BRS = OFF
那么：
虽然：
Payload：
仍然可以：
64 Byte
但是：
速度：
不会提高。
整个 Frame：
一直：
500kbps。
即：
ID
500k
Control
500k
Data
500k
CRC
500k
所以：
CAN FD：
≠ 高速
真正高速：
来自：
BRS。
图3：BRS波特率切换时序图
-
为什么不能一开始就直接 5Mbps 仲裁？
很多新人都会问：
既然都支持 5Mbps。
为什么：
仲裁不用？
原因非常简单：
原因1：传播延迟
例如：
ECU1 —————- ECU2
30m
信号：
需要传播时间。
如果：
Bit：
只有：
200ns。
可能：
ECU2 还没收到。
ECU1 已经采样结束。
仲裁立即错误。
原因2：Bit Arbitration 要求一致
CAN 最经典：
0 覆盖 1
要求：
所有 ECU：
同一时刻：
看到：
一致 Bus Level。
高速：
很难保证。
所以：
保持经典速度。
最安全。
-
CAN FD 为什么 CRC 更复杂？
经典 CAN：
CRC：
15 Bit。
CAN FD：
Payload：
最大：
64 Byte。
如果：
还用原来 CRC。
误检率会上升。
因此：
CAN FD：
根据 Payload：
自动使用：
CRC17
CRC21
可靠性更高。
-
为什么 CAN FD 的效率提升远不止 8 倍？
很多人觉得：
Data：
8 Byte
↓
64 Byte
只是：
8 倍。
实际上：
效率提升更大。
原因：
Frame Header：
几乎不用增加。
例如：
以前：
Frame1
Header
8Byte
CRC
发送：
8 次：
需要：
Header ×8
CRC ×8
现在：
一次：
Header
64Byte
CRC
Header：
一次。
CRC：
一次。
Bus 利用率大幅提高。
OTA、Flash Programming 提升尤其明显。
图4：经典CAN与CANFD总线利用率对比
-
AUTOSAR 中 CAN FD 是如何配置的？
对于做 BSW 的工程师来说：
真正关心的是：
CanDrv。
例如：
很多配置工具：
可以看到：
CanControllerFdBaudrate
5000000
以及：
CanControllerBaudrate
500000
对应：
Arbitration
500k
和：
Data
5M
另外：
还能配置：
Data Sample Point
80%
75%
87.5%
以及：
Nominal Sample Point
分别对应：
仲裁阶段。
数据阶段。
很多人第一次看到：
Nominal Bit Timing
Data Bit Timing
觉得特别复杂。
其实一句话：
就是：
Nominal
↓
仲裁速度
Data
↓
高速阶段
理解以后：
CanDrv 配置就简单很多。
图5：AUTOSAR CanDrv 配置示意图
-
实际项目中最容易踩的坑
① BRS 配置不一致
ECU：
BRS ON
另一端：
BRS OFF
直接通信失败。
② Data BaudRate 不一致
例如：
ECU A
5Mbps
ECU B
2Mbps
结果：
CRC Error。
Error Frame。
Bus Error。
③ Sample Point 配置错误
特别 Data Phase：
更敏感。
高速：
EMI 更容易影响。
④ Transceiver 不支持 CAN FD
很多老型号：
只能：
Classic CAN。
即使 MCU 支持：
仍无法通信。
⑤ 线束设计不合理
Data Phase：
5Mbps：
对：
PCB
Stub Length
Connector
EMC
要求更高。
很多项目：
软件没问题。
真正问题：
在线束。
-
CAN FD 能完全替代以太网吗？
答案：
不能。
CAN FD 最大优势：
✅ 实时性高
✅ 成本低
✅ 仲裁机制成熟
✅ 控制类数据可靠
但是：
Camera：
Gbps
Radar：
大量 Point Cloud
OTA：
大文件
日志：
DLT
都越来越依赖 Automotive Ethernet。
未来汽车网络的发展趋势基本已经形成：
图6：现代汽车网络架构:Ethernet+CANFD+LIN
未来几年：
最典型架构就是：
"以太网 + CAN FD + LIN" 共存。
写在最后
CAN FD 并不是推翻经典 CAN，而是在保留其可靠仲裁机制的基础上，通过 BRS（Bit Rate Switch） 将数据阶段提速，实现了更高带宽、更长 Payload、更高通信效率。
对于 AUTOSAR 开发工程师来说，真正理解 Nominal Bit Timing、Data Bit Timing、BRS、Sample Point、CRC17/CRC21，远比会配置几个参数更重要。
🚗 一句话总结：
CAN FD 的核心思想只有一句话：仲裁保持可靠，数据高速传输；经典 CAN 保留稳定性，BRS 释放带宽潜力。
👉下期预告
《AUTOSAR中的CanIf到底在干什么？为什么它是CanDrv和Com之间最重要的一层？》
下一期，我们正式进入 AUTOSAR CAN 软件栈，从 CanDrv、CanIf、PduR、Com 的数据流开始，一步一步讲清楚整条 CAN 通信链路。
