|
对于车载控制器来说，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 任务中打来实锤。 如果是这种，从问题角度来看，就是降负载，或者调高任务或者中断的优先级。更深层次来看，就是系统设计有问题，导致基本的报文发送波动，需要从系统层面优化。 以上就是一些简单的经验梳理总结，有问题的地方大家可以在留言指正。 |
|
|
