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

正文

CAN驅(qū)動(dòng)作為一個(gè)在日常開發(fā)項(xiàng)目中經(jīng)常接觸到的重要驅(qū)動(dòng)模塊，AUTOSAR組織對(duì)CAN Driver有著十分全面而準(zhǔn)確的實(shí)現(xiàn)要求與相關(guān)關(guān)鍵詞參數(shù)的定義。

經(jīng)常發(fā)現(xiàn)大家在開發(fā)過程中總是會(huì)忽略或者混淆這些模塊的關(guān)鍵詞的定義，導(dǎo)致最終雙方在溝通過程中存在很多的誤解，在開發(fā)過程中也會(huì)存在諸多不必要的失誤與bug的產(chǎn)生，因此本文小T將帶領(lǐng)大家一起來了解AUTOSAR框架的CAN Driver一些十分重要的關(guān)鍵詞解釋以及難以理解的基本概念，助力我們?nèi)粘９ぷ髦械腃AN驅(qū)動(dòng)開發(fā)。

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

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

CAN 驅(qū)動(dòng)關(guān)鍵詞定義解釋#### CAN 驅(qū)動(dòng)Mailbox關(guān)鍵配置參數(shù)

在底層MCAL CAN Driver配置過程中總是會(huì)存在許多容易混淆的關(guān)鍵配置參數(shù)，該類參數(shù)如果配置有誤，有些時(shí)候就會(huì)出現(xiàn)讓人費(fèi)解的問題與bug，因此為了能夠減小這類問題的出現(xiàn)，小T結(jié)合自身實(shí)戰(zhàn)經(jīng)驗(yàn)一起來學(xué)習(xí)下CAN驅(qū)動(dòng)中關(guān)鍵配置參數(shù)的定義與相關(guān)注意事項(xiàng)。

Hardware Object

如上述表格中所述，一個(gè)Hardware Object就是一個(gè)CAN L-PDU的buffer，用來存儲(chǔ)僅一個(gè)CAN ID Message，你將可以將其理解為就是我們常說的Mailbox，該Mailbox就是CAN 控制器硬件上的一個(gè)物理buffer空間，用來存儲(chǔ)用于發(fā)送或者接收的一個(gè)CAN ID Message，該CAN ID Message自然就是包含CAN ID，DLC， Data三個(gè)部分。

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ù)面向的對(duì)象是HOH，即HRH或者HTH。

該參數(shù)表示是否為該HOH配置了FIFO機(jī)制，如果數(shù)目為1，則并沒有FIFO進(jìn)行緩存數(shù)據(jù)，如果大于1，那么就是為該HOH配置了FIFO的數(shù)據(jù)緩存機(jī)制，這種緩存機(jī)制對(duì)于防止CAN接收或者發(fā)送的重要報(bào)文丟失至關(guān)重要。

如下圖所示便展示了CanHwObjectCount在HOH中的配置：

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

2.CanHwObjectCount在HOH中的接收配置

如上圖1所示，可以知道該HOH為發(fā)送類型的HOH，因此就直接可以理解為HTH，那么該HTH中定義了參數(shù)CanHwObjectCount的值為1，表示不存在FIFO機(jī)制，僅是一個(gè)唯一的buffer，如果數(shù)據(jù)發(fā)送或者接收比較頻繁，意味著新數(shù)據(jù)可能來不及發(fā)送；

如上圖2所示，可以知道該HOH為接收類型的HOH，因此就直接可以理解為HRH，那么該HRH中定義了參數(shù)CanHwObjectCount的值為2，表示存在深度為2的FIFO機(jī)制，如果數(shù)據(jù)發(fā)送或者接收比較頻繁，至少存在深度為2的FIFO緩存空間來防止重要數(shù)據(jù)的丟失。

Full CAN與Basic CAN

在MCAL CAN Driver中的Full CAN與Basic CAN是用來修飾HOH的類型參數(shù)，該參數(shù)可以通過CanObejctType進(jìn)行定義。

Full CAN：一般表示僅存在1個(gè)的Hardware Object與之對(duì)應(yīng)，且該Full CAN類型的Hardware Object與特定的CAN ID Message綁定；

Basic CAN：一般表示存在1個(gè)或者多個(gè)的Hardware Object與之對(duì)應(yīng)，且該Basic CAN類型的Hardware Object與非特定的CAN ID Message或者一定范圍內(nèi)的CAN ID Message綁定；

注意事項(xiàng)：

對(duì)于Basic Can類型的HOH一般建議通過配置硬件過濾器來實(shí)現(xiàn)底層無關(guān)CAN Message的數(shù)據(jù)接收或者特定范圍內(nèi)的報(bào)文接收，減少不必要的硬件中斷，也就從某種程度上降低了CPU負(fù)載；

當(dāng)硬件資源較為充足且無需過多考慮新數(shù)據(jù)可能覆蓋老數(shù)據(jù)的場(chǎng)景，一般推薦將HOH配置成FULL CAN類型。

在HOH的配置過程中，一般情況下均需要先將FULL CAN類型的HOH統(tǒng)一配置在前，Basic CAN類型的HOH配置在后，否則容易造成生成的代碼中Maibox使用錯(cuò)亂的情況。

推薦配置方案

小T結(jié)合實(shí)戰(zhàn)經(jīng)驗(yàn)，將軟件開發(fā)過程中常見的四類報(bào)文類型：應(yīng)用報(bào)文，網(wǎng)絡(luò)管理報(bào)文，診斷報(bào)文，Xcp報(bào)文的發(fā)送與接收的mailbox配置方案總結(jié)如下表所示：

CAN Mailbox的四類報(bào)文推薦配置方案推薦配置方案總結(jié)如下：

