1 背景

本人汽車電子行業(yè)從業(yè)多年，最近兩年主要從事CAN,LIN,ETH的功能開發(fā)。前幾日與測試小伙伴溝通的時候談到，雖然目前在前期功能驗證的時候，Vector公司提供的基于CANOE軟件和CAPL腳本的測試環(huán)境可以完全模擬各類汽車通信網(wǎng)絡的上的任意節(jié)點的任意功能，但是由于價格極其昂貴，所以在項目預算吃緊的情況下，無法做到license完全人手一份。那么在這樣的前提下，是否能夠做一些替代的方案。因此我想到了一些可以做的嘗試：

購入市面上較為便宜的CAN盒，LIN盒，ETH轉T1的盒子等，然后通過python等腳本語言來完成節(jié)點的行為模擬

使用STM32，GD32等價格親民的片子來自己做一個模擬的物理節(jié)點，應用ETH，CAN，LIN等協(xié)議棧，通過開源的項目來完成節(jié)點的行為模擬

通過一段時間的研究，我發(fā)現(xiàn)方案2會更加具有挑戰(zhàn)且對軟硬件的掌控更加自如，因此我打算基于網(wǎng)絡上全開源的項目來完成我的這個設想。

2 目的

如圖所示，我的初期目標還是相對比較簡單的，由于CAN網(wǎng)絡是汽車通訊網(wǎng)絡中最常見也最常用的，并且考慮到單片機的外設io資源，性能等，我打算采用兩路CANFD和一路ETH來做幾個以下比較常規(guī)的功能。

節(jié)點作為支持CANFD的Node，可以完成對CANFD的報文收發(fā)，報文過濾，報文重發(fā)等功能

節(jié)點作為支持Router的Node，對DoCAN->DoCAN, Doip->DoCAN的診斷路由以及CANFD->CANFD的直接路由

節(jié)點作為支持UDS的Node，可以完成對診斷服務的響應。

節(jié)點需要支持CAN

通信框架

3 環(huán)境

3.1 硬件

初步選型了STM32H750VBT6,網(wǎng)絡上的板子價格相對都比較便宜，并且性能不弱，必要時甚至可以擴充ROM，此外自帶兩路FDCAN，再加上ETH的支持，所以性價比很高。

硬件拓撲如下

3.2 軟件

軟件么，就毋庸置疑了，哈哈，之前就接觸過rt-thread，沒有真正的使用過，正好接這個機會來更加深入的了解下rt-thread。

4 當前實現(xiàn)的工作

由于我在標題標記了(1)，說明STM32H750在CANFD部分的工作需要多個part來描述，因此本文內(nèi)容僅描述了如何在沒有使能硬件過濾功能的前提下實現(xiàn)基于HAL-FDCAN和TJA1042收發(fā)器對CAN FD Frame，CAN Frame的收發(fā)實現(xiàn)。硬件過濾的部分需要其他的工作來做更進一步的描述。

4.1 創(chuàng)建工程以及配置

由于我更習慣CLI的工作方式，因此完成下述步驟之后就算基本完成了工程的配置

直接使用studio創(chuàng)建如下工程，創(chuàng)建完成之后不再使用，后續(xù)編譯使用cmake + gcc， 調(diào)試使用pyocd + daplink

后續(xù)使用ENV環(huán)境來配置

編譯完成后可以直接燒錄并且在串口輸出

4.2 時鐘配置

Note：計算CANFD的沖裁域以及數(shù)據(jù)域的波特率和采樣率的源頭來自于與FDCAN的時鐘頻率，其實根據(jù)實際板子配置之后，可以將FDCAN的時鐘配置為常見的20MHZ，40MHZ，80MHZ中的一個，我當前選擇了40 MHz

4.3 使能CAN的配置

4.3.1

ENV

RT-Thread Components -> Device Drivers ->

[* ] **Using CAN device drivers***

