前言
首先，請問大家?guī)讉€小小問題，你清楚：
- AUTOSAR框架下的CAN驅(qū)動關(guān)鍵詞定義嗎？是不是有些總是傻傻分不清楚呢？
- CAN驅(qū)動Mailbox配置過程中有哪些關(guān)鍵配置參數(shù)值得我們注意，防止出現(xiàn)低級錯誤？
- CAN驅(qū)動Mailbox的三種類型Tx Buffer，Tx FIFO，Tx Queue的區(qū)別嗎？
今天，我們來一起探索并回答這些問題。為了便于大家理解，以下是本文的主題大綱：
正文
CAN驅(qū)動作為一個在日常開發(fā)項目中經(jīng)常接觸到的重要驅(qū)動模塊，AUTOSAR組織對CAN Driver有著十分全面而準(zhǔn)確的實現(xiàn)要求與相關(guān)關(guān)鍵詞參數(shù)的定義。
經(jīng)常發(fā)現(xiàn)大家在開發(fā)過程中總是會忽略或者混淆這些模塊的關(guān)鍵詞的定義，導(dǎo)致最終雙方在溝通過程中存在很多的誤解，在開發(fā)過程中也會存在諸多不必要的失誤與bug的產(chǎn)生，因此本文小T將帶領(lǐng)大家一起來了解AUTOSAR框架的CAN Driver一些十分重要的關(guān)鍵詞解釋以及難以理解的基本概念，助力我們?nèi)粘９ぷ髦械腃AN驅(qū)動開發(fā)。
小T未來會繼續(xù)更新該AUTOSAR詞典專欄，該詞典將會講解有關(guān)AUTOSAR框架下難以理解或者容易混淆的基本概念與相關(guān)重要知識點，像“百科詞典”一樣幫助大家查漏補缺，助力大家高效完成基于AUTOSAR的軟件開發(fā)，歡迎大家多多關(guān)注與轉(zhuǎn)發(fā)該專欄。
CAN 驅(qū)動關(guān)鍵詞定義
小T通過學(xué)習(xí)AUTOSAR CAN Driver標(biāo)準(zhǔn)文檔，并結(jié)合自身實戰(zhàn)經(jīng)驗，將CAN Driver模塊的關(guān)鍵詞定義整理如下表所示：
CAN 驅(qū)動Mailbox關(guān)鍵配置參數(shù)
在底層MCAL CAN Driver配置過程中總是會存在許多容易混淆的關(guān)鍵配置參數(shù)，該類參數(shù)如果配置有誤，有些時候就會出現(xiàn)讓人費解的問題與bug，因此為了能夠減小這類問題的出現(xiàn)，小T結(jié)合自身實戰(zhàn)經(jīng)驗一起來學(xué)習(xí)下CAN驅(qū)動中關(guān)鍵配置參數(shù)的定義與相關(guān)注意事項。
Hardware Object
如上述表格中所述， 一個Hardware Object就是一個CAN L-PDU的buffer，用來存儲僅一個CAN ID Message，你將可以將其理解為就是我們常說的Mailbox，該Mailbox就是CAN 控制器硬件上的一個物理buffer空間，用來存儲用于發(fā)送或者接收的一個CAN ID Message，該CAN ID Message自然就是包含CAN ID，DLC， Data三個部分。
HOH，HTH，HRH三者區(qū)別與聯(lián)系
為了更好地理解HOH，HTH，HRH三者的區(qū)別，小T將三者的區(qū)別與聯(lián)系整理如下表所示：
CanHwObjectCount
該參數(shù)按照AUTOSAR官方文檔中的定義，表示的就是Hardware Object中的數(shù)目，不過需要注意的是該參數(shù)面向的對象是HOH，即HRH或者HTH。
該參數(shù)表示是否為該HOH配置了FIFO機制，如果數(shù)目為1，則并沒有FIFO進行緩存數(shù)據(jù)，如果大于1，那么就是為該HOH配置了FIFO的數(shù)據(jù)緩存機制，這種緩存機制對于防止CAN接收或者發(fā)送的重要報文丟失至關(guān)重要。
如下圖所示便展示了CanHwObjectCount在HOH中的配置：
2.CanHwObjectCount在HOH中的接收配置
- 如上圖1所示，可以知道該HOH為發(fā)送類型的HOH，因此就直接可以理解為HTH，那么該HTH中定義了參數(shù)CanHwObjectCount的值為1，表示不存在FIFO機制，僅是一個唯一的buffer，如果數(shù)據(jù)發(fā)送或者接收比較頻繁，意味著新數(shù)據(jù)可能來不及發(fā)送；
- 如上圖2所示，可以知道該HOH為接收類型的HOH，因此就直接可以理解為HRH，那么該HRH中定義了參數(shù)CanHwObjectCount的值為2，表示存在深度為2的FIFO機制，如果數(shù)據(jù)發(fā)送或者接收比較頻繁，至少存在深度為2的FIFO緩存空間來防止重要數(shù)據(jù)的丟失。
Full CAN與Basic CAN
在MCAL CAN Driver中的Full CAN與Basic CAN是用來修飾HOH的類型參數(shù)，該參數(shù)可以通過CanObejctType進行定義。
Full CAN：一般表示僅存在1個的Hardware Object與之對應(yīng)，且該Full CAN類型的Hardware Object與特定的CAN ID Message綁定；
Basic CAN：一般表示存在1個或者多個的Hardware Object與之對應(yīng)，且該Basic CAN類型的Hardware Object與非特定的CAN ID Message或者一定范圍內(nèi)的CAN ID Message綁定；
注意事項：
- 對于Basic Can類型的HOH 一般建議通過配置硬件過濾器來實現(xiàn)底層無關(guān)CAN Message的數(shù)據(jù)接收或者特定范圍內(nèi)的報文接收，減少不必要的硬件中斷，也就從某種程度上降低了CPU負載；
- 當(dāng)硬件資源較為充足且無需過多考慮新數(shù)據(jù)可能覆蓋老數(shù)據(jù)的場景，一般推薦將HOH配置成FULL CAN類型。
- 在HOH的配置過程中，一般情況下均需要先將FULL CAN類型的HOH統(tǒng)一配置在前，Basic CAN類型的HOH配置在后，否則容易造成生成的代碼中Maibox使用錯亂的情況。
推薦配置方案
小T結(jié)合實戰(zhàn)經(jīng)驗，將軟件開發(fā)過程中常見的四類報文類型：應(yīng)用報文，網(wǎng)絡(luò)管理報文，診斷報文，Xcp報文的發(fā)送與接收的mailbox配置方案總結(jié)如下表所示：
推薦配置方案總結(jié)如下：
- 診斷報文由于屬于重要報文，丟失與發(fā)送均不允許丟失且存在嚴格的時序關(guān)系，因此發(fā)送與接收均推薦Basic CAN+FIFO 來設(shè)置；
- Xcp報文發(fā)送與接收都是特定ID的報文，因此發(fā)送與接收均推薦Full CAN+Buffer來設(shè)置；
- 應(yīng)用報文在mailbox硬件充足的前提下，發(fā)送與接收優(yōu)先采用Full CAN+Buffer來設(shè)置，如果硬件資源不夠的話，那么推薦采用Basic CAN+FIFO來配置；
- 網(wǎng)絡(luò)管理報文接收一般是一定范圍的報文，因此接收推薦采用Basic CAN+Buffer來配置，發(fā)送由于ID確定，因此推薦采用Full Can+Buffer來設(shè)置；
- 所有報文的發(fā)送與接收配置完成之后，一定要確保所有配置HOH中的CanHwObjectCount加起來的mailbox發(fā)送與接收數(shù)目分別不能超過芯片手冊規(guī)定的發(fā)送mailbox與接收mailbox硬件資源總和。
CAN 驅(qū)動硬件Buffer類型
了解了上述CAN驅(qū)動推薦方案之后，我們接下來需要進一步探究下對于can controller硬件資源內(nèi)部對于用于存儲CAN L-PDU的buffer是如何定義的？
一般來講，現(xiàn)在市面上主流的CAN Controller對于其硬件資源按照發(fā)送與接收可以分為如下幾種類型Buffer：
- 發(fā)送硬件Buffer類型：Tx Buffer，Tx FIFO，Tx Queue；
- 接收硬件Buffer類型Rx Buffer，Rx FIFO；
接下來將針對每種硬件Buffer類型分別進行講解：
Tx Buffer
Tx Buffer又名Dedicated Tx Buffer，該Buffer會與特定的CAN ID進行綁定，發(fā)送優(yōu)先級是完全通過CAN ID越小，優(yōu)先級越高，高優(yōu)先級優(yōu)先發(fā)送；
一般該Tx Buffer會配置HOH的CanObejctType類型為Full CAN模式。
Tx FIFO
上文中說的FIFO機制實際上在硬件底層可以分為兩種，一種是Tx FIFO，另外一種就是Tx Queue，因為兩種本身都是一種緩存空間。
Tx FIFO顧名思義就是按照“先進先出”的方式來進行發(fā)送，忽略CAN ID優(yōu)先級，一般為了防止出現(xiàn)優(yōu)先級反轉(zhuǎn)現(xiàn)象，不建議使用FIFO模式。
Tx Queue
Tx Queue 作為FIFO機制的一種，與Tx FIFO本身有所不同的是放置新的Message發(fā)送請求時按照先后順序來放置，但是發(fā)送時則與Tx Buffer機制一樣，按照高優(yōu)先級優(yōu)先發(fā)送原則，即CAN ID越小，優(yōu)先級越高，如果存在多個同樣CAN ID的報文需要發(fā)送，那么數(shù)字小的Buffer ID號先發(fā)送。
除了上述單一的發(fā)送模式之外，絕大多數(shù)情況可能存在上述組合模式，組合模式下特別需要注意的是外發(fā)報文優(yōu)先級的判定：
Tx Buffer + Tx FIFO模式
如上圖可知，每次發(fā)送優(yōu)先級按照如下方式進行判定：
- 取出Dedicated Tx Buffer中的最小CAN ID發(fā)送請求；
- 取出Tx FIFO中最老的CAN ID發(fā)送請求；
- 比較上述Tx Buffer與Tx FIFO分別取出的CAN ID發(fā)送請求，兩者之間的CAN ID越小的發(fā)送請求優(yōu)先發(fā)送。
Tx Buffer + Tx Queue模式
如上圖可知，每次發(fā)送優(yōu)先級按照如下方式進行判定：
- 取出Dedicated Tx Buffer中的最小CAN ID發(fā)送請求；
- 取出Tx Queue中最小CAN ID發(fā)送請求；
- 比較上述Tx Buffer與Tx Queue分別取出的CAN ID發(fā)送請求，兩者之間的CAN ID越小的發(fā)送請求優(yōu)先發(fā)送。
Rx Buffer
Rx Buffer與Tx Buffer同理， 一般都是與特定的CAN ID進行綁定，一般該Rx Buffer均會配置HOH的CanObejctType類型為Full CAN模式，如果此時老的數(shù)據(jù)CPU還沒有處理完，新的數(shù)據(jù)將不會得到處理。
Rx FIFO
Rx FIFO典型的就是按照“先進先出”的方式進行CAN報文的接收處理，一般而言，Rx FIFO都會存在兩個，一個是Rx FIFO0，另外一個是Rx FIFO1，這個根據(jù)實際情況進行選擇。
同時Rx FIFO如果存在Full的情況，那么有如下兩種處理方式：
- Blocking Mode：表示如果FIFO已經(jīng)滿了，只有等到數(shù)據(jù)處理完成之后才可以放入新的數(shù)據(jù)，一般推薦使用該方式；
- Overwrite Mode：表示如果FIFO已經(jīng)滿了，新來的數(shù)據(jù)可以覆蓋掉最老的數(shù)據(jù)，如果采用OverWrite方式，需要確保獲取數(shù)據(jù)時與接收數(shù)據(jù)時不會存在數(shù)據(jù)一致性問題。
轉(zhuǎn)自汽車電子與軟件
