在搞清楚FullCAN和BasicCAN是什么之前，我們先搞清楚一些基礎的東西。

1基礎概念

提示：

以英飛凌tc397為例。

1、CAN Module與CAN Node、Controller關系

平時開發中，我們說“ECU有3路CAN”，所說的“3路CAN”和3個Node是一個概念嗎？不是。

我們平時所討論的“3路CAN”是指3個網絡，也就是我們口語中的“節點”。而芯片手冊中（Data Sheet），一個CAN Module會包含多個Node（即，Controller），比如：tc397芯片手冊中，MCMCAN Module包含3個CAN Module，每個Module包含4個Controller，如下所示：

2、Controller與Transceiver關系

在實際的使用中，一個Controller必須配一個Transceiver，Controller+Transceiver = Network，如下所示：

所以，平時我們口語話的“3路CAN”是指3個Controller+Transceiver組合，即：3個Network，我們也常稱“3個節點”。

3、Controller與RAM資源關系

剛提到，tc397中，一個CAN Module包含4個Controller，那每個Controller可以發送多少個CAN報文，接收多少個CAN 報文呢？這里我們要區分硬件緩存CAN報文的數量和項目中要求發送/接收報文的數量。

硬件緩存CAN報文數量：是指上層請求發送報文或者接收報文時，CAN驅動最多能緩存的數量；

項目中要求發送/接收報文的數量：是指當前節點要外發或者接收的報文數量。

以發送CAN報文數量為例：需求要求當前網絡節點發送100幀CanID不同的CAN報文，實際該節點CAN Controller可用的硬件發送緩存區最多有32，意味著底層硬件最多緩存32幀發送報文，如果超過32幀發送請求，則會因沒有硬件空間緩存而發送請求失敗。

tc397 CAN Module資源情況如下所示：

提示：上圖中的Controller用“Node”表示。由上可以看出，3個CAN Module，共12個Controller。

每個CAN Module（4個Controller）共用32個發送Tx Buffer，共用64個Rx Buffer

...對于發送緩沖區，每個CAN Module共用32個發送緩沖區，如果配置了32個TxDedicated Buffer，則沒有空間配置Tx FIFO/Queue；同理，每個CAN Module雖然有兩個Rx FIFO，如果配置了64個Rx Dedicated Buffer，則沒有空間配置Rx FIFO。一般，Tx/Rx Buffer配置時，會混合使用，比如：

20TxDedicated Buffer+ 12Tx Queue

40 RxDedicated Buffer+ 24Rx FIFO

MCMCAN

Module RAM區地址劃分順序如下所示：

4、Mailbox、HRH、HWObject

Mailbox：郵箱，就是CAN驅動所具有的接收緩存區和發送緩存區，接收緩存區和發送緩存區均在RAM區。

HWObject：硬件對象，包含CAN ID、DLC、Data等信息的RAM區。

HRH：Hardware Receive Handle，接收句柄，一個HRH表示一個接收HWObject。

HTH：HardwareTransmitHandle，發送句柄，一個HTH表示一個發送HWObject。

Mailbox、HWObject、HRH、HTH、Controller、Transceiver之間的關系如下所示：

2FullCAN和BasicCAN是什么？

首先，FullCAN和BasicCAN是CanIf模塊配置的參數。

BasicCAN：一個HWObject(HardwareObject)可以處理一段范圍的CanId

FullCAN：一個HWObject(HardwareObject)只能處理單個CanId

Autosar對FullCAN和BasicCAN的解釋如下所示：

將上述的解釋進一步細化，如下所示：

使用工程中，MCAL會將緩存區分配成FIFO和Dedicated Buffer，FIFO和Dedicated Buffer的區別是什么呢？Dedicated Buffer區域，Hareware Object與HRH/HTH一一對應，而FIFO區域，一個HRH/HTH對應多個HarewareObject，如下所示：

3為什么需要FullCAN和BasicCAN？

在CAN驅動層，可以通過過濾的方式，過濾一段范圍內的CanID，也就是說：會有一段范圍內的報文接收進來，但是接收進來的這一段范圍的報文并不一定都是上層所需要的，怎么辦呢？用軟件方式，再過濾一遍，由CanIf過濾所需要的CAN報文。因此，提出了FullCAN和BasicCAN的概念。

比如：HRH對應BASIC CAN類型，接收CanID范圍：0x10~0x18，CanIf根據過濾算法，在0x10~0x18范圍內過濾出需要的0x10、0x13、0x14、0x16、0x17送給上層，而其余的丟棄，如下所示：

CanIf可以通過設置CANIF_HRHRANGE_LOWER_CANID、CANIF_HRHRANGE_UPPER_CANID方式過濾，也可以通過設置CANIF_HRHRANGE_BASEID、CANIF_HRHRANGE_MASK進行過濾。

不同報文類型如何選擇FULL CAN/BASICCAN

應用報文：一般選擇配置成FULL CAN類型，對于應用報文，一般不需要緩存，使用最新接收的數據即可。對于發送的應用報文，都配置成FULL CAN類型需要一個前提：上層需要發送應用報文數量＜底層硬件緩存區數量。比如：底層發送硬件緩存區數量為32，節點需要發送的應用報文數量為50，顯然無法將50個發送的應用報文都配置成FULL CAN。遇到這種情況，一般會將重要的應用報文配置成FULL CAN，而其他要發送的應用報文配置成BASIC CAN。這樣配置以后，硬件緩存區的分配就需要混用，即：Dedicated Tx Buffers+Tx Queue或者 Dedicated Tx Buffers+Tx FIFO，如下所示：

如上圖，ID3、ID15、ID20是比較重要的應用報文，配置成FULL CAN，分別給一個獨立的緩存區；其他的緩存區則配置成BASIC CAN，即：一個緩存區可以發送多個不同CanID的報文。

診斷報文：一般選擇配置成BASIC CAN類型（結合FIFO Buffer使用），因為診斷報文的請求/響應不能錯序，需按照順序處理，且數據不能覆蓋；

網絡管理報文：接收一般選擇配置成BASIC CAN類型，因為一個節點一般會要求接收一段范圍的網絡管理報文，eg:0x500~0x53F。發送網絡管理報文配置成FULL/BASIC CAN類型均可，如果資源夠用，推薦配置成FULL CAN類型，因為每個節點的發送網絡管理報文唯一；

標定報文：一般選擇配置成FULL CAN類型。



審核編輯：劉清