对于车载控制器来说,CAN周期的波动通常是有严格的标准,国标要求如下,基于国标,各个主机厂在这一块稍微有些差异,不过大部分要求是不超过10%,比如10ms的报文,周期波动范围是9~11ms。
▲图1 GBT 34658-2017中要求
那如果遇到报文周期偏大的问题该从何下手,或者说有哪些解决办法呢?
首先来梳理一下CAN报文的发送流程,CAN通信协议栈的整体架构如下图所示,包括应用层,交互层,网络层,数据链路层,物理层。
▲图2 CAN通信从应用层到硬件的流程(来源CSDN)
从各层的交互接口来看,报文接收polling接收方式的流程如下图所示。
Can_MainFunction_Read函数周期调用访问CanController(硬件)的寄存器,并读取这些寄存器的数据;数据读取结束后,继续调用CAN Interface模块的CanIf_RxIndication函数,将数据传给CanIf模块;CanIf再调用PduR模块的PduR_RxIndication函数,将数据传到PduR模块;PduR模块路由到COM模块,调用Com_RxIndication函数,将数据传到COM模块,COM模块将会把数据存入其缓存,供应用层软件读取使用。
如果是CAN报文的接收采用的是中断方式,数据则是在中断中接收,并调用 CanIf_RxIndication将数据向上传递。
▲图3 CAN报文接收流程
报文发送流程如下图所示。通过Com_ManfunctionTx将数据一层一层传递到CAN模块,并且通过Polling或者中断的形式将数据发送出去。
▲图4 CAN报文发送流程
上述基本梳理了一下CAN报文收发的流程,那下面就来分析一下总线报文周期波动过大问题的可能问题点。
第一种可能是同一节点发送报文很多,并且大部分报文周期都相同,这就导致同一时刻,大量报文需要发送,导致报文发送阻塞。如果是这种情况的话,可以在Com层对报文的发送增加offset,offset一般是Com周期的倍速,这里可以适当地调低Com Mainfunction的周期。
第二种可能就是需要检查Canif和CAN是否大量报文发送仅使用一个发送缓冲区,并且采用FIFO的方式进出,这样就会出现报文周期波动,其影响的原因是,假如大CANID的报文在前,小CANID的报文在后,大ID由于总线仲裁,无法发送,会导致小CANID的无法发送,从现象来看就是报文优先就翻转。
▲图4 内部优先级翻转
这里还可以从总线log来分析,查看小CANID周期间隔点,发送的报文是哪些,如果那会儿大ID在发,那就有可能是这种原因。
第三种有可能系统负载的原因,比如系统负载过高,导致Com_MainFuncionTx的调度发生波动,导致总线上报文周期波动,或者是以中断的模式发送,中断优先级过低,导致被其他高优先级的中断打断,导致报文无法发送,这里可以通过打时间戳的形式来确认,在任务中打时间搓或者是在idle 任务中打来实锤。
如果是这种,从问题角度来看,就是降负载,或者调高任务或者中断的优先级。更深层次来看,就是系统设计有问题,导致基本的报文发送波动,需要从系统层面优化。