前篇內容請點擊查看：

RA MCU CAN和CANFD IP介紹

CAN和CANFD協議簡介（上）

2. CAN協議

2.2 協議層

前文講述了CAN的物理層標準，約定了電氣特性，以下介紹的協議層則規定了通訊邏輯。

2.2.1 幀的種類

通信是通過以下5種類型的幀進行的。

? 數據幀

? 遙控幀

? 錯誤幀

? 過載幀

? 幀間隔

在這些幀當中，數據幀和遙控幀由用戶設定，其他的幀由CAN的硬件部分完成。

另外，數據幀和遙控幀有標準格式和擴展格式兩種格式。標準格式有11位的ID，擴展格式具有29位ID。

各種幀的用途如下表所示。

2.2.2 數據幀

數據幀把消息從發送單元傳到接收單元，是用戶使用的最基本的幀。數據幀由7個段構成。

(1) 幀起始：表示數據幀開始。

(2) 仲裁段：表示該幀優先級的段。

(3) 控制段：表示數據的字節數及保留位。

(4) 數據段：數據本身，可傳送0～8個字節。

(5) CRC段：檢查幀的傳送錯誤的段。

(6) ACK段：正常接收確認段。

(7) 幀結束：表示數據幀結束。

2.2.3 遙控幀

接收單元向發送單元請求消息所用的幀。遙控幀由6 個段組成，也可以說是沒有數據段的數據幀。

(1) 幀起始（SOF）：表示幀的開始。

(2) 仲裁段：表示該幀優先級的段。請求具有同樣ID的數據幀。

(3) 控制段：表示所請求數據的字節數及保留位。

(4) CRC段：檢查幀的傳送錯誤的段。

(5) ACK段：正常接收確認段。

(6) 幀結束：表示遙控幀結束。

關于遙控幀和數據幀：

? 數據幀和遙控幀有何不同

遙控幀沒有數據段，仲裁段的RTR位為隱性電平。

沒有數據段的數據幀和遙控幀可通過RTR位區別開來。

? 遙控幀沒有數據段，數據長度碼該如何表示？

遙控幀的數據長度碼以所請求數據幀的數據長度碼表示。

? 沒有數據段的數據幀有何用途？

可用于各單元的定期連接確認/應答、或仲裁段本身帶有實質性信息的情況下。

2.2.4 錯誤幀

在收發信中發現錯誤時用于通知錯誤的幀。錯誤幀由錯誤標志和錯誤間隔符構成，錯誤幀的發送是由CAN的硬件部分來完成的。

(1) 錯誤標志：錯誤標志包括有效錯誤標志和無效錯誤標志兩種。

? 有效錯誤標志：6位顯性電平。

? 無效錯誤標志：6位隱性電平。

(2) 錯誤間隔符：錯誤間隔符由8位隱性電平構成。

注

1. 有效錯誤標志：處于錯誤有效態的單元檢出錯誤時傳送的錯誤標志。

2. 無效錯誤標志：處于錯誤無效態的單元檢出錯誤時傳送的錯誤標志。

3. 錯誤標志的重合：由連接到總線上的各單元的錯誤檢出時間不同，錯誤標志會發生重合，最長可延續到12位。

2.2.5 過載幀

過載幀是用于接收單元通知其尚未完成準備所用的幀。過載幀由過載標志和過載間隔符構成。

(1) 過載標志：6位顯性電平。過載標志的構成與有效錯誤標志的構成相同。

(2) 過載間隔符：8個隱性位。過載間隔符的構成與錯誤間隔符的構成相同。

注

1. 過載幀的重合：與錯誤標志一樣依據發生時序不同過載標志也會發生重合，最長可延遲到12位。

2.2.6 幀間隔

幀間隔用于分隔數據幀或遙控幀。數據幀或遙控幀前插入幀間隔可將本幀與前面發送的任何幀（數據幀、遙控幀、錯誤幀、過載幀）分開。但是，過載幀和錯誤幀前不能插入幀間隔。

(1) 間隔：3位隱性電平。在“間隔”期檢測到顯性電平時，一定要發送過載幀。然而，在間隔期的第3位出現的顯性電平被認為是SOF，此時不發送過載幀。

(2) 總線空閑：隱性電平，無長度限制（0位亦可）。本狀態為總線處于空閑中，要發送的單元可開始發送消息。

(3) 延遲傳送（發送暫時停止）：8個隱性電平。處于錯誤無效態的單元在發送完一個消息后的幀間隔中必須包含的段。

2.2.7 優先級的仲裁

在總線空閑態，最先開始發送消息的單元獲得通信權。

多個單元同時開始傳送時，各發送單元從仲裁段的第一位開始進行仲裁。位電平第一次出現不同而且位電平為顯性的單元獲得通信權發送。仲裁失敗的單元在下一個位開始進入接收狀態。

仲裁的過程如下圖所示：

(1) 數據幀和遙控幀的優先級

具有同樣ID的數據幀和遙控幀在總線上競爭時，仲裁段的最后一位（RTR）為顯性電平的數據幀具有優先權，可繼續通信。

(2) 標準格式和擴展格式的優先級

具有相同基本ID的標準格式與擴展格式的數據幀或遙控幀在總線上競爭時，由于標準格式的RTR位為顯性電平，具有更高的優先權，可進行發送。

2.2.8 錯誤的種類

