上篇文章講述了CAN總線的特點，以及CAN協議幀的基礎知識，包括數據幀和遙控幀。本文將在此基礎上通過相關的協議標準，寄存器和整車控制器CAN通信報文來進一步深化CAN協議幀的理解，同時可了解到一個簡單版的CAN通訊功能實現。

---

4 CAN協議標準及其他有關內容

當要深入CAN通訊功能時，就必須得介紹下CAN2.0協議標準和ISO 11898標準。為什么呢？因為只有通過這些協議標準才能掌握CAN通訊的基石，更好地了解CAN通訊功能的硬件與軟件。當去了解這些協議標準時，發現CAN通訊框架是基于OSI參考模型來設計。那么什么是OSI參考模型？它有什么作用?接下來從OSI參考模型開始了解。

4.1 OSI 參考模型

引自[3]:
OSI參考模型是一個邏輯上的定義，一個規范，它把網絡從邏輯上分為七層，每一層都對應著不同的作用，這七層分別為應用層、表示層、會話層、傳輸層、網絡層、數據鏈路層、物理層。對OSI七層網絡模型的定義，對后續的各種網絡技術的評判和分析提供了依據，也是學習網絡技術的基礎。
OSI參考模型的七層協議的分層目的是為了解決異種機互連的問題，包括互連時所遇到的兼容性問題。分層的最大優點是將服務、接口和協議這三者明確地區分開。
在這個參考模型的數據傳輸過程當中，不同主機對等層之間會按照協議進行通信，同一主機的不同層之間通過接口進行通信。在這個模型中，每一層將上一層傳遞過來的通信數據加上若干控制位后再傳遞給下一層，最終由物理層傳遞到對方物理層，再逐級上傳，從而實現了對等層之間的邏輯通信。

圖1 OSI 參考模型，來源不詳

考慮到作為汽車底層網絡，其信息傳輸量相對較少，信息傳輸的實時性要求較高，網絡連接方式相對較簡單，因此，CAN總線網絡底層只采用了OSI 7層參考模型的最低兩層，即物理層和數據鏈路層，而在高層只有應用層。物理層和數據鏈路層的功能可由CAN接口器件來實現，應用層的功能是由微處理器實現的。這里先了解下物理層和數據鏈路層：

1）物理層

物理層是OSI參考模型中最底層，主要定義了系統的電氣、機械、過程和功能標準。如：電壓、物理數據速率、最大傳輸距離、物理聯接器和其他的類似特性。物理層的主要功能是利用傳輸介質為數據鏈路層提供物理連接，負責數據流的物理傳輸工作。物理層傳輸的基本單位是比特流，即0和1，也就是最基本的電信號或光信號，是最基本的物理傳輸特征。

圖2 物理層與CAN通訊相關的內容，引自[1]

2）數據鏈路層

數據鏈路層是在通信實體間建立數據鏈路聯接，傳輸的基本單位為“幀”，并為網絡層提供差錯控制和流量控制服務。數據鏈路層由MAC(介質訪問控制子層)和LLC(邏輯鏈路控制子層)組成，其中MAC的主要任務是規定如何在物理線路上傳輸幀，LLC對在同一條網絡鏈路上的設備之間的通信進行管理。數據鏈路控制子層主要負責邏輯上識別不同協議類型，并對其進行封裝，也就是說數據鏈路控制子層會接受網絡協議數據、分組的數據包并且添加更多的控制信息，從而把這個分組傳送到它的目標設備。

圖3 數據鏈路層與CAN通訊相關的內容，引自[1]

到此我們就對OSI參考模型的物理層和數據鏈路層有了基本的概念，那么CAN協議標準都對物理層和數據鏈路層做了什么定義呢？下面來具體了解：

4.2 ISO 11898 標準

1991年，Bosch發布CAN 2.0 標準協議，隨后 ISO 標準化了 該協議，發布了ISO 11898 和 ISO 11519 兩種標準。這兩種標準對數據鏈路層的定義相同，但物理層不同。這里我們主要關心CAN總線標準對數據鏈路層的定義，故下面只選取 ISO 11898 進行分析即可，如圖4。因為 ISO 11898-2,3,4主要是針對于CAN總線的物理特性，電氣特性等，不在本系列文章討論范圍內，故只考慮 ISO 11898-1，對應于OSI參考模型的數據鏈路層和物理層情況如圖5所示。

