上篇文章講述了CAN總線的特點(diǎn)，以及CAN協(xié)議幀的基礎(chǔ)知識(shí)，包括數(shù)據(jù)幀和遙控幀。本文將在此基礎(chǔ)上通過相關(guān)的協(xié)議標(biāo)準(zhǔn)，寄存器和整車控制器CAN通信報(bào)文來(lái)進(jìn)一步深化CAN協(xié)議幀的理解，同時(shí)可了解到一個(gè)簡(jiǎn)單版的CAN通訊功能實(shí)現(xiàn)。

---

4 CAN協(xié)議標(biāo)準(zhǔn)及其他有關(guān)內(nèi)容

當(dāng)要深入CAN通訊功能時(shí)，就必須得介紹下CAN2.0協(xié)議標(biāo)準(zhǔn)和ISO 11898標(biāo)準(zhǔn)。為什么呢？因?yàn)橹挥型ㄟ^這些協(xié)議標(biāo)準(zhǔn)才能掌握CAN通訊的基石，更好地了解CAN通訊功能的硬件與軟件。當(dāng)去了解這些協(xié)議標(biāo)準(zhǔn)時(shí)，發(fā)現(xiàn)CAN通訊框架是基于OSI參考模型來(lái)設(shè)計(jì)。那么什么是OSI參考模型？它有什么作用?接下來(lái)從OSI參考模型開始了解。

4.1 OSI 參考模型

引自[3]:
OSI參考模型是一個(gè)邏輯上的定義，一個(gè)規(guī)范，它把網(wǎng)絡(luò)從邏輯上分為七層，每一層都對(duì)應(yīng)著不同的作用，這七層分別為應(yīng)用層、表示層、會(huì)話層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層。對(duì)OSI七層網(wǎng)絡(luò)模型的定義，對(duì)后續(xù)的各種網(wǎng)絡(luò)技術(shù)的評(píng)判和分析提供了依據(jù)，也是學(xué)習(xí)網(wǎng)絡(luò)技術(shù)的基礎(chǔ)。
OSI參考模型的七層協(xié)議的分層目的是為了解決異種機(jī)互連的問題，包括互連時(shí)所遇到的兼容性問題。分層的最大優(yōu)點(diǎn)是將服務(wù)、接口和協(xié)議這三者明確地區(qū)分開。
在這個(gè)參考模型的數(shù)據(jù)傳輸過程當(dāng)中，不同主機(jī)對(duì)等層之間會(huì)按照協(xié)議進(jìn)行通信，同一主機(jī)的不同層之間通過接口進(jìn)行通信。在這個(gè)模型中，每一層將上一層傳遞過來(lái)的通信數(shù)據(jù)加上若干控制位后再傳遞給下一層，最終由物理層傳遞到對(duì)方物理層，再逐級(jí)上傳，從而實(shí)現(xiàn)了對(duì)等層之間的邏輯通信。

圖1 OSI 參考模型，來(lái)源不詳

考慮到作為汽車底層網(wǎng)絡(luò)，其信息傳輸量相對(duì)較少，信息傳輸?shù)膶?shí)時(shí)性要求較高，網(wǎng)絡(luò)連接方式相對(duì)較簡(jiǎn)單，因此，CAN總線網(wǎng)絡(luò)底層只采用了OSI 7層參考模型的最低兩層，即物理層和數(shù)據(jù)鏈路層，而在高層只有應(yīng)用層。物理層和數(shù)據(jù)鏈路層的功能可由CAN接口器件來(lái)實(shí)現(xiàn)，應(yīng)用層的功能是由微處理器實(shí)現(xiàn)的。這里先了解下物理層和數(shù)據(jù)鏈路層：

1）物理層

物理層是OSI參考模型中最底層，主要定義了系統(tǒng)的電氣、機(jī)械、過程和功能標(biāo)準(zhǔn)。如：電壓、物理數(shù)據(jù)速率、最大傳輸距離、物理聯(lián)接器和其他的類似特性。物理層的主要功能是利用傳輸介質(zhì)為數(shù)據(jù)鏈路層提供物理連接，負(fù)責(zé)數(shù)據(jù)流的物理傳輸工作。物理層傳輸?shù)幕締挝皇潜忍亓?#xff0c;即0和1，也就是最基本的電信號(hào)或光信號(hào)，是最基本的物理傳輸特征。

圖2 物理層與CAN通訊相關(guān)的內(nèi)容，引自[1]

2）數(shù)據(jù)鏈路層

