前言首先，請問大家幾個小小問題，你清楚：
今天，我們來一起探索并回答這些問題。為了便于大家理解，以下是本文的主題大綱：  正文CAN驅動作為一個在日常開發項目中經常接觸到的重要驅動模塊，AUTOSAR組織對CAN Driver有著十分全面而準確的實現要求與相關關鍵詞參數的定義。 經常發現大家在開發過程中總是會忽略或者混淆這些模塊的關鍵詞的定義，導致最終雙方在溝通過程中存在很多的誤解，在開發過程中也會存在諸多不必要的失誤與bug的產生，因此本文小T將帶領大家一起來了解AUTOSAR框架的CAN Driver一些十分重要的關鍵詞解釋以及難以理解的基本概念，助力我們日常工作中的CAN驅動開發。 小T未來會繼續更新該AUTOSAR詞典專欄，該詞典將會講解有關AUTOSAR框架下難以理解或者容易混淆的基本概念與相關重要知識點，像“百科詞典”一樣幫助大家查漏補缺，助力大家高效完成基于AUTOSAR的軟件開發，歡迎大家多多關注與轉發該專欄。 CAN 驅動關鍵詞定義小T通過學習AUTOSAR CAN Driver標準文檔，并結合自身實戰經驗，將CAN Driver模塊的關鍵詞定義整理如下表所示：  CAN 驅動Mailbox關鍵配置參數在底層MCAL CAN Driver配置過程中總是會存在許多容易混淆的關鍵配置參數，該類參數如果配置有誤，有些時候就會出現讓人費解的問題與bug，因此為了能夠減小這類問題的出現，小T結合自身實戰經驗一起來學習下CAN驅動中關鍵配置參數的定義與相關注意事項。 Hardware Object 如上述表格中所述， 一個Hardware Object就是一個CAN L-PDU的buffer，用來存儲僅一個CAN ID Message，你將可以將其理解為就是我們常說的Mailbox，該Mailbox就是CAN 控制器硬件上的一個物理buffer空間，用來存儲用于發送或者接收的一個CAN ID Message，該CAN ID Message自然就是包含CAN ID，DLC， Data三個部分。 HOH，HTH，HRH三者區別與聯系 為了更好地理解HOH，HTH，HRH三者的區別，小T將三者的區別與聯系整理如下表所示：  CanHwObjectCount 該參數按照AUTOSAR官方文檔中的定義，表示的就是Hardware Object中的數目，不過需要注意的是該參數面向的對象是HOH，即HRH或者HTH。 該參數表示是否為該HOH配置了FIFO機制，如果數目為1，則并沒有FIFO進行緩存數據，如果大于1，那么就是為該HOH配置了FIFO的數據緩存機制，這種緩存機制對于防止CAN接收或者發送的重要報文丟失至關重要。 如下圖所示便展示了CanHwObjectCount在HOH中的配置：  
Full CAN與Basic CAN 在MCAL CAN Driver中的Full CAN與Basic CAN是用來修飾HOH的類型參數，該參數可以通過CanObejctType進行定義。 Full CAN：一般表示僅存在1個的Hardware Object與之對應，且該Full CAN類型的Hardware Object與特定的CAN ID Message綁定； Basic CAN：一般表示存在1個或者多個的Hardware Object與之對應，且該Basic CAN類型的Hardware Object與非特定的CAN ID Message或者一定范圍內的CAN ID Message綁定； 注意事項：
推薦配置方案 小T結合實戰經驗，將軟件開發過程中常見的四類報文類型：應用報文，網絡管理報文，診斷報文，Xcp報文的發送與接收的mailbox配置方案總結如下表所示：  推薦配置方案總結如下：
CAN 驅動硬件Buffer類型了解了上述CAN驅動推薦方案之后，我們接下來需要進一步探究下對于can controller硬件資源內部對于用于存儲CAN L-PDU的buffer是如何定義的？ 一般來講，現在市面上主流的CAN Controller對于其硬件資源按照發送與接收可以分為如下幾種類型Buffer：
接下來將針對每種硬件Buffer類型分別進行講解： Tx Buffer Tx Buffer又名Dedicated Tx Buffer，該Buffer會與特定的CAN ID進行綁定，發送優先級是完全通過CAN ID越小，優先級越高，高優先級優先發送； 一般該Tx Buffer會配置HOH的CanObejctType類型為Full CAN模式。 Tx FIFO 上文中說的FIFO機制實際上在硬件底層可以分為兩種，一種是Tx FIFO，另外一種就是Tx Queue，因為兩種本身都是一種緩存空間。 Tx FIFO顧名思義就是按照“先進先出”的方式來進行發送，忽略CAN ID優先級，一般為了防止出現優先級反轉現象，不建議使用FIFO模式。 Tx Queue Tx Queue 作為FIFO機制的一種，與Tx FIFO本身有所不同的是放置新的Message發送請求時按照先后順序來放置，但是發送時則與Tx Buffer機制一樣，按照高優先級優先發送原則，即CAN ID越小，優先級越高，如果存在多個同樣CAN ID的報文需要發送，那么數字小的Buffer ID號先發送。 除了上述單一的發送模式之外，絕大多數情況可能存在上述組合模式，組合模式下特別需要注意的是外發報文優先級的判定： Tx Buffer Tx FIFO模式  如上圖可知，每次發送優先級按照如下方式進行判定：
Tx Buffer Tx Queue模式  如上圖可知，每次發送優先級按照如下方式進行判定：
Rx Buffer Rx Buffer與Tx Buffer同理， 一般都是與特定的CAN ID進行綁定，一般該Rx Buffer均會配置HOH的CanObejctType類型為Full CAN模式，如果此時老的數據CPU還沒有處理完，新的數據將不會得到處理。 Rx FIFO Rx FIFO典型的就是按照“先進先出”的方式進行CAN報文的接收處理，一般而言，Rx FIFO都會存在兩個，一個是Rx FIFO0，另外一個是Rx FIFO1，這個根據實際情況進行選擇。 同時Rx FIFO如果存在Full的情況，那么有如下兩種處理方式：
|
|
|
