1.1：數據段傳輸性能上的區別，這里就是指波特率上的區別

1. 2：數據段長度的區別

(1)CAN標準幀和擴展幀的數據段0-8Byte

(2)CANFD的標準幀和擴展幀數據段長度是0-64Byte

1.3：幀類型不一樣

• CAN有 1：數據幀，遠程幀 ， 錯誤幀，擴展幀

• CAN FD 有數據幀 錯誤幀 擴展幀

1.4：CAN只能以固定的波特率發送，CANfd可以有兩種不同的波特率（這里指的是同一幀報文可以有兩種不同的發送速率）

如下圖所示，other higher speed 指的是數據段，這也是CANfd比較神奇的地方，就是說在SOF-DLC區間內以較低的速率發送數據，而在數據段波特率突然提升，CRC-END階段又恢復低速率運行。

1.5：CRC位數和格式不一樣

當報文為傳統CAN時，仍采用原有的CRC多項式。

當報文為CANFD且數據長度小于等于16字節時，調整為17位的CRC多項式。

當報文為CANFD且數據長度大于16字節時，則調整為21位的CRC多項式。

注意：這里只是說的是“多項式”，而不是指CRC整個占據的bit數量。1.7小結后處，做了整體的說明。

1.6 CRC計算時機不同

在傳統CAN中，位填充（連續5位相同位后填充一位相反位）是在CRC計算之后進行。當CAN控制器發送報文時，先對需要進行校驗的數據段（即：SOF-數據段的最后1bit位）CRC計算后，再填入填充位發送；接收時，則對接收數據移除填充位后，再做CRC校驗。

在CANFD中，CRC計算時機調整為位填充后。也就是說，發送方發送時，先對報文進行位填充后，再做CRC計算。接收方，也使用同樣的方法進行CRC計算。這種方式增加了對填充位的CRC計算，降低了錯誤漏檢的概率。

易錯理解點：

1、CAN和CANFD類型報文，接收方對數據處理時，都要去除填充位

1.7 增加固定填充位和填充位計數

CANFD中，CRC域采用一種固定填充位的格式：在CRC段第一位及接下來的每四位增加一個固定填充位（Fixed Stuff Bit，以下簡稱為FSB），填充位為上一位的反碼。

以下分別為CRC17和CRC21的固定填充位（FSB）位置。

除了固定填充位之外，CRC域的起始還包含了3位的填充位計數，及1位填充位計數檢驗位，以進一步提高通信可靠性。填充位計數在CRC段的位置如下圖紅框所示。

3位填充位計數表示的值為實際填充位計數對8取模的結果，采用格雷碼顯示。奇偶校驗位對填充位計數進行奇偶校驗。詳見下表。

需要注意的是，non-ISO CANFD協議標準，無固定填充位FSB及填充位計數。若使用USBCANFD-200U時，遇到通訊的CANFD控制器為non-ISO標準，可以在打開通道時，選擇CANFD標準為non-ISO，以兼容non-ISO標準CANFD控制器。

小結：CRC整體 = CRC序列（17bit或21bit）+固定填充位（6bit或7bit）+ 填充位計數（固定4bit）

（1）當數據段字節書<=16Byte時，CRC = 17+6+4 = 27bit；

（2）當數據段字節書>16Byte時，CRC = 21+7+4 = 32bit；

1.8 CAN_FD兩種填充方式的兼容

CAN_FD采取了兩種填充格式：

1、逢5填1

2、FSB填充法

如果出現如下情況，該如何處理？有如下兩種方案

1、有些同學會說，數據段需要額外填充一個0，如這樣 111110。

2、又有同學會說，不用，直接在首個（圖中，從左往右首個FSB）直接填充0，即可。

實際上CANFD,采取第2種方案。

1.9 CAN_FD對CRC錯誤發生時，錯誤幀發送的時間

CAN傳統幀，接收方應該在檢測到CRC錯誤后，在ACK界定符之后，開始發送錯誤幀。

CAN_FD幀，接收方應該在檢測到CRC錯誤后，在CRC界定符之后3個bit位的時間后，開始發送錯誤幀。