數(shù)據(jù)鏈路層是在通信實(shí)體間建立數(shù)據(jù)鏈路聯(lián)接，傳輸?shù)幕締挝粸椤皫?#xff0c;并為網(wǎng)絡(luò)層提供差錯(cuò)控制和流量控制服務(wù)。數(shù)據(jù)鏈路層由MAC(介質(zhì)訪問控制子層)和LLC(邏輯鏈路控制子層)組成，其中MAC的主要任務(wù)是規(guī)定如何在物理線路上傳輸幀，LLC對(duì)在同一條網(wǎng)絡(luò)鏈路上的設(shè)備之間的通信進(jìn)行管理。數(shù)據(jù)鏈路控制子層主要負(fù)責(zé)邏輯上識(shí)別不同協(xié)議類型，并對(duì)其進(jìn)行封裝，也就是說數(shù)據(jù)鏈路控制子層會(huì)接受網(wǎng)絡(luò)協(xié)議數(shù)據(jù)、分組的數(shù)據(jù)包并且添加更多的控制信息，從而把這個(gè)分組傳送到它的目標(biāo)設(shè)備。

圖3 數(shù)據(jù)鏈路層與CAN通訊相關(guān)的內(nèi)容，引自[1]

到此我們就對(duì)OSI參考模型的物理層和數(shù)據(jù)鏈路層有了基本的概念，那么CAN協(xié)議標(biāo)準(zhǔn)都對(duì)物理層和數(shù)據(jù)鏈路層做了什么定義呢？下面來(lái)具體了解：

4.2 ISO 11898 標(biāo)準(zhǔn)

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

圖4 ISO 11898: 2003(E)

圖5 ISO11898-1對(duì)應(yīng)的OSI參考模型的物理層和數(shù)據(jù)鏈路層，引自[2]

由圖5可知，CAN通訊的物理層定義信號(hào)怎樣傳輸；數(shù)據(jù)鏈路層的LLC子層的功能主要是報(bào)文濾波、超載通知和恢復(fù)管理；MAC子層的功能主要是傳送規(guī)則，即控制幀結(jié)構(gòu)、執(zhí)行仲裁、錯(cuò)誤檢測(cè)、出錯(cuò)標(biāo)定和故障界定，是實(shí)現(xiàn)CAN協(xié)議的核心。

下面具體了解下ISO 11898-1標(biāo)準(zhǔn)，本文主要關(guān)注3塊內(nèi)容：

• 服務(wù)原語(yǔ)
• LLC子層
• MAC子層

1）服務(wù)原語(yǔ) 有3種通用類型：

• 請(qǐng)求（request），即服務(wù)用戶向服務(wù)提供者發(fā)起請(qǐng)求服務(wù)；
• 通知（indication），即服務(wù)提供者向服務(wù)用戶通知一個(gè)對(duì)其重要的服務(wù)提供者內(nèi)部事件；
• 確認(rèn)（confirm），即服務(wù)提供者向服務(wù)用戶傳達(dá)先前請(qǐng)求服務(wù)的結(jié)果，是成功還是失敗，是完成還是未完成。

通俗地講，發(fā)送時(shí)，用戶先請(qǐng)求提供者，然后提供者發(fā)送，再向用戶確認(rèn)；接收時(shí)，提供者通知用戶，如下圖6。當(dāng)信息經(jīng)過LLC或MAC傳輸，即發(fā)送或者接收，同樣地遵循上述的規(guī)則，所以在此先介紹這三條服務(wù)原語(yǔ)，為后續(xù)LLC和MAC的描述做鋪墊。

圖6 服務(wù)原語(yǔ)的使用示意

2）LLC子層

LLC子層提供兩種無(wú)連接模式傳輸服務(wù)，分別為Unknowledged data transfer service和Unacknowledged remote data request service，這里我們就關(guān)注前者，對(duì)于這種服務(wù)會(huì)使用LLC data frame，用來(lái)發(fā)送和接收。

根據(jù)上述服務(wù)原語(yǔ)的描述，我們知道發(fā)送數(shù)據(jù)時(shí)，LLC用戶傳輸數(shù)據(jù)給LLC子層，并請(qǐng)求LLC子層發(fā)送，當(dāng)LLC子層發(fā)送數(shù)據(jù)后，向LLC用戶確認(rèn)發(fā)送狀態(tài)。當(dāng)接收數(shù)據(jù)時(shí)，LLC子層通知LLC用戶有數(shù)據(jù)到達(dá)。這里每條服務(wù)原語(yǔ)對(duì)數(shù)據(jù)有怎樣的規(guī)定呢？下圖7做了清晰的定義。

圖7 LLC子層服務(wù)原語(yǔ)，引自[2]

到此我們就知道了LLC子層的發(fā)送與接收過程。另外，LLC子層可以與對(duì)等的LLC實(shí)體交換數(shù)據(jù)單元的，也就是交換LLC數(shù)據(jù)幀。

圖8 LLC子層的數(shù)據(jù)傳輸類型

一個(gè)LLC數(shù)據(jù)幀由3個(gè)位段（bit field）組成，即id，長(zhǎng)度和數(shù)據(jù)3段，基本對(duì)應(yīng)于上篇文章的CAN協(xié)議幀的三段，其中id段稍有不同，它包含3個(gè)部分：基本id，擴(kuò)展flag和擴(kuò)展id，但在MAC子層會(huì)將id段處理成CAN協(xié)議幀的id段格式。

圖9 LLC數(shù)據(jù)幀，引自[2]