[ ] Enable CAN hardware filter

[*] **Enable CANFD support**

保存配置之后

4.3.2 CubeMx

4.3.2.1 使能FDCAN1和FDCAN2

4.3.2.2 生成代碼的使用

根據(jù)選擇方式的不同，代碼生成位置也會不同，只需要保證drv在調(diào)用HAL驅動的時候可以被正確call到即可，具體細節(jié)不再贅述，論壇文章頗多。

4.4 完善CANFD的設備驅動

4.4.1 添加宏

在 board.h中添加宏

/*#define BSP_USING_ON_CHIP_FLASH*/

#define BSP_USING_FDCAN

#define BSP_USING_FDCAN1

#define BSP_USING_FDCAN2

4.4.2 添加drv_fdcan.c

根據(jù)rtthread的驅動模型，kernel在can.c中提供了can設備各類操作的抽象，但是對CAN控制器的具體操作需要一個設備驅動來完成，而在5.1.0的軟件中只有drv_can.c且里面只支持CAN_HAL。在一番搜索之后發(fā)現(xiàn)ARTPI官方例子中有drv_fdcan.c的文件，可以支持FDCAN_HAL。然而這個驅動存在以下幾個小問題，導致其只能發(fā)送can幀，而不能發(fā)送canfd幀

只支持仲裁域配置，無數(shù)據(jù)域配置

只支持配置成classic模式，沒有配置成FD模式的接口

沒有提供一個類似于drv_can.c里面提供的在不同時鐘頻率下的不同波特率和采樣率的數(shù)據(jù)設置集合

沒有提供對Txfifo, txbuffer等方式的靈活設置的接口

不支持數(shù)據(jù)長度大于8的發(fā)送和接收，且沒有提供Length與DLC之間的轉換接口。

等等其他

4.4.3 完成對drv_fdcan.c的一些改進之后，一些重要的配置項如下

時間參數(shù)設置的規(guī)則

1波特率 = (1 / (n + tseg1 + tseg2)) * fclk

如果配置為40Mhz, 仲裁段500K -80%采樣率，數(shù)據(jù)段2000K-70%采樣率

/* 位時序配置:

************************

位時序參數(shù) | Normal | Data

--------------------------|--------------|----------------

CAN子系統(tǒng)內(nèi)核時鐘輸入 | 40 MHz | 40 MHz

時間常量 | 25 ns | 25 ns

相位段1 | 63 tq | 13 tq

相位段2 | 16 tq | 6 tq

同步跳轉寬度 | 16 tq | 6 tq

位長度 | 40 tq = 1 us | 40 tq = 1 us

位速率 | 500k | 2 MBit/s

4.4.4 總線初始化

當完成配置，編譯燒錄之后，啟動系統(tǒng)會自動初始化fdcan1和fdcan2

4.5 測試

4.5.1 測試結果

完成驅動之后，使用FINISH接口編寫了一個FDCAN的測試接口，測試代碼如下

測試結果 ->如圖所示，分別發(fā)送了如下命令

4.5.2 測試結論

可以通過APP層的參數(shù)控制，并且由于CANFD對CAN是完全兼容的特性，可以實現(xiàn)在STM32H750+TJA1042的組合上發(fā)送

長度為1-8的CAN Frame

長度為1-64的CAN FD Frame

5 未完成的工作

對HDR過濾器的配置，目前FDCAN的過濾配置有多種模式，需要從can. -> drv.fdcan.c 的鏈路上優(yōu)化配置HDR的方式

對canfd的高數(shù)據(jù)下的鏈路性能以及壓力測試

文檔中的一些設置描述比較粗略，會再補充細節(jié)的。

版權聲明：本文為RT-Thread論壇用戶「Woshizhapuren」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權協(xié)議，轉載請附上原文出處鏈接及本聲明。

原文鏈接：https://club.rt-thread.org/ask/article/221a0238569f6f40.html