深度解析CAN FD特點(diǎn)及使用注意事項(xiàng)

CAN?總線在工業(yè)、汽車行業(yè)具有非常廣泛的應(yīng)用，為網(wǎng)絡(luò)中設(shè)備之間點(diǎn)對點(diǎn)通信提供一種可靠、穩(wěn)定、經(jīng)濟(jì)的方案。伴隨網(wǎng)絡(luò)中設(shè)備節(jié)點(diǎn)的增加，由于?1Mbps?速率和最長數(shù)據(jù)?8?字節(jié)的限制，通信效率和總線占用問題變得愈發(fā)突出。而?CAN FD?正是為了應(yīng)對這種挑戰(zhàn)而出現(xiàn)。文章接下來將介紹?CAN FD?的一些新特點(diǎn)以及使用注意事項(xiàng)，最后將使用?Toradex Apalis iMX8QM?和?Verdin iMX8M Mini?計(jì)算機(jī)模塊簡單演示?CAN FD?使用。

相比于傳統(tǒng)?CAN?協(xié)議，CAN FD?最大的兩個(gè)特點(diǎn)是采用可變速率和單幀最長?64?字節(jié)數(shù)據(jù)，另外包括控制位和?CRC?校驗(yàn)的變化。

圖?1：傳統(tǒng)?CAN?和?CAN FD?幀

控制位的首位由傳統(tǒng)?CAN?的?RTR?變?yōu)?CAN FD?的?RRS，該位始終是顯性（0）。第三個(gè)控制位在傳統(tǒng)?CAN?中屬于保留功能，在?CAN FD?位?FDF，位隱性（1）。FDF?位?1?時(shí)表示該幀是?CAN FD?格式。在?CAN FD?中緊隨?FDF?還是一個(gè)保留功能，用于將來的擴(kuò)展。BRS（Bit Rate Switch）位允許?CAN FD?幀以不同的速率進(jìn)行傳輸。如果?BRS?為顯性（0）則該幀采用和仲裁階段（Arbitration Phase）同樣的速率進(jìn)行傳輸，既速率不發(fā)生變化。當(dāng)?BRS?為隱性（1），該幀接下來的部分將以較高的速率傳輸。這里需要注意，并不是整個(gè)?CAN FD?幀都用高速率傳輸，如下圖，Data Phase?從?BRS?后的?ESI?位開始到?CRC Delimiter?位結(jié)束，該階段的數(shù)據(jù)會(huì)以較高的速率傳輸。

圖?2：?CAN FD?幀結(jié)構(gòu)

ESI（Error Status Indicator）通常為顯性（0）。當(dāng)發(fā)送方遇到通訊異常后會(huì)將其置為隱性（1）。DLC?表示該幀中實(shí)際數(shù)據(jù)長度，為了于傳統(tǒng)?CAN?兼容，DLC?仍然采用?4bit。當(dāng)數(shù)據(jù)長度小于?8?字節(jié)時(shí)，DLC?位的數(shù)值可以直接表示數(shù)據(jù)長度，但超過?8?字節(jié)時(shí)，由于?4?個(gè)位最高只能表示?15，為了支持?CAN FD?最長?64?字節(jié)數(shù)據(jù)，這里采用了折中的表示方法。當(dāng)數(shù)據(jù)不超過?8?個(gè)字節(jié)時(shí)，DLC?仍直接表示數(shù)據(jù)長度。當(dāng)超過?8?個(gè)字節(jié)，只支持?12?到?64?中部分長度的數(shù)據(jù)包，而非全部的?9?到?64?任一長度。如下表所示，當(dāng)?DLC?為?9?時(shí)，CAN FD?數(shù)據(jù)長度為?12?字節(jié)，DLC?為?12?時(shí)，數(shù)據(jù)長度是?24?字節(jié)。

?

?

在實(shí)際應(yīng)用中最好選擇上面的其中一種長度，避免通訊效率降低。如果小于某一種長度，則需要對數(shù)據(jù)進(jìn)行填充，可以用?0xCC?和?0x55?作為填充字節(jié)，這樣能夠在總線上產(chǎn)生足夠的波形翻轉(zhuǎn)從而使?CAN?節(jié)點(diǎn)保持同步。

