CAN總線的編碼方式_第1頁
CAN總線的編碼方式_第2頁
CAN總線的編碼方式_第3頁
免費預(yù)覽已結(jié)束,剩余1頁可下載查看

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、對CAN息、線的常見編碼格式解析我們在進行CAN總線的通訊設(shè)計過程中,對丁通訊矩陣的建立,我們常常會選擇一種編碼方式,最常見的編碼格式是Intel格式和Motorola格式。但是往往人們都是以一種習(xí)慣去選擇,究竟兩種格式具體的區(qū)別在哪里呢?我們需要明白兩種格式對信號是如何排布的,乂是按照什么順序進行正確解析的。本篇文章就是作者根據(jù)在整理通訊矩陣和dbc文件中遇到的一些問題,提出的自己的一些體會和見解,希望大家通過此篇文章對兩種格式有更加深刻的理解。我們在設(shè)計初期,都會首先選擇一種編碼格式,這種選擇大多都是根據(jù)設(shè)計者自己的習(xí)慣,具體Intel格式和Motorola格式哪個更有優(yōu)勢的問題,在這里沒

2、有區(qū)別。但是就使用者而言,需要對接收到數(shù)據(jù)幀進行正確的解析,否則就無法得到想要的信號。下面我們就來說一下兩種格式的區(qū)別。首先我們需要明確一點,無論是Intel格式還是Motorola格式,在每個字節(jié)中,數(shù)據(jù)傳輸順序都是從高位msR傳向低位lsb。如下列圖所示。bytexbit(8*x+7)bit(8*x)msblsb注:x=0,1,2,3-7圖1一般主機廠設(shè)計人員在設(shè)計初期都會定義好字節(jié)的發(fā)送順序,定義Byte0為LS己Byte7為MSB第一種情況:先發(fā)送Byte0,然后Byte1到Byte7;第二種情況:先發(fā)送Byte7,然后Byte6到Byte0。根據(jù)我了解到的大部分主機廠都會采取第一種發(fā)

3、送方法,很少會采取后者。我們在用CANo寸的CANdb+編輯數(shù)據(jù)庫時,肯定會用到如下歹0圖所示的編輯界面。圖2結(jié)合工作中的出現(xiàn)的問題,有的網(wǎng)絡(luò)設(shè)計者會在排布信號的時候出現(xiàn)誤區(qū)。上圖中用的是比較常規(guī)的排布方式,即位在字節(jié)中的索引是從右至左,還有一種是顛倒過來的,即從左至右。如下列圖所示。0123458701234587089W11121J111151161?W19'2Q21222322425262?_'25293031332333435363738394叫414243444546475495。51525355&56575859知61日2G37圖3我們現(xiàn)在以第一種矩陣模式進

4、行說明。在這種情況下,如果主機廠在初期定義先發(fā)送LS己再發(fā)送的MSB勺形式,那么數(shù)據(jù)信號可以按照從上到下,從左到右的順序發(fā)送,非常方便,接收器解析起來也比較容易。如果主機廠定義先發(fā)送MSES發(fā)送LSB的形式,那樣數(shù)據(jù)傳輸比較復(fù)雜,所以一般都不建議用這種方案。至丁設(shè)計者常出現(xiàn)的錯誤我們在下文中會重點說明,下面我們先了解一下Intel格式和Motorola格式在CANdb+中的區(qū)別。、Motorola編碼格式:如果我們選擇使用Motorola編碼格式,那需要知道它在CANdb+中的3種信號排布方式。這三種排布的主要區(qū)別在丁它們的起始位不同。我們假設(shè)一個信號的位長為12,那么它就要跨字節(jié)排布。在Mo

5、torola格式中的第一種排布形式為MotorolaForwardLSB,即從小端開始,它的起始位為lsb16;第二種排布形式為MotorolaForwardMSB,即從大端開始,它的起始位為msb11;第三種排布形式為MotorolaBackward,它的起始位為第8位,這種形式基本不采用,因為排布規(guī)律相對丁前兩種比較復(fù)雜。如下歹U圖所示;765432100msb-1lsb23圖4針對上述Motorola格式第一種排布形式,信號的起始位為高字節(jié)的低位。在CANdb+的具體表達如下圖。圖5在CANdb+中,無法區(qū)別這三種排布形式,它的起始位也是自動定義的,所以我們在設(shè)計通訊矩陣時,一般都會采用