A、 CAN_FD發送錯誤幀，過載幀 采取的位速率

CAN_FD的錯誤幀和過載幀采取和仲裁段一致的位速率，（即，低速率發送）錯誤幀和過載幀。

B、 CAN_FD的CRC填充字段發送填充位錯誤

2.1 幀結構不一樣

CANFD標準幀格式

1：SOF幀開始:

下面這兩張圖，分別給出了CAN幀和CANFD 幀的標準形式和擴展形式

給大家提出幾個問題

1：請總結 CANFD擴展幀格式與標準幀格式的不同

2：總結CAN   幀標準格式和擴展格式之間的區別和聯系

3：總結CAN標準格式和CANFD標準格式之間的區別和聯系

4：總結CAN   擴展格式和CANfd擴展格式之間的區別和聯系

2.2、DLC不一樣

注意點，我們可以觀察到CAN幀和CANFD幀，DLC都為4bit，CAN幀最大發送字節為8Byte，4bit能完全表示。

但是CANFD的DLC，也只有4bit，4bit最大能表示十進制數15。fd最大發送字節為64該如何表示

前4個，二進制數值每增加1，代表長度+4。第5位+8，第6個＋16，第7個+32。成倍增加

延伸一下，如果我們使用設備，模擬發送CAN_FD幀，DLC必須要是（0-8||12||16||20||24||32||48||64）

如果有人告訴你,他設計的CAN_fd幀數據段長度為15，只能說明這個人是完全不懂CAN_FD的。

2.3 CAN_FD中 （BRS位+CRC界定符位 ），所占用的位時間?

過上面的學習，大家都知道，CAN_FD中的BRS置位時，從BRS-CRC界定位速率切換為高速率。問大家一個問題：

問？(BRS位+CRC界定符位 ）所占用的位時間?,前提條件數據段速率2M，仲裁段為500K。

答：如果你不假思索的回答，100uS，那你就錯了。因為你想當然得認為位速率切換，從BRS位開始出就開始切換為2M，然后到CRC界定符位結束處。其實是錯誤的。

正確的其實是如下圖

這樣結論就出來了， BRS位+CRC界定符位 =(一個500k的位時間)+（一個2M的位時間）。準確來說，是在采樣點處，速率會發送切換。

大家可以拿示波器，去實際量一下BRS和CRC界定符實際的為時間。我先告訴你答案：

（500k的位時間）=2us，（2M的位時間）=500ns，假設 “仲裁段采樣點（百分比）” = 70%，“數據段采樣點（百分比）”=80%。

計算結果= 2us * 70%+ 500 *(20%)=1500ns，左右。

實測波形如下：1.499us，也證實了我們的計算。

通過以上的比較，我們能大致得出來，CAN標準幀&CAN拓展幀，CANFD標準幀和CANFD拓展幀，CAN標準遠程幀&CAN拓展遠程幀。下圖也表示了，他們之間的關系。

首先總結所有幀結構的相同點：

（1）只要是CAN/CANfd幀，[SOF----ID(11bit)]，任何幀之間的結構都一樣。

（2）只要是CAN/CANfd幀 [DLC---CRC)，任何幀之間的結構都一樣。

（3）只要是CAN/CANfd幀（CRC-EOF]，任何幀之間的結構都一樣。

我們嘗試從CAN幀的發展歷史來代入進來理解，從實際應用角度去切入。這會讓我們更加理解為什么各種CAN幀之間的不同，以及為什么不同。

4.1 CAN標準幀

首先來看，最簡單的CAN標準數據幀 sof+（11bitID）+RTR(遠程標志位：1隱形代表：遠程幀)+IDE(拓展幀標致位：1=是拓展幀)+r0+DLC+Data+CRC(15bit)+CRC界定符+ACK(1bit)+ACK界定符+EOF(7bit隱形位)

首先CAN被最開始定義出來時，規范的設計者，先設計了  幀起始+仲裁段+控制段+數據段+CRC段+ACK段+幀結束段。

幀起始段，暫時只要理解為一個位的顯性位。