在?CAN FD?中根據(jù)數(shù)據(jù)長度會(huì)采用不同的?CRC?校驗(yàn)方案，當(dāng)小于等于?16?字節(jié)是為?CRC-17，當(dāng)數(shù)據(jù)大于?16?字節(jié)后則采用?CRC-21。CRC Delimiter?之后的格式?CAN FD?和傳統(tǒng)?CAN?仍保持一致。

CAN FD?雖然具有更長的數(shù)據(jù)包以及更快的傳輸速度，但是由于引入了更多的位到幀中，幀的開銷也會(huì)增加。以同樣發(fā)送?1字節(jié)數(shù)據(jù)包為例，傳統(tǒng)?CAN 2.0?標(biāo)準(zhǔn)幀和?CAN FD?標(biāo)準(zhǔn)幀具體組成如上方圖?1?所示。傳統(tǒng)?CAN 2.0?標(biāo)準(zhǔn)幀總共位?54 bit，CAN FD?為?70 bit。CAN FD?需要多消耗?16 bit?來傳送同樣的數(shù)據(jù)。如果?CAN FD?不采用更高的可變速率這就意味著同樣的幀，CAN FD?反而會(huì)要更長的傳輸時(shí)間。當(dāng)?CAN FD?采用可變速率，那么情況將會(huì)變得不一樣。假設(shè)?CAN FD?的仲裁速率是?500 Kbps，和傳統(tǒng)?CAN?的速率一致，而可變的數(shù)據(jù)傳輸速率提高?8?倍到?4 Mbps。傳統(tǒng)?CAN?耗時(shí)為?54 bit/ 500 Kbps = 108 us。CAN FD?中?4 Mbps?的速率只用于傳輸從?ESI?位開始到?CRC Delimiter?位之間的數(shù)據(jù)，所以?CAN FD?耗時(shí)為?29 bit/500 Kbps + 41 bit/4 Mbps = 68 us。這里我們看到，在提高數(shù)據(jù)傳輸速率情況下，?CAN FD?即使有更多的幀開銷，幀傳輸時(shí)間還是減少了?40 us。更高的傳輸速度有利于發(fā)送節(jié)點(diǎn)更快得完成幀發(fā)送，減少?CAN?總線占用時(shí)間，這對越長數(shù)據(jù)的幀會(huì)更加明顯，對?CAN?網(wǎng)絡(luò)的實(shí)時(shí)性來講是一個(gè)優(yōu)勢。

然而提高傳輸速率不僅僅是在使用的時(shí)候設(shè)置一個(gè)參數(shù)，更重要的是保障?CAN?總線物理鏈路層的質(zhì)量?？梢允褂?a target="_blank">示波器觀察總線上信號(hào)的質(zhì)量。如果信號(hào)陡峭且清晰，可以嘗試將數(shù)據(jù)傳輸速率提高到仲裁速率的?2?到?4?倍。測量點(diǎn)需要遍布總線上多個(gè)位置，信號(hào)在不同位置會(huì)有所差異。線路阻抗的一致性對信號(hào)質(zhì)量至關(guān)重要。通常在總線交叉點(diǎn)的線纜沒有發(fā)生物理尺寸變化，并采用具有相同介電常數(shù)的隔離器，阻抗會(huì)保持不變。這可以參考以太網(wǎng)和?USB?中使用的專門的連接器。當(dāng)?CAN FD?采用較高的傳輸速率時(shí)，每處線路分叉，每個(gè)連接器都可能會(huì)影響阻抗，從而引起信號(hào)反射。這些反射信號(hào)的能量最終可以影響?CAN?幀每個(gè)比特位邊緣的抖動(dòng)。

CAN FD?最長?64?字節(jié)的數(shù)據(jù)包使用在實(shí)際應(yīng)用中也需要注意。更長的幀不可避免在傳輸?shù)臅r(shí)候會(huì)占用總線更多的時(shí)間，而這期間其他?CAN?節(jié)點(diǎn)則無法發(fā)送數(shù)據(jù)。對于實(shí)時(shí)性需求不高的場合，如通過?CAN?總線升級(jí)固件，長幀能夠以更小的開銷完成傳輸。而對實(shí)時(shí)性有要求的場合，對長幀的使用需要有一定的限制。對于?8?字節(jié)以下的幀，?CAN FD?更高的數(shù)據(jù)傳輸速率可以有效降低總線占用時(shí)間，前提是物理鏈路層能夠滿足高速傳輸?shù)囊蟆?/p>

