前言
首先，請問大家幾個小小問題，你清楚：
- AUTOSAR框架下的CAN驅動關鍵詞定義嗎？是不是有些總是傻傻分不清楚呢？
- CAN驅動Mailbox配置過程中有哪些關鍵配置參數值得我們注意，防止出現低級錯誤？
- CAN驅動Mailbox的三種類型Tx Buffer，Tx FIFO，Tx Queue的區別嗎？
今天，我們來一起探索并回答這些問題。為了便于大家理解，以下是本文的主題大綱：
正文
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中的配置：
2.CanHwObjectCount在HOH中的接收配置
- 如上圖1所示，可以知道該HOH為發送類型的HOH，因此就直接可以理解為HTH，那么該HTH中定義了參數CanHwObjectCount的值為1，表示不存在FIFO機制，僅是一個唯一的buffer，如果數據發送或者接收比較頻繁，意味著新數據可能來不及發送；
- 如上圖2所示，可以知道該HOH為接收類型的HOH，因此就直接可以理解為HRH，那么該HRH中定義了參數CanHwObjectCount的值為2，表示存在深度為2的FIFO機制，如果數據發送或者接收比較頻繁，至少存在深度為2的FIFO緩存空間來防止重要數據的丟失。
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綁定；
注意事項：
- 對于Basic Can類型的HOH 一般建議通過配置硬件過濾器來實現底層無關CAN Message的數據接收或者特定范圍內的報文接收，減少不必要的硬件中斷，也就從某種程度上降低了CPU負載；
- 當硬件資源較為充足且無需過多考慮新數據可能覆蓋老數據的場景，一般推薦將HOH配置成FULL CAN類型。
- 在HOH的配置過程中，一般情況下均需要先將FULL CAN類型的HOH統一配置在前，Basic CAN類型的HOH配置在后，否則容易造成生成的代碼中Maibox使用錯亂的情況。
推薦配置方案
小T結合實戰經驗，將軟件開發過程中常見的四類報文類型：應用報文，網絡管理報文，診斷報文，Xcp報文的發送與接收的mailbox配置方案總結如下表所示：
推薦配置方案總結如下：
- 診斷報文由于屬于重要報文，丟失與發送均不允許丟失且存在嚴格的時序關系，因此發送與接收均推薦Basic CAN+FIFO 來設置；
- Xcp報文發送與接收都是特定ID的報文，因此發送與接收均推薦Full CAN+Buffer來設置；
- 應用報文在mailbox硬件充足的前提下，發送與接收優先采用Full CAN+Buffer來設置，如果硬件資源不夠的話，那么推薦采用Basic CAN+FIFO來配置；
- 網絡管理報文接收一般是一定范圍的報文，因此接收推薦采用Basic CAN+Buffer來配置，發送由于ID確定，因此推薦采用Full Can+Buffer來設置；
- 所有報文的發送與接收配置完成之后，一定要確保所有配置HOH中的CanHwObjectCount加起來的mailbox發送與接收數目分別不能超過芯片手冊規定的發送mailbox與接收mailbox硬件資源總和。
CAN 驅動硬件Buffer類型
了解了上述CAN驅動推薦方案之后，我們接下來需要進一步探究下對于can controller硬件資源內部對于用于存儲CAN L-PDU的buffer是如何定義的？
一般來講，現在市面上主流的CAN Controller對于其硬件資源按照發送與接收可以分為如下幾種類型Buffer：
- 發送硬件Buffer類型：Tx Buffer，Tx FIFO，Tx Queue；
- 接收硬件Buffer類型Rx Buffer，Rx FIFO；
接下來將針對每種硬件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模式
如上圖可知，每次發送優先級按照如下方式進行判定：
- 取出Dedicated Tx Buffer中的最小CAN ID發送請求；
- 取出Tx FIFO中最老的CAN ID發送請求；
- 比較上述Tx Buffer與Tx FIFO分別取出的CAN ID發送請求，兩者之間的CAN ID越小的發送請求優先發送。
Tx Buffer + Tx Queue模式
如上圖可知，每次發送優先級按照如下方式進行判定：
- 取出Dedicated Tx Buffer中的最小CAN ID發送請求；
- 取出Tx Queue中最小CAN ID發送請求；
- 比較上述Tx Buffer與Tx Queue分別取出的CAN ID發送請求，兩者之間的CAN ID越小的發送請求優先發送。
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的情況，那么有如下兩種處理方式：
- Blocking Mode：表示如果FIFO已經滿了，只有等到數據處理完成之后才可以放入新的數據，一般推薦使用該方式；
- Overwrite Mode：表示如果FIFO已經滿了，新來的數據可以覆蓋掉最老的數據，如果采用OverWrite方式，需要確保獲取數據時與接收數據時不會存在數據一致性問題。
轉自汽車電子與軟件