診斷報(bào)文由于屬于重要報(bào)文，丟失與發(fā)送均不允許丟失且存在嚴(yán)格的時(shí)序關(guān)系，因此發(fā)送與接收均推薦Basic CAN+FIFO 來設(shè)置；

Xcp報(bào)文發(fā)送與接收都是特定ID的報(bào)文，因此發(fā)送與接收均推薦Full CAN+Buffer來設(shè)置；

應(yīng)用報(bào)文在mailbox硬件充足的前提下，發(fā)送與接收優(yōu)先采用Full CAN+Buffer來設(shè)置，如果硬件資源不夠的話，那么推薦采用Basic CAN+FIFO來配置；

網(wǎng)絡(luò)管理報(bào)文接收一般是一定范圍的報(bào)文，因此接收推薦采用Basic CAN+Buffer來配置，發(fā)送由于ID確定，因此推薦采用Full Can+Buffer來設(shè)置；

所有報(bào)文的發(fā)送與接收配置完成之后，一定要確保所有配置HOH中的CanHwObjectCount加起來的mailbox發(fā)送與接收數(shù)目分別不能超過芯片手冊(cè)規(guī)定的發(fā)送mailbox與接收mailbox硬件資源總和；

CAN 驅(qū)動(dòng)硬件Buffer類型

了解了上述CAN驅(qū)動(dòng)推薦方案之后，我們接下來需要進(jìn)一步探究下對(duì)于can controller硬件資源內(nèi)部對(duì)于用于存儲(chǔ)CAN L-PDU的buffer是如何定義的？

一般來講，現(xiàn)在市面上主流的CAN Controller對(duì)于其硬件資源按照發(fā)送與接收可以分為如下幾種類型Buffer：

發(fā)送硬件Buffer類型：Tx Buffer，Tx FIFO，Tx Queue；

接收硬件Buffer類型Rx Buffer，Rx FIFO；

接下來將針對(duì)每種硬件Buffer類型分別進(jìn)行講解：

Tx Buffer

Tx Buffer又名Dedicated Tx Buffer，該Buffer會(huì)與特定的CAN ID進(jìn)行綁定，發(fā)送優(yōu)先級(jí)是完全通過CAN ID越小，優(yōu)先級(jí)越高，高優(yōu)先級(jí)優(yōu)先發(fā)送；

一般該Tx Buffer會(huì)配置HOH的CanObejctType類型為Full CAN模式。

Tx FIFO

上文中說的FIFO機(jī)制實(shí)際上在硬件底層可以分為兩種，一種是Tx FIFO，另外一種就是Tx Queue，因?yàn)閮煞N本身都是一種緩存空間。

Tx FIFO顧名思義就是按照“先進(jìn)先出”的方式來進(jìn)行發(fā)送，忽略CAN ID優(yōu)先級(jí)，一般為了防止出現(xiàn)優(yōu)先級(jí)反轉(zhuǎn)現(xiàn)象，不建議使用FIFO模式。

Tx Queue

Tx Queue 作為FIFO機(jī)制的一種，與Tx FIFO本身有所不同的是放置新的Message發(fā)送請(qǐng)求時(shí)按照先后順序來放置，但是發(fā)送時(shí)則與Tx Buffer機(jī)制一樣，按照高優(yōu)先級(jí)優(yōu)先發(fā)送原則，即CAN ID越小，優(yōu)先級(jí)越高，如果存在多個(gè)同樣CAN ID的報(bào)文需要發(fā)送，那么數(shù)字小的Buffer ID號(hào)先發(fā)送。

除了上述單一的發(fā)送模式之外，絕大多數(shù)情況可能存在上述組合模式，組合模式下特別需要注意的是外發(fā)報(bào)文優(yōu)先級(jí)的判定：

Tx Buffer + Tx FIFO模式

如上圖可知，每次發(fā)送優(yōu)先級(jí)按照如下方式進(jìn)行判定：

取出Dedicated Tx Buffer中的最小CAN ID發(fā)送請(qǐng)求；

取出Tx FIFO中最老的CAN ID發(fā)送請(qǐng)求；

比較上述Tx Buffer與Tx FIFO分別取出的CAN ID發(fā)送請(qǐng)求，兩者之間的CAN ID越小的發(fā)送請(qǐng)求優(yōu)先發(fā)送。

Tx Buffer + Tx Queue模式

如上圖可知，每次發(fā)送優(yōu)先級(jí)按照如下方式進(jìn)行判定：

取出Dedicated Tx Buffer中的最小CAN ID發(fā)送請(qǐng)求；

取出Tx Queue中最小CAN ID發(fā)送請(qǐng)求；

比較上述Tx Buffer與Tx Queue分別取出的CAN ID發(fā)送請(qǐng)求，兩者之間的CAN ID越小的發(fā)送請(qǐng)求優(yōu)先發(fā)送。

Rx Buffer

Rx Buffer與Tx Buffer同理， 一般都是與特定的CAN ID進(jìn)行綁定，一般該Rx Buffer均會(huì)配置HOH的CanObejctType類型為Full CAN模式，如果此時(shí)老的數(shù)據(jù)CPU還沒有處理完，新的數(shù)據(jù)將不會(huì)得到處理。

Rx FIFO

Rx FIFO典型的就是按照“先進(jìn)先出”的方式進(jìn)行CAN報(bào)文的接收處理，一般而言，Rx FIFO都會(huì)存在兩個(gè)，一個(gè)是Rx FIFO0，另外一個(gè)是Rx FIFO1，這個(gè)根據(jù)實(shí)際情況進(jìn)行選擇。

同時(shí)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í)與接收數(shù)據(jù)時(shí)不會(huì)存在數(shù)據(jù)一致性問題；

審核編輯：劉清