QA1：CAN報文發(fā)送，有優(yōu)先級嗎？

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

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

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

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

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

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

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

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

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

假設：CAN BUS上有兩個節(jié)點：ECU1::CAN1和ECU2::CAN1，ECU1::CAN1使用Tx FIFO緩存待發(fā)送數(shù)據(jù)，ECU2::CAN1使用Dedicated Tx Buffers方式緩存待發(fā)送數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

審核編輯：劉清