QA1：CAN報文發送，有優先級嗎？

答 ：有。以英飛凌tc3xx系列為例，MCMCAN模塊有多個硬件發送緩沖區，也就是說同一時刻可以緩存多個待發送的報文，這些報文放入待發送的緩沖區以后，會置位發送Pending標志，等待發送，誰先發送呢？在回答這個問題之前，我們先說待發送的報文在硬件緩存區中的存儲方式：Dedicated Tx Buffers 、Tx FIFO、 Tx Queue。

對于Dedicated Tx Buffers與 Tx Queue兩種存儲方式，根據lowest Message ID原則發送，即：發送的CanID數值越小，優先級越高。具體發送順序示例如下：

對于Tx FIFO存儲方式，報文的發送順序由進入FIFO緩存區的先后順序決定，即：先進先出，具體發送順序如下：

如果使用Dedicated Tx Buffers與 Tx Queue兩種存儲方式，優先級低的報文(比如：網絡管理報文、診斷報文、標定報文等，優先級比應用報文低），是不是永遠得不到發送了？不是，我們要清楚：發送的硬件緩存區不止一個，而是多個（比如：tc397有32個發送緩沖區），足以在某一時刻緩存多個待發送的報文。是否存在某一時刻（如下t1），發送報文的個數超過硬件緩存區個數？這種可能性是存在的，這也是為什么會有發送報文丟幀的原因。

為了避免發送丟幀或者周期性報文抖動問題，我們可以將相同周期性報文的發送做一個Offset處理， 避免周期性相同的報文以同一個基準時間計時 。

比如：通信啟動后，周期性報文Msg01(周期10ms)在t0時刻開始周期性發送；而周期性報文Msg02(周期10ms)在t1時刻開始周期性發送，這樣即可避免兩者在某一時刻的發送重疊，如下所示：

QA2：Tx FIFO發送方式可能引發的問題有什么？

答： 對于CAN報文，使用FIFO方式發送，我能想到的場景：診斷中，發送診斷指令使用FIFO緩存，保證診斷指令請求的順序。不知道大家在何種情況下使用過Tx FIFO，還請大家給普及。

這里思考到了一種工況，可能會因使用FIFO發送方式，導致報文的發送延遲，具體如下所示：

假設：CAN BUS上有兩個節點：ECU1::CAN1和ECU2::CAN1，ECU1::CAN1使用Tx FIFO緩存待發送數據，ECU2::CAN1使用Dedicated Tx Buffers方式緩存待發送數據。

在某一時刻，ECU1::CAN1的Buffer Index0待發送報文的CAN ID = 0x30，ECU2::CAN1待發送的6個報文的CAN ID ＜0x30，所以，每次總線仲裁，都會優先發送ECU2::CAN1緩存的報文，而ECU1::CAN1因為總線仲裁失敗，導致ECU1::CAN1 FIFO中的高優先級報文無法及時發送出去，如下所示：

所以，在使用Tx FIFO方式時，需要注意此工況。

QA3：程序應先處理發送報文還是應該先處理接收報文？

答 ：TBD。為什么是未定義呢？在實際的項目開發中，先處理Rx報文還是先處理Tx報文確實沒有明確規定，在項目不出問題之前，沒有人會留意兩者的處理順序。

這里我們討論一下先處理Rx Msg，再處理Tx Msg的情況，實質就是討論Task中，Com_MainFunctionRx()/Com_MainFunctionTx()的處理順序。

假設：Com_MainFunctionRx()/Com_MainFunctionTx()均在5ms的Task中，且先處理Com_MainFunctionRx()，再處理Com_MainFunctionTx()，如果此節點收/發的報文數量不多，任務在規定的時間內處理完（t1時刻之前），不會引發問題，如下所示：

如果當前節點接收的報文數量較多，Com_MainFunctionRx()消耗了任務處理的大部分時間，導致Com_MainFunctionTx()處理被Delay，可能會導致本節點發送報文的周期抖動問題，比如：本來10ms的Tx Msg，由于延遲導致Tx Msg＞10ms + 容差值，假設容差值±10%(1ms)，比如：實際Tx Msg周期13ms，導致通信出問題。

對于一個節點，接收報文數量存在不確定性，比如：接收的報文類型如果有事件性應用報文、高周期應用報文（如：1ms周期性應用報文）等。

那么Com_MainFunctionRx()的處理時間就會存在一定的不確定性。相對于接收報文，節點發送報文的數量相對比較確定，發送所消耗的時間也比較確定，所以，從處理順序上來說， 先處理確定的發送再處理不確定的發送比較合理 ，這樣可以確保發送報文的時間。

而對于接收，即使超一點時間，如果Task沒有超過Deadline Time，對程序的運行也不會造成太大影響。

再者，對于CAN報文，發送報文還需要進行總線仲裁，仲裁失敗也會存在一定的延時（參考QA2）。

注意 ：上述假設OS所使用的基準計數器是可信的，即：基礎計數器準確，一般由GPT或者STM驅動。

QA4:周期型報文Offset的作用是啥？

答： 降低同一時刻，多個發送報文的Burst Send問題。這個問題屬于QA1的延申。

一個節點，發送的報文類型可以有多種（QA1提到）。其中，節點外發的應用報文從幾個到幾十個不等。應用報文又分為事件型、周期型、混合型。以周期型應用報文為例，可能有5ms、10ms、20ms、50ms等周期。

如果本節點外發的報文數量較大，在某一時刻會存在大量并發請求。比如：MsgA Cycle =5ms，MsgB Cycle = 10ms，MsgC Cycle = 10ms，如果MsgA的發送時刻為5ms、10ms、15ms、20ms、25ms、30ms.....MsgB、MsgC的發送時刻為10ms、20ms、30ms.....，在time＝10ms、time＝30ms......等時刻，MsgA 、MsgB、MsgC會同時請求發送，節點要發送的報文數量越多，某一時刻（如下圖time = 10ms 時刻），請求發送的報文數量可能就越多。

在某一時刻，發送報文數量過多會帶來什么問題呢？這就是QA3中的問題，會使得某個發送報文發送延遲，使得其發送周期出現抖動，即：超過該周期報文的允許誤差值，一般來說，≤100ms的周期性應用報文允許的偏差為3％，＞100ms的周期性應用報文允許的偏差為1％(看OEM要求)。

既然應用報文會Burst Send，如何降低這種并發請求行為呢？ 偏移相同周期報文的發送時機 ，比如：MsgBOffset 5 ms，MsgC Offset 10ms，這樣兩者的發送就不會重疊，如下所示：

那偏移不同周期的應用報文有用嗎？因為周期性報文發送取決于Com_MainFunctionTx()所在任務周期，Offset Value = n * Cycle（n為非負整數，Cycle指Com_MainFunctionTx()的任務周期），所以，Offset Value是Com_MainFunctionTx()任務周期的整數倍。

這樣，即使設置MsgA、MsgB的Offset Value不同，也不能避免某一時刻（如：time = 10ms時刻），兩者的并發請求，如下所示：

審核編輯：劉清