1. CANFD技术概述：从CAN2.0到CANFD的演进

大家好，我是你们的嵌入式讲师。今天咱们来聊聊CANFD。说实话，我最早接触CAN总线是在十年前做车载项目的时候，那时候用的还是CAN2.0B。后来有一次客户要求传输一批固件升级包，数据量大了，CAN2.0那8个字节的载荷让我折腾了好几个通宵。嗯，从那以后我就特别关注CANFD的发展。

1.1 从CAN2.0到CANFD：为什么非要升级？

先说说CAN2.0。它诞生于上世纪90年代，设计初衷是让汽车里的各个ECU能互相说上话。1Mbps的速率、8字节的数据场，在当时看来绰绰有余。但你想想看，现在的智能汽车里有多少个传感器？摄像头、激光雷达、高精地图……每个都在往外吐数据。

我举个例子。一个普通的CAN2.0报文，假设ID占11位，控制场、CRC这些加起来，有效数据占比其实很低。你发8个字节的数据，实际在总线上要占用一百多个位的时间。说白了，效率不高。

CANFD的出现，就是为了解决这个痛点。它保留了CAN2.0的物理层和总线仲裁机制，但在数据段做了两件事：跑得更快、装得更多。

1.2 CANFD核心优势：速率提升与数据场扩展

咱们一个一个说。

速率提升

CANFD在数据段采用了更灵活的位时序。仲裁段还是用原来的速率（比如500kbps），但一旦进入数据段，它会切换到高速模式。我在项目中实测过，STM32的CANFD外设在5Mbps下跑得很稳，8Mbps也能跑，但要注意线缆长度和终端匹配。

为什么会这样？因为CANFD在数据段使用了更短的位时间。你想想看，仲裁段需要保证所有节点都能正确采样，所以位时间不能太短。但数据段是单节点发送，其他节点只负责接收，这时候就可以把速率提上去。

数据场扩展

从8字节到64字节，这个提升是实打实的。我做过一个电池管理系统的项目，每个电池模组的状态信息大概有40个字节。用CAN2.0得拆成5帧发送，还要自己拼包、做序号管理。换成CANFD后，一帧搞定。

这里有个细节要注意：CANFD的数据场虽然扩展到了64字节，但并不是所有应用都需要用满。我个人习惯是，根据实际数据量选择合适的数据长度。比如传输诊断数据，可能16字节就够了；传输固件升级包，那就直接上64字节。

特性	CAN2.0	CANFD
最大数据场	8字节	64字节
数据段速率	最高1Mbps	最高8Mbps+
有效载荷效率	约40%	约70%
CRC算法	15位CRC	17/21位CRC（可选）

1.3 CANFD与CAN2.0兼容性分析

这个问题我经常被问到。答案是：部分兼容，但不是完全兼容。

CANFD的物理层和CAN2.0完全一样，都是差分信号、显性隐性电平。所以从硬件上看，CANFD节点可以和CAN2.0节点挂在同一条总线上。但是，CANFD的报文格式和CAN2.0不一样。

具体来说：

• CANFD的帧格式中，控制场里多了一个EDL位（Extended Data Length），用来标识这是CANFD帧
• CANFD的CRC算法不同，使用了17位或21位CRC
• CANFD的数据段速率可以切换

所以，如果你把一个CANFD节点和一个CAN2.0节点放在同一条总线上，CANFD节点发送CANFD帧时，CAN2.0节点会报错。因为CAN2.0不认识EDL位，它会认为这是一个格式错误。

那怎么解决兼容性问题呢？有三种方案：

1. 纯CANFD网络：所有节点都支持CANFD，发挥最大性能
2. 混合网络：CANFD节点配置为"兼容模式"，只发送CAN2.0帧，但可以接收CANFD帧（如果不需要接收，那就更简单了）
3. 网关桥接：用一个CANFD节点做网关，一边接CANFD网络，一边接CAN2.0网络，做协议转换

我个人比较推荐第三种方案。因为混合网络虽然省钱，但调试起来很麻烦。你想想看，CANFD节点在高速模式下发送数据，CAN2.0节点虽然不参与，但总线上有高速信号，对CAN2.0节点的共模抑制能力是个考验。

1.4 小结

好了，这一章的内容就到这里。总结一下：

• CANFD从CAN2.0演进而来，解决了速率和载荷的瓶颈
• 核心优势是数据段速率提升（最高8Mbps+）和数据场扩展（64字节）
• 与CAN2.0部分兼容，混用时需要特别注意帧格式和物理层设计

下一章，我会带大家看看STM32的CANFD外设到底长什么样，以及怎么配置它。到时候我会拿一个实际的项目代码出来，咱们一行一行地分析。嗯，敬请期待。