6、第一種,即MotorolaForwardLSB。只是有的工程帥根據(jù)自己的個人習(xí)慣,去改變起始位,但我們需要明確一點就是,在Canoe軟件中,一種格式的信號排布是沒有區(qū)別的。二、Intel編碼格式如果我們選擇使用Intel編碼格式,它在CANdb+中也有兩種信號排布方式。我們假設(shè)一個信號位長為12,它也是要跨字節(jié)排布。第一種排布形式為IntelStandard,即標準形式,它的起始位為lsb12。信號的起始位為低字節(jié)的低位。如下列圖所示:16543210<-lsb一Lo12圖6圖7第二種排布形式為IntelSequential,即順序排布形式或者叫顛倒排布。這種形式不太常用,但我們也需要了

7、解,它的起始位為lsb11。如下列圖所示:01234570<-lsb1msb,一一-一一、23圖8以上文字介紹了當信號的位長超過一個字節(jié)的情況下,信號分別以Motorola編碼格式和Intel編碼格式排布時的區(qū)別。我們現(xiàn)在假設(shè)一個信號的位長為4,觀察在CANdb+中信號的排布有什么區(qū)別。Motorola編碼格式下的信號排布:綠色信號圖9Intel編碼格式下的信號排布:綠色信號VrdfFi.十亍-|I-“r一一一.圖10由圖可知,兩種格式的起始位不同,但是他們的排布方式相同,都是信號的高位放在該字節(jié)的高位msR,信號的低位放在該字節(jié)的低位lsb。所以,當一個信號的位長小丁8時,那么兩種編碼

8、格式?jīng)]有區(qū)別。如果信號的位長大丁8,那么兩種編碼格式將會產(chǎn)生很大差異。這是我們在網(wǎng)絡(luò)通訊設(shè)計初期必須要掌握的。下面我們說一下一些工程師在做通訊矩陣的設(shè)計時,常會出現(xiàn)的幾個問題:1. 在編寫通訊矩陣時,在起始位的編寫中,常會將Intel格式和Motorola格式弄混。例如:如下列圖所示的通訊矩陣位艦序bitorderMSBTTTiffT-kTLSB字節(jié)順序13yteorderbit7bitebit5bit4bit3bit2bit1bitO!MSBByte0165431IByte115141211g8IByte2|2322_21201918;17_risJByte3131"3029282

9、72625244Byte43938373635343332JByte54746454443424140Byte55554535251504948LSBByte?63:626160595857P56如果一個信號的位長為4,那么假設(shè)是Motorola編碼格式,那它的起始位就是4;而假設(shè)是Intel編碼格式,那它的起始位就是0。2. 在CANdb+中進行通訊矩陣的調(diào)整時,首先應(yīng)明確信號選取的編碼格式,然后進行拖曳,有的工程師常常在沒有區(qū)分編碼格式,憑借主觀感覺對通訊矩陣進行調(diào)整,這往往會導(dǎo)致信號的傳輸錯誤。3. 在信號跨字節(jié)排布中,未明確msb和lsb,在拖曳過程中會出現(xiàn)錯誤。綜上所述,Motoro

10、la編碼格式和Intel編碼格式主要區(qū)別還是在信號位長大于8或者信位長不超過8但是跨字節(jié)的情況下,前者的規(guī)則:該信號的高位S_msb將被放在低字節(jié)MSB的高位,信號的低位S_lsb將被放在高字節(jié)LSB5的低位;后者的規(guī)則:該信號的高位S_msB將被放在高字節(jié)MSB的高位,信號的低位S_lsb將被放在低字節(jié)LSE8的低位。希望大家能從此篇文章中收獲一些經(jīng)驗。文中術(shù)語解釋及定義:信號的高位,即最能表達信號特性的因子,比方:車速信號500km/h按照給定的公式,轉(zhuǎn)換成十六進制數(shù)為0x6A5,因為6代表的數(shù)量級最大162,那么其中6就是其信號的高位。信號的低位,即最不能表達信號特性的因子,比方:車速信號500km/h按照

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論