對于應(yīng)用開發(fā)?CAN FD?的使用是非常簡單的。CAN FD?是可以兼容傳統(tǒng)?CAN，這意味著原先基于傳統(tǒng)?CAN?通信的代碼可以直接運(yùn)行在支持?CAN FD的設(shè)備上，但不使用任何?CAN FD?的新功能。如果需要使用?CAN FD?的可變數(shù)據(jù)速率或者超過?8?字節(jié)數(shù)據(jù)的幀，那么代碼也只需做簡單的修改。我們以?Linux?中?SocketCAN?為例，使用?can-utils?代碼進(jìn)行說明。在?cansend.c?和?candump.c?中采用?canfd_frame?結(jié)構(gòu)體來存放需要發(fā)送和接收的?CAN?數(shù)據(jù)。CANFD_MAX_DLEN?為?64，對應(yīng)?CAN FD?最長的?64?字節(jié)。

然后將?can socket?設(shè)置?CAN FD?格式，使用?setsockopt()?函數(shù)，設(shè)置?CAN_RAW_FD_FRAMES?參數(shù)即可。

在發(fā)送時(shí)將?struct canfd_frame frame?結(jié)構(gòu)體中?len?長度參數(shù)設(shè)置?CAN FD?定義幾種長度。

剩余代碼中的操作可以沿用傳統(tǒng)?CAN?模式下的方法。最后用下面命令配置?CAN?設(shè)備。這里仲裁速率為?500Kbps，CAN FD?可變數(shù)據(jù)速率為1Mbps，在結(jié)尾添加?fd on?參數(shù)啟用?CAN FD。

接下來我們將在?Apalis iMX8QM?和?Verdin iMX8M Mini?計(jì)算機(jī)模塊上演示?CAN FD?通信。Apalis iMX8QM ?采用?NXP i.MX8 QuadMax?處理器，可以提供?3?路?CAN?接口。Verdin iMX8M Mini?上的?i.MX8 M Mini?處理器本身并不支持?CAN?接口，我們在模塊上添加了一塊?MCP2518?實(shí)現(xiàn)?CAN?接口。

Apalis iMX8QM?和?Verdin iMX8M Mini?分別通過?Ixora?和?Dahlia?載板進(jìn)行?CAN?接口互聯(lián)。這兩個(gè)底板上均引出了?CAN?接口，方便用戶測試。

Verdin iMX8M Mini?作為發(fā)送端，依次運(yùn)行下面命令，并發(fā)送?4?字節(jié)和?10?字節(jié)長度的幀。

Apalis iMX8QM?作為接收端。

上面測試可以看到?Verdin iMX8M Mini?發(fā)送一幀?10?字節(jié)長度的數(shù)據(jù)，但是?Apalis iMX8QM??在收到了?12?字節(jié)的數(shù)據(jù)。這是?CAN FD?定義沒有?10?字節(jié)的幀長，適合發(fā)送?10?字節(jié)的是?12?字節(jié)長度的幀。所以看到實(shí)際收到的是“11 22 33 44 55 66 77 88 99 00 00 00”這12?個(gè)字節(jié)，最后兩個(gè)“00 00?”是填充的數(shù)據(jù)。這部分填充數(shù)據(jù)來自?lib.c?代碼? memset(cf, 0, sizeof(*cf)); /* init CAN FD frame, e.g. LEN = 0 */

總結(jié)

CAN FD?的新功能為滿足了應(yīng)用對更加高效的傳輸、更好實(shí)時(shí)性需求，但充分發(fā)揮這些功能還需要從應(yīng)用開發(fā)到鏈路設(shè)計(jì)方面的優(yōu)化。上面我們討論簡單地討論一些注意事項(xiàng)，以及使用方法，具體的應(yīng)用還要結(jié)合實(shí)際工況做調(diào)整。

審核編輯：黃飛