CAN FD 介绍

随着电动汽车,无人驾驶汽车技术的快速发展,以及对汽车高级驾驶辅助系统和人机交互HMI需求的增加,传统的CAN总线在传输速率带宽等方面越来越显得力不从心,其主要原因如下:

1、通常整车CAN网络负载大大超过推荐值(50%)

2、CAN消息中只有大约40-50%的带宽用于实际数据传输

3、总线速率通常被限制在1Mbit/s,在实际使用中的速度更低,大多数情况下为500Kbit/s;在J1939网络中使用250Kbit/s

4、最大总线速度受响应机制限制,即错误帧,ACK等

5、ACK延迟 = 收发器延迟+总线传播延迟

可见最直接的办法就是使用下一代总线FlexRay,这样可以一劳永逸的解决这一难题。但如果将原来所有的CAN节点全部升级为FlexRay节点,由此会带来巨大的硬件开销,软件通讯移植开发,以及漫漫长的开发周期。人们不禁会共同产生一个统一的想法,那就是 Make CAN fast !

CAN FD 的出现

 

为了缩小CAN网络(Max:1MBit/s)与FlexRay(Max:10MBit/s)网络的带宽差距,BOSCH推出了CAN FD方案。CAN FD(CAN with Flexible Data rate)继承了CAN总线的主要特性。

CAN总线采用双线串行通讯协议,基于非破坏性仲裁技术,分布式实时控制,可靠的错误处理和检测机制使CAN总线有很高的安全性,但CAN总线带宽和数据场长度却受到制约。CAN FD总线弥补了CAN总线带宽和数据场长度的制约,CAN FD总线与CAN总线的区别主要表现在:

 可变速率 

CAN FD采用了两种位速率:从控制场中的BRS位到ACK场之前(含CRC分界符)为可变速率,其余部分为原CAN总线用的速率。两种速率各有一套位时间定义寄存器,它们除了采用不同的位时间单位TQ外,位时间各段的分配比例也可不同。

 CAN FD对数据场的长度作了很大的扩充,DLC最大支持64个字节,在DLC小于等于8时与原CAN总线是一样的,大于8时有一个非线性的增长,所以最大的数据场长度可达64字节

CAN FD 结构

 与普通CAN报文相同,CAN FD报文一共具有,帧起始SOF,仲裁段,控制段,数据域,CRC域,ACK域,帧结束,共七个部分组成。

 CAN与CANFD使用相同的SOF标志位来标志报文的起始。帧起始由单个显性位构成,标志着报文的开始,并在总线上起着同步作用。

与传统CAN相比,CAN FD取消了对远程帧的支持,用RRS位替换了RTR位,为常显性。IDE位仍为标准帧和扩展帧标志位,若标准帧与扩展帧具有相同的前 11 位 ID,那么标准帧将会由于 IDE 位为 0,优先获得总线。

RTR(Remote Transmission Request Bit):远程发送请求位,RER位在数据帧里必须是显性,而在远程帧里为隐性。

RRS(Remote Request Substitution):远程请求替换位,即传统CAN中的RTR位,CAN FD中为常显性。

 

 控制域中CANFD与CAN有着相同的IDE,res,DLC位。同时增加了三个控制bit位,FDF、BRS、ESI。

FDF(Flexible Data Rate Format):原CAN数据帧中的保留位r。FDF常为隐性,表示CAN FD 报文。

BRS( Bit Rate Switch):位速率转换开关,当BRS为显性位时数据段的位速率与仲裁段的位速率一致,当BRS为隐性位时数据段的位速率高于仲裁段的位速率。 

ESI(Error State Indicator):错误状态指示,主动错误时发送显性位,被动错误时发送隐性位。

 

 

 相比于传统CAN,在CAN FD中最多可接受2个位时间有效的ACK,允许1个额外的位时间来补偿收发器相移和传播延迟)。EOF(End of frame)同样由连续7个隐性位来表示。

 CAN FD 特点

CAN FD继承了CAN总线的主要特性,提高了CAN总线的网络通信带宽,改善了错误帧漏检率,同时可以保持网络系统大部分软硬件特别是物理层不变。这种相似性使ECU供应商不需要对ECU的软件部分做大规模修改即可升级汽车通信网络。

 尽管CAN FD继承了绝大部分传统CAN的特性,但从传统CAN升级到CAN FD依旧需要做很多工作:

1、硬件与工具:首先需要选取支持CAN FD的控制器和收发器,还需要采用新的网络调试和监测工具。

2、网络兼容性:对于传统的CAN网段的部分节点升级到CAN FD的情况需要特别注意。CAN FD节点可以正常收发传统CAN报文,但是传统CAN节点不能正确收发CAN FD报文,其原因是帧格式不一致,会导致传统CAN节点发送错误帧。

 基于以上场景,为了解决传统CAN和CAN FD的兼容性问题,芯片厂提出了一种解决方案,在传统CAN节点上采用CAN FD Shield模式的收发器,当收到CAN FD报文时,收发器会将其过滤掉,防止传统CAN节点发出错误帧,从而实现网络的兼容。


参考文献:

1、CAN FD introduction(Vector)

2、CAN with Flexible Data-rate(Bosch)

3、车载网络技术革新-CAN FD浅析(控制工程网)

### CANFD 工具的功能特点及使用介绍 #### 支持CANFD的控制器和收发器 为了实现CANFD功能,硬件层面需要选用支持CANFD协议的CAN控制器和收发器。这些设备能够提供更高的数据传输能力以及更高效的通信性能[^1]。 #### 新型网络调试与监测工具 除了基本的硬件组件外,还需要配备专门用于CANFD网络的调试和监测工具。这类工具有助于开发人员实时监控网络状态、分析数据帧结构并诊断潜在问题。通过这些工具,工程师可以更好地理解网络行为并对系统进行优化。 #### 数据传输增强特性 CANFD相比传统CAN协议有显著改进之处在于其提高了带宽利用率,并允许单个消息携带多达64字节的数据量(而原来仅限于8字节)。此外,它还支持高达12 Mbit/s的速度操作模式,在保持向后兼容性的前提下实现了更快的信息交换过程[^2]。 #### 开源项目推荐——周立功CANFD盒子 对于希望快速搭建起基于CANFD技术平台的应用场景来说,“周立功CANFD盒子”是一个非常实用的选择。“周立功CANFD盒子”提供了完整的解决方案来简化复杂度高的嵌入式系统的开发流程;该项目开源地址为 https://gitcode.com/open-source-toolkit/188da 。此资源不仅包含了详细的文档说明和技术指导,而且还有实际案例供参考学习[^3]。 ```python import canfd def initialize_canfd(): bus = canfd.Bus(channel='can0', bustype='socketcan') message = can.Message(arbitration_id=0x123, data=[0, 1, 2], is_extended_id=False) try: bus.send(message) print("Message sent on {}".format(bus.channel_info)) except can.CanError: print("Message NOT sent") if __name__ == "__main__": initialize_canfd() ``` 上述Python脚本展示了如何利用`canfd`库初始化一个CANFD总线实例并向指定ID发送一条测试消息。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值