在搞清楚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類型。
審核編輯:劉清
-
CAN
+關注
關注
57文章
2764瀏覽量
464137 -
RAM
+關注
關注
8文章
1369瀏覽量
114880 -
fifo
+關注
關注
3文章
389瀏覽量
43811
發布評論請先 登錄
相關推薦
評論