對于車載控制器來說，CAN周期的波動通常是有嚴格的標準，國標要求如下，基于國標，各個主機廠在這一塊稍微有些差異，不過大部分要求是不超過10%，比如10ms的報文，周期波動范圍是9~11ms。

▲圖1?GBT 34658-2017中要求

那如果遇到報文周期偏大的問題該從何下手，或者說有哪些解決辦法呢？

首先來梳理一下CAN報文的發(fā)送流程，CAN通信協(xié)議棧的整體架構(gòu)如下圖所示，包括應用層，交互層，網(wǎng)絡層，數(shù)據(jù)鏈路層，物理層。

▲圖2?CAN通信從應用層到硬件的流程(來源CSDN)

從各層的交互接口來看，報文接收polling接收方式的流程如下圖所示。

Can_MainFunction_Read函數(shù)周期調(diào)用訪問CanController（硬件）的寄存器，并讀取這些寄存器的數(shù)據(jù)；數(shù)據(jù)讀取結(jié)束后，繼續(xù)調(diào)用CAN Interface模塊的CanIf_RxIndication函數(shù)，將數(shù)據(jù)傳給CanIf模塊；CanIf再調(diào)用PduR模塊的PduR_RxIndication函數(shù)，將數(shù)據(jù)傳到PduR模塊；PduR模塊路由到COM模塊，調(diào)用Com_RxIndication函數(shù)，將數(shù)據(jù)傳到COM模塊，COM模塊將會把數(shù)據(jù)存入其緩存，供應用層軟件讀取使用。

如果是CAN報文的接收采用的是中斷方式，數(shù)據(jù)則是在中斷中接收，并調(diào)用?CanIf_RxIndication將數(shù)據(jù)向上傳遞。

▲圖3?CAN報文接收流程

報文發(fā)送流程如下圖所示。通過Com_ManfunctionTx將數(shù)據(jù)一層一層傳遞到CAN模塊，并且通過Polling或者中斷的形式將數(shù)據(jù)發(fā)送出去。

▲圖4?CAN報文發(fā)送流程

上述基本梳理了一下CAN報文收發(fā)的流程，那下面就來分析一下總線報文周期波動過大問題的可能問題點。

第一種可能是同一節(jié)點發(fā)送報文很多，并且大部分報文周期都相同，這就導致同一時刻，大量報文需要發(fā)送，導致報文發(fā)送阻塞。如果是這種情況的話，可以在Com層對報文的發(fā)送增加offset，offset一般是Com周期的倍速，這里可以適當?shù)卣{(diào)低Com Mainfunction的周期。

第二種可能就是需要檢查Canif和CAN是否大量報文發(fā)送僅使用一個發(fā)送緩沖區(qū)，并且采用FIFO的方式進出，這樣就會出現(xiàn)報文周期波動，其影響的原因是，假如大CANID的報文在前，小CANID的報文在后，大ID由于總線仲裁，無法發(fā)送，會導致小CANID的無法發(fā)送，從現(xiàn)象來看就是報文優(yōu)先就翻轉(zhuǎn)。

▲圖4?內(nèi)部優(yōu)先級翻轉(zhuǎn)

這里還可以從總線log來分析，查看小CANID周期間隔點，發(fā)送的報文是哪些，如果那會兒大ID在發(fā)，那就有可能是這種原因。

第三種有可能系統(tǒng)負載的原因，比如系統(tǒng)負載過高，導致Com_MainFuncionTx的調(diào)度發(fā)生波動，導致總線上報文周期波動，或者是以中斷的模式發(fā)送，中斷優(yōu)先級過低，導致被其他高優(yōu)先級的中斷打斷，導致報文無法發(fā)送，這里可以通過打時間戳的形式來確認，在任務中打時間搓或者是在idle 任務中打來實錘。

如果是這種，從問題角度來看，就是降負載，或者調(diào)高任務或者中斷的優(yōu)先級。更深層次來看，就是系統(tǒng)設計有問題，導致基本的報文發(fā)送波動，需要從系統(tǒng)層面優(yōu)化。

審核編輯：劉清