仲裁段。一開始設計了11Bit,位，最大能表示0x7EF(2031個ID細心的同學發現了，不對啊！11bit最大不是能表示0x7FF，這是因為11位ID,的高7bit不能全置1的原因導致的),ID段首先被發送到CAN總線上。接收節點根據事先設定，決定接收或者不接受這個幀。

當節點決定接收這個文件后，立馬就要接收控制段的信息，假設CAN被開發出來的時候，控制段的前三位都是預留位，程序對該段信息直接忽略，開始接收DLC,和數據段（這才是我們需要的最重要的信息），接收完數據段后，程序開始接收CRC校驗段（校驗范圍sof--接收的數據段最后一個字節）。然后自己開始計算CRC。最后判斷 （接收的CRC） =（自身計算的CRC），來決定是否在ACK端應答。最后發送幀結束標志。至此一個幀算是正式的發送且被成功接收。

以上過程都很完美。一直過了好幾年，出現了以下兩種情況：

（1）汽車電子發展的越來越快，一個總線上掛載的節點越來越多，ID數量不夠用了（本質上0x7EF(2031個ID是夠用的)但是實際應用中 為了維持系統的穩定性，不會依次選取所有的ID），這是需要擴展ID,于是大家坐一起商量了一下，決定把ID再增加18BIT。就如圖所示：擴展之后532676607位，絕對是夠用了。

這還讓我想到了通訊界一個很有意思的問題，就是IP地址，當初設計ip地址的時候，ip地址為4個Byte，也就是4294967295個IP可以用，出去一些特定用途的IP外（如廣播，組播用途），其他IP都可以分配給個人或公司團體，大家都認為這些IP地址以及足夠使用了，結果沒想到互聯網僅僅過了幾十年的發展，目前這些IP已經快分配完了。于是大家又是想出了CIDR，又是想出了IPV6協議（也就是6個Byte的ip）。

說上面一段的原因，我是想說，很多時候，在制定標準時，好像很合理，但是隨著技術的發展很多事情的發展，會大大出乎最初的意料。有時防患于未然，雖然要犧牲掉一部分性能和效率，很多時候也不失為一種合理的選擇。

（2）總線上的負債率的不斷提升（這里解釋下，總線負債率，可以簡單理解成在單位時間內（如1s），有數據的段所占用的時間  /  總線上有數據的段所占用的時間+空閑的段占用的時間）如1s內有一半的時間是有數據段，一半時間是沒有數據段。那么總線的負載率就是50%。工程師們就開始研究，如何在不影響通訊的情況下，減少總線負載率。于是CAN遠程幀便應用而生。遠程幀的全稱是遠程請求幀。幀結構只包括幀頭（幀起始段+仲裁段+控制段）。

它應用的場景如下：如鎖車系統，當鎖車系統接收到鑰匙上的鎖車信號時，鎖車系統必須要知道發動機狀態是否已經關閉，車速是否為0，車上所有燈是否關閉。這些條件不滿足時（現在好多車型甚至能夠判斷車內是否還有人，發出信號的鑰匙是否在車內），必須不能鎖車。但是平常情況下，鎖車系統根本不需要去接收這些信號。故工程師們便想出了，利用遠程請求幀。

工作過程如下：

當收到鎖車信號時，發送相關請求幀（假設發動機狀態和車速信號在0x121幀上，車燈信號在0x345幀上），鎖車系統發出這些幀的幀頭，當發動機系統或車燈系統接收到這些遠程請求幀后，會立即把這些信號發送出來（比如周期100ms發送10幀）。此時鎖車系統就能夠知道，鎖車條件是否滿足了。

但是我們想一下，遠程請求幀，能不能和請求的幀，幀頭是一模一樣的，不能。我們從其他需要接收，發動機狀態和車速信號在0x121，車燈信號在0x345的模塊去考慮，假如我們發送遠程請求幀頭和被請求數據的幀頭一樣，就會導致混亂，其他模塊根本沒有請求這些數據，怎么自己就發出來了？