圖4 ISO 11898: 2003(E)

圖5 ISO11898-1對應的OSI參考模型的物理層和數據鏈路層，引自[2]

由圖5可知，CAN通訊的物理層定義信號怎樣傳輸；數據鏈路層的LLC子層的功能主要是報文濾波、超載通知和恢復管理；MAC子層的功能主要是傳送規則，即控制幀結構、執行仲裁、錯誤檢測、出錯標定和故障界定，是實現CAN協議的核心。

下面具體了解下ISO 11898-1標準，本文主要關注3塊內容：

• 服務原語
• LLC子層
• MAC子層

1）服務原語 有3種通用類型：

• 請求（request），即服務用戶向服務提供者發起請求服務；
• 通知（indication），即服務提供者向服務用戶通知一個對其重要的服務提供者內部事件；
• 確認（confirm），即服務提供者向服務用戶傳達先前請求服務的結果，是成功還是失敗，是完成還是未完成。

通俗地講，發送時，用戶先請求提供者，然后提供者發送，再向用戶確認；接收時，提供者通知用戶，如下圖6。當信息經過LLC或MAC傳輸，即發送或者接收，同樣地遵循上述的規則，所以在此先介紹這三條服務原語，為后續LLC和MAC的描述做鋪墊。

圖6 服務原語的使用示意

2）LLC子層

LLC子層提供兩種無連接模式傳輸服務，分別為Unknowledged data transfer service和Unacknowledged remote data request service，這里我們就關注前者，對于這種服務會使用LLC data frame，用來發送和接收。

根據上述服務原語的描述，我們知道發送數據時，LLC用戶傳輸數據給LLC子層，并請求LLC子層發送，當LLC子層發送數據后，向LLC用戶確認發送狀態。當接收數據時，LLC子層通知LLC用戶有數據到達。這里每條服務原語對數據有怎樣的規定呢？下圖7做了清晰的定義。

圖7 LLC子層服務原語，引自[2]

到此我們就知道了LLC子層的發送與接收過程。另外，LLC子層可以與對等的LLC實體交換數據單元的，也就是交換LLC數據幀。

圖8 LLC子層的數據傳輸類型

一個LLC數據幀由3個位段（bit field）組成，即id，長度和數據3段，基本對應于上篇文章的CAN協議幀的三段，其中id段稍有不同，它包含3個部分：基本id，擴展flag和擴展id，但在MAC子層會將id段處理成CAN協議幀的id段格式。

圖9 LLC數據幀，引自[2]

3）MAC子層

MAC子層是OSI DLL的最底層部分，介于LLC子層和PLS子層間，因此提供了訪問這兩層的接口，另外也提供了打包接收數據/解包發送數據，接收/發送介質訪問管理等功能，如下圖10。

圖10 MAC子層的功能，引自[2]

與上述LLC子層同樣的思路，LLC與MAC間的數據傳輸使用的服務原語如下所示：

圖11 MAC子層的數據傳輸類型，引自[2]

圖12 MAC子層服務原語6

回看圖10可知道，MAC子層分為兩條完全獨立的操作部分，即發送和接收。MAC發送或接收的數據幀就是上篇文章所述的CAN協議幀，即如下圖13所示。

圖13 MAC數據幀結構，引自[2]

對于發送部分，MAC子層要實現：數據打包和發送介質訪問管理。

• 數據打包，包括：LLC數據幀的接收；CRC序列計算；MAC數據幀的構建（即增加SOF，SRR位，IDE位，RTR位，保留位，CRC，ACK和EOF到LLC數據幀）。
• 發送介質訪問管理，包括：識別到總線空閑時發起發送；位填充；仲裁，仲裁失敗轉為接收模式；ACK檢查等；向物理層發送一串位流（a serial bit stream）。

圖14 發送部分，從LLC用戶到物理層接口過程

對于接收部分：MAC子層要實現：接收介質訪問管理和數據解包。