錯誤共有5種。有時數種錯誤同時發生。

? 位錯誤

? 填充錯誤

? CRC錯誤

? 格式錯誤

? ACK錯誤

錯誤的種類、錯誤的內容、出錯的幀和檢出錯誤的單元如下表所示。

2.2.9 位時序

一個位可分為4段。

? 同步段(SS: Synchronization Segment)

? 傳播時間段(PTS: Propagation Time Segment)

? 相位緩沖段1(PBS1: Phase Buffer Segment 1)

? 相位緩沖段2(PBS2: Phase Buffer Segment 2)

這些段由最小時間單位Tq(Time Quantum)構成。

消息中的1位被分為4個段，每個段又由若干個Tq構成，這稱為位時序。

消息中的1位由多少個Tq構成、每個段又由多少個Tq構成、這些是可以任意設定的。通過設定位時序，總線上數個單元可以以相同的時序對消息采樣，可以設定采樣點。采樣點設置在PBS1的結束處，以此時檢測到的總線上的電平值作為該位的電平值。

各段的用途和Tq數如下表所示。

1位的構成如下圖所示。

2.2.10 取得同步的方法

CAN 協議的通信方法為非歸零NRZ(Non-Return to Zero)方式。每個位上沒有開始或終了的同步信號。發送單元以與位時序同步的方式開始發送數據。接收單元根據總線上電平的變化進行同步接收信號。

但是，發送單元和接收單元存在的時鐘頻率誤差及傳送路徑上的（電纜、驅動器等）相位延遲會引起同步偏差。因此接收單元通過強制同步、再同步的方法調整時序進行接收。

2.2.11 強制同步

接收單元在總線空閑狀態檢出幀起始時進行的同步調整。檢出從隱性電平到顯性電平的邊沿時被認為是SS段，與SJW無關。

2.2.12 再同步

在接收過程中根據總線上的電平變化進行的同步。

檢出邊沿（總線上的電平跳變）時，對照誤差值并且根據SJW值延長PBS1段，或縮短PBS2段，以配合同步。但如果發生了超出SJW值的誤差，按照SJW值作修正。

2.2.13 同步規則

強制同步和再同步遵從如下規則。

(1) 1 位中只進行一次同步調整（兩次采樣點間）。

(2) 只有當邊沿后的總線電平與邊沿前一個總線采樣值不同時，該沿才能用于同步。

(3) 一旦檢測到隱性電平到顯性電平的邊沿，如果滿足條件(1)、(2)須進行同步。

(4) 幀間隔(“間隔”的第1位除去)中檢測到隱性電平到顯性電平的邊沿時，須進行強制同步。

(5) 其他所有的隱性電平到顯性電平的邊沿，須進行再同步。

(6) 發送單元觀測到自身輸出的顯性電平有延遲時不進行再同步。

2.3 CANFD框架

CAN FD可以理解成CAN協議的升級版，只升級了協議，物理層未改變。

CAN FD協議引入了經過調整的CAN數據幀，以實現額外的數據字節和靈活的比特率。

下面我們比較一個11位的傳統CAN幀與一個11位的CAN FD幀（同時也支持29位）：

下面我們一步一步地討論這些差異：

RTR與r1(RRS)：傳統CAN中使用了遠程傳輸請求Remote Transmission Request（RTR）來識別數據幀和相應的遠程幀。但在CAN FD中，不支持遠程幀，遠程請求替換（r1）始終是顯性（0）。

在CAN-FD幀中，在控制字段中添加了三個新位（FDF、BRS、ESI位）：

? 擴展數據長度 Extended Data Length （EDL）：隱性表示幀為CAN-FD，否則該位為顯性（稱為R0）在CAN 2.0幀中。在傳統CAN格式的幀中，所對應傳輸的是位R0而不是EDL。

? 比特率切換 Bit Rate Switch（BRS）：指示是否啟用兩個比特率。如果是隱性，則比特率從仲裁階段的標準比特率切換到數據階段的預配置交替比特率。如果是顯性，則不切換比特率。

? 錯誤狀態指示器 Error State Indicator（ESI）：表示發送節點狀態，指示節點處于錯誤活動模式還是錯誤被動模式。

DLC：像在傳統CAN中一樣，CAN FD DLC是4位，表示幀中數據字節的數量。下表顯示了這兩種協議如何始終使用多達8個數據字節的DLC。為了維持4位DLC，CAN FD使用從9到15的其余7個值來表示所使用的數據字節數（12、16、20、24、32、48、64）。

CRC：傳統CAN中的循環冗余校驗（CRC）為15位，而在CAN FD中為17位（最多16個數據字節）或21位（20-64個數據字節）。在傳統CAN中，CRC中可以包含0到3個填充位，而在CAN FD中，總是有四個固定填充位以提高通信可靠性。

總結起來，CAN和CANFD協議是一種常用于汽車和工業領域的通信協議。CAN協議是一種高效可靠的串行通信協議，而CANFD協議在保持CAN協議基本特性的基礎上增強了數據傳輸速率和數據長度。這兩種協議都在車輛電子系統中扮演著重要的角色，實現了車內各個電子設備之間的可靠通信。

更多內容，您可復制下方網址到瀏覽器中打開進入瑞薩中文論壇查看：

https://community-ja.renesas.com/zh/forums-groups/mcu-mpu/