于是還記得，我們上一段介紹can數據幀時的“假設CAN被開發出來的時候，控制段的前三位都是預留位，程序對該段信息直接忽略”這就起到作用了，工程師們于是就將從左往右的第一個bit，命名為RTR，于是順帶著又將第二個bit位命名為IDE位。第三位依然保留稱為r0。

此時看似萬事大吉了，可是注意看細節，最新的CAN數據幀標準中，把11位ID和RTR位，都算到了仲裁段中去了。是不是意味著，遠程幀和數據幀是可以兼容的，且數據幀比遠程幀的優先級要高：RTR在can標準數據幀中，是0（顯性）。在遠程幀是1（隱性） 。

這樣做的好處在于，假如遠程請求幀會連續發送三幀，但是目標模塊反應很快，在第二幀遠程請求幀剛剛發出來的時候，被請求的數據幀同時發出。此時把RTR放在仲裁段，就可以知道，返回的數據幀優先級更高。這時遠程請求幀就因為仲裁失敗，停止發送。返回的數據幀優先級高，繼續發送。

此時看第二個問題，我們已經將預留位的第一位設置為RTR標志位，那么現在來解決11位ID不足的問題。

此時又有問題有來了,can擴展數據幀已經定義好了，那么還要不要把CAN的擴展遠程請求幀也定義出來。

我們初步的方案是將11位ID，擴展為（11+18）=29Bit，最簡單的方法是不是在箭頭處，直接添加18Bit，直接組合成29Bit的仲裁段。這樣做的看起來并不存在什么問題！

但是還是兼容性的問題，直接在11bit后添加18bitID,  的情況下CAN標準數據幀和CAN擴展數據幀同時存在于一條can總線上，我問大家一個問題

can標準數據幀ID=0x001; id二進制為        0000 0000 001

can擴展數據幀的ID=0x001；id的二進制為 0000 0000 0000 0000 0000 0000 0000 1

根據仲裁從最高位開始的協議，明顯的CAN擴展幀的優先級更高，進一步思考，

can標準數據幀ID=0x001; id二進制為         0000 0000 001

can擴展數據幀的ID=0x3FFF；id的二進制為 0000 0000 0001 1111 1111 1111 1111 1

can擴展數據幀0x3FFF的優先級比can標準數據幀ID=0x001的優先級還要高。這明顯不是我們想要的。我們設計CAN擴展幀就是為了彌補ID不夠用的作用的，理想的情況下，

應該: can標準數據幀0x3EF的優先級>CAN擴展幀的0x...0001的，于是我們將IDE位移入SOF之后，直接先判斷是否是擴展幀。是擴展幀直接仲裁失敗，退出發送。

但是此時所有的軟件工程師又立馬要跳出來，全體反對了，你這么隨心所欲的修改，把CAN標準幀的結構都改掉了，我要是想在原有的軟件架構下，想再兼容CAN擴展幀，我連原先處理CAN標準幀的程序都要全部修改，反對反對！堅決反對！?。。。?！

4.2 CAN拓展幀

于是 我們嘗試把18bit的放到r0之后，這樣做又會有兩個問題。

1：當標準數據幀的11Bit>擴展幀的前11Bit。時，此時標準幀的優先級將低于擴展幀

2：當標準遠程幀的11Bit=擴展幀的前11Bit，時，因為擴展幀的RTR位必須為隱形，此時將導致，此種情況下，擴展幀的優先級大于標準幀的遠程幀。

前11位相同的情況下，我們必須保證優先級：標準數據幀>標準遠程幀>擴展數據幀>擴展遠程幀

此時，我們又將擴展幀中RTR，放到18Bit的ID之后，這樣的話，又會帶來代碼改動的問題，于是又在IDE前填充了一位，稱為SRR（遠程請求代替位），擴展幀中這一位必須為1（隱形位）。

真是歷經九九八十一難，終于把擴展幀的結構給定下來了。

閑下來的工程師們，決定在對擴展幀的結構做一點優化。把r0這個不用的位，移動到RTR之后，又為了以后的擴展，又添加了 一個新的預留位，最終結構如下。

來源：CSDN@帥氣小胖子

https://blog.csdn.net/WE_BIG/article/details/130832481