在搞清楚FullCAN和BasicCAN是什么之前,我們先搞清楚一些基礎的東西。 1、CAN Module與CAN Node、Controller關系 2、Controller與Transceiver關系 3、Controller與RAM資源關系 剛提到,tc397中,一個CAN Module包含4個Controller,那每個Controller可以發送多少個CAN報文,接收多少個CAN 報文呢?這里我們要區分硬件緩存CAN報文的數量和項目中要求發送/接收報文的數量。
以發送CAN報文數量為例:需求要求當前網絡節點發送100幀CanID不同的CAN報文,實際該節點CAN Controller可用的硬件發送緩存區最多有32,意味著底層硬件最多緩存32幀發送報文,如果超過32幀發送請求,則會因沒有硬件空間緩存而發送請求失敗。 tc397 CAN Module資源情況如下所示:
4、Mailbox、HRH、HWObject Mailbox:郵箱,就是CAN驅動所具有的接收緩存區和發送緩存區,接收緩存區和發送緩存區均在RAM區。 HWObject:硬件對象,包含CAN ID、DLC、Data等信息的RAM區。 HRH:Hardware Receive Handle,接收句柄,一個HRH表示一個接收HWObject。 HTH:Hardware Transmit Handle,發送句柄,一個HTH表示一個發送HWObject。 首先,FullCAN和BasicCAN是CanIf模塊配置的參數。
Autosar對FullCAN和BasicCAN的解釋如下所示: 將上述的解釋進一步細化,如下所示: 在CAN驅動層,可以通過過濾的方式,過濾一段范圍內的CanID,也就是說:會有一段范圍內的報文接收進來,但是接收進來的這一段范圍的報文并不一定都是上層所需要的,怎么辦呢?用軟件方式,再過濾一遍,由CanIf過濾所需要的CAN報文。因此,提出了FullCAN和BasicCAN的概念。 比如:HRH對應BASIC CAN類型,接收CanID范圍:0x10~0x18,CanIf根據過濾算法,在0x10~0x18范圍內過濾出需要的0x10、0x13、0x14、0x16、0x17送給上層,而其余的丟棄,如下所示: 不同報文類型如何選擇FULL CAN/BASIC CAN 應用報文:一般選擇配置成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類型。 ![]() 參考資料 SIMPLE TITLE Infineon-AURIX_TC3xx_Part2-UserManual-v01_00-EN.pdf |
|
來自: 開心果NeedCar > 《待分類》