對于車載控制器來說，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 任務中打來實錘。

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

審核編輯：劉清