• 接收介質訪問管理，包括：從物理層接收一串位流；刪除填充的位；發送ACK等。
• 數據解包，包括：移除數據幀的MAC特定信息；把LLC數據幀和接口控制信息給LLC子層。

圖15 接收部分，從物理層接口到LLC用戶過程

上面提到了位填充（bit stuffing）和去位填充（bit destuffing），這里引用[4]的解釋：

圖16 位填充，引自[4]

---

通過上面的內容，我們就了解了CAN協議幀的由來，按照OSI參考模型來分層CAN通訊架構，CAN協議幀具體在哪層使用，如何使用（當然以上內容也將為后續的CAN通訊軟件實現做了鋪墊）。而且我們也知道CAN協議幀最終CAN接口器件來實現，那么具體是怎么通過硬件來實現？

4.3 CAN協議幀的相關寄存器

從基于AUTOSAR架構的軟件開發，一般會涉及到與CAN協議幀有關的幾種寄存器，比如與id對應的寄存器，與數據對應的寄存器和與長度對應的寄存器。也就是說通過對寄存器的了解，就可以很清楚地明白CAN協議幀是怎么通過硬件（寄存器）實現的。下面分別通過Infineon和NXP 飛思卡爾的用戶手冊稍作了解。

下圖17為Infineon的仲裁寄存器定義：

圖17 仲裁寄存器，引自[5]

下圖18為Infineon的數據寄存器（低位）的定義。

圖18 數據寄存器（低位），引自[5]

下圖19為Infineon的功能控制寄存器，24-27位定義了DLC。

圖19 功能控制寄存器中的DLC，引自[5]

NXP的用戶手冊中定義的CAN協議幀的寄存器如下圖20：

圖20 CAN協議幀相關的寄存器，引自[6]

下圖21為NXP的標識符寄存器定義：

圖21 標識符寄存器，引自[6]

下圖22為NXP的數據段寄存器定義：

圖22 數據段寄存器，引自[6]

下圖23為NXP的數據長度寄存器定義：

圖23 數據長度寄存器，引自[6]

CAN協議幀就這樣通過寄存器來實現：發送時，從軟件寫入到寄存器（硬件）；接收時，從寄存器讀取到軟件。

4.4 整車控制器CAN通信報文與CAN協議幀

整車控制器CAN通信報文定義了控制器（比如VCU）與其他控制器（比如ECU,TCU,MCU等）通過哪些id通信，每條報文有多長，數據表示什么信號，不同信號值代表什么意思等信息，如下圖24所示。

圖24 整車控制器報文示意

也就是說整車控制器CAN通信報文首先必須基于CAN協議幀來定義的，其次它賦予每一條CAN協議幀的實際意義，即不同id的幀數據段代表著不同的物理意義。當然這些并不在物理層和數據鏈路層實現，而是在應用層來實現，也就是通過軟件實現物理層數據的解析。

---

到此我們就了解到了與CAN協議幀相關的協議標準，寄存器和整車控制器CAN通信報文。基于這些內容就基本可以實現一個簡單版的CAN通訊功能，即接收功能：從讀取相關寄存器的數據，最終傳給應用層，將數據解析成具有意義的信號；發送功能：將應用層信號轉換成規定的數據形式發送，寫入寄存器，再向應用層確認。

寫到此也產生了一個問題：數據最終發送方是以顯隱性電平形式逐位地發送到總線上，那么接收方是怎么正確地接收這一位一位的總線電平呢？下篇文章將回答這個問題，即介紹ISO 11898-1中有關物理層PLS的內容。

Reference:

[1] 汽車CAN總線協議規范-深圳速銳得科技有限公司-國六OBD在線監測 |遠程排放管理終端|CANBUS總線開發|汽車總線數據應用

[2] ISO 11989-1

[3] CAN總線通信模型與OSI的七層參考模型(轉)_microcosmv的博客-CSDN博客

[4] CAN入門書

[5] TC27x D-Step 32-Bit Single-Chip Microcontroller

[6] MC9S08DZ60 HCS08微控制器

總結

以上是生活随笔為你收集整理的tms570 can 接收大量数据_CAN通讯系列--CAN总线基础3的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。