tms570 can 接收大量数据_CAN通讯系列--CAN总线基础3
上篇文章講述了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)。
對(duì)于接收部分:MAC子層要實(shí)現(xiàn):接收介質(zhì)訪問管理和數(shù)據(jù)解包。
- 接收介質(zhì)訪問管理,包括:從物理層接收一串位流;刪除填充的位;發(fā)送ACK等。
- 數(shù)據(jù)解包,包括:移除數(shù)據(jù)幀的MAC特定信息;把LLC數(shù)據(jù)幀和接口控制信息給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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: python webdriver点击指令
- 下一篇: pgsql 两个时间字段相减_如何在Ex