3）MAC子層

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

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

與上述LLC子層同樣的思路，LLC與MAC間的數(shù)據(jù)傳輸使用的服務(wù)原語(yǔ)如下所示：

圖11 MAC子層的數(shù)據(jù)傳輸類型，引自[2]

圖12 MAC子層服務(wù)原語(yǔ)6

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

圖13 MAC數(shù)據(jù)幀結(jié)構(gòu)，引自[2]

對(duì)于發(fā)送部分，MAC子層要實(shí)現(xiàn)：數(shù)據(jù)打包和發(fā)送介質(zhì)訪問管理。

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

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

對(duì)于接收部分：MAC子層要實(shí)現(xiàn)：接收介質(zhì)訪問管理和數(shù)據(jù)解包。

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

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

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

圖16 位填充，引自[4]

---

通過上面的內(nèi)容，我們就了解了CAN協(xié)議幀的由來(lái)，按照OSI參考模型來(lái)分層CAN通訊架構(gòu)，CAN協(xié)議幀具體在哪層使用，如何使用（當(dāng)然以上內(nèi)容也將為后續(xù)的CAN通訊軟件實(shí)現(xiàn)做了鋪墊）。而且我們也知道CAN協(xié)議幀最終CAN接口器件來(lái)實(shí)現(xiàn)，那么具體是怎么通過硬件來(lái)實(shí)現(xiàn)？

4.3 CAN協(xié)議幀的相關(guān)寄存器

從基于AUTOSAR架構(gòu)的軟件開發(fā)，一般會(huì)涉及到與CAN協(xié)議幀有關(guān)的幾種寄存器，比如與id對(duì)應(yīng)的寄存器，與數(shù)據(jù)對(duì)應(yīng)的寄存器和與長(zhǎng)度對(duì)應(yīng)的寄存器。也就是說通過對(duì)寄存器的了解，就可以很清楚地明白CAN協(xié)議幀是怎么通過硬件（寄存器）實(shí)現(xiàn)的。下面分別通過Infineon和NXP 飛思卡爾的用戶手冊(cè)稍作了解。

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

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

下圖18為Infineon的數(shù)據(jù)寄存器（低位）的定義。

圖18 數(shù)據(jù)寄存器（低位），引自[5]

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

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

NXP的用戶手冊(cè)中定義的CAN協(xié)議幀的寄存器如下圖20：

圖20 CAN協(xié)議幀相關(guān)的寄存器，引自[6]

下圖21為NXP的標(biāo)識(shí)符寄存器定義：

圖21 標(biāo)識(shí)符寄存器，引自[6]

下圖22為NXP的數(shù)據(jù)段寄存器定義：

圖22 數(shù)據(jù)段寄存器，引自[6]

下圖23為NXP的數(shù)據(jù)長(zhǎng)度寄存器定義：

圖23 數(shù)據(jù)長(zhǎng)度寄存器，引自[6]

CAN協(xié)議幀就這樣通過寄存器來(lái)實(shí)現(xiàn)：發(fā)送時(shí)，從軟件寫入到寄存器（硬件）；接收時(shí)，從寄存器讀取到軟件。

4.4 整車控制器CAN通信報(bào)文與CAN協(xié)議幀

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

圖24 整車控制器報(bào)文示意

也就是說整車控制器CAN通信報(bào)文首先必須基于CAN協(xié)議幀來(lái)定義的，其次它賦予每一條CAN協(xié)議幀的實(shí)際意義，即不同id的幀數(shù)據(jù)段代表著不同的物理意義。當(dāng)然這些并不在物理層和數(shù)據(jù)鏈路層實(shí)現(xiàn)，而是在應(yīng)用層來(lái)實(shí)現(xiàn)，也就是通過軟件實(shí)現(xiàn)物理層數(shù)據(jù)的解析。

---

到此我們就了解到了與CAN協(xié)議幀相關(guān)的協(xié)議標(biāo)準(zhǔn)，寄存器和整車控制器CAN通信報(bào)文。基于這些內(nèi)容就基本可以實(shí)現(xiàn)一個(gè)簡(jiǎn)單版的CAN通訊功能，即接收功能：從讀取相關(guān)寄存器的數(shù)據(jù)，最終傳給應(yīng)用層，將數(shù)據(jù)解析成具有意義的信號(hào)；發(fā)送功能：將應(yīng)用層信號(hào)轉(zhuǎn)換成規(guī)定的數(shù)據(jù)形式發(fā)送，寫入寄存器，再向應(yīng)用層確認(rèn)。

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

Reference:

[1] 汽車CAN總線協(xié)議規(guī)范-深圳速銳得科技有限公司-國(guó)六OBD在線監(jiān)測(cè) |遠(yuǎn)程排放管理終端|CANBUS總線開發(fā)|汽車總線數(shù)據(jù)應(yīng)用

[2] ISO 11989-1

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

[4] CAN入門書

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

[6] MC9S08DZ60 HCS08微控制器

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。