CAN驅(qū)動Mailbox配置過程中有哪些關(guān)鍵配置參數(shù)值得我們注意？

正文

CAN驅(qū)動作為一個在日常開發(fā)項目中經(jīng)常接觸到的重要驅(qū)動模塊，AUTOSAR組織對CAN Driver有著十分全面而準確的實現(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ā)。

CAN 驅(qū)動關(guān)鍵詞定義

小T通過學(xué)習(xí)AUTOSAR CAN Driver標準文檔，并結(jié)合自身實戰(zhàn)經(jīng)驗，將CAN Driver模塊的關(guān)鍵詞定義整理如下表所示：

CAN 驅(qū)動關(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)系整理如下表所示：

HTH,HRH,HOH三者區(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中的配置：

1.CanHwObjectCount在HOH中的發(fā)送配置

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負載；

當硬件資源較為充足且無需過多考慮新數(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é)如下表所示：

CAN Mailbox的四類報文推薦配置方案推薦配置方案總結(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ù)一致性問題；

審核編輯：劉清