CAN總線入(ru)門如此簡單
時(shi)間：2018-03-15 來源：can總線原(yuan)理(li)入(ru)門(men)
很難找(zhao)到一篇能夠(gou)適合初學者CAN總線原理(li)的(de)文章，因此(ci)小編本著通俗易懂的(de)原則編寫此(ci)文!
什(shen)么(me)是CAN總線?
CAN總線應用于汽車，實現電(dian)子控制器和傳(chuan)感器之間的通(tong)信
Ø 高可靠性、低(di)成本(ben)的通信(xin)協(xie)議。
Ø 最初由Robert Bosch于1986年(nian)開發。
Ø 主要(yao)應用于汽車、卡車、拖拉機、工業機器人(ren)。
想象一(yi)下，一(yi)輛汽車就像一(yi)個人：
Ø CAN總線(xian)是(shi)神經系(xi)統，使身體各(ge)部分之間(jian)的通信得以實(shi)現。
Ø ECU通過CAN總線連(lian)接，該總線相當(dang)于一個中央網(wang)絡系(xi)統。
什么(me)是ECU?
Ø 在汽車(che)CAN總線系(xi)(xi)統中(zhong)，ECUs可以是發動機控制單元、安全氣囊或音(yin)頻系(xi)(xi)統。
Ø 一輛現代汽車(che)最多可以有(you)70輛ECUs。
CAN總線5大特性(xing)
Ø 低(di)成(cheng)本：ECUs通過單個CAN接口進行通信(xin)，布(bu)線成(cheng)本低(di)。
Ø 高集(ji)成：CAN總線(xian)系(xi)統(tong)允許在所(suo)有(you)ECUs上進行集(ji)中錯誤診斷和配(pei)置(zhi)。
Ø 可(ke)靠(kao)性：該系統對子系統的故障和電磁(ci)干擾具(ju)有(you)很強的魯棒性，是(shi)汽車控制(zhi)系統的理想(xiang)選擇。
Ø 高(gao)(gao)效率：可以(yi)通過(guo)id對消息進行(xing)優先級排序，以(yi)便最(zui)高(gao)(gao)優先級的(de)id不被中(zhong)斷。
Ø 靈活性：每個ECU包含一個用于CAN總(zong)線(xian)收發(fa)芯片，隨意(yi)添加CAN總(zong)線(xian)節點。
CAN總線發展(zhan)史(shi)
Ø 未出現前：汽(qi)車ECUs依靠越(yue)來越(yue)復雜(za)的點對點布線。
Ø 1986年：Bosch公司開發了(le)CAN總線協議作為汽(qi)車電(dian)子解決方案，并在SAE大會上發布。
Ø 1991年：Bosch公(gong)司發布了CAN2.0，包涵(han)CAN 2.0A (11 位) 和CAN 2.0B (29 位)。
Ø 1993年：CAN總(zong)線列入(ru)國際標準(ISO 11898)。
Ø 2012年(nian)：Bosch公司發布了CAN FD 1.0
Ø 今天：幾乎(hu)每(mei)一輛汽車(che)都有CAN總線系統，它廣(guang)泛(fan)應(ying)用于(yu)卡車(che)、公共汽車(che)、工業車(che)輛、船舶、飛機和工業自(zi)動化。
CAN總線的(de)未來
展望未來，CAN總線(xian)將繼續(xu)前行——而且(qie)更有可能是隨著(zhu)云(yun)計算、物聯網和自動駕(jia)駛汽車的興起。這些趨勢還(huan)將增(zeng)加可以使用WiFi /蜂(feng)窩網絡連接的CAN總線(xian)的需求——允許無線(xian)傳輸的CAN總線(xian)數(shu)據，例如(ru)云(yun)服務器(qi)。
為了(le)實(shi)現這一(yi)目標，CAN FD將(jiang)是一(yi)個關鍵(jian)的(de)(de)組成部分。基本上，今天的(de)(de)CAN總線系統面臨(lin)一(yi)個主要的(de)(de)障礙:1 Mbit/s的(de)(de)速度(du)限制隨著數(shu)據速度(du)的(de)(de)復(fu)雜性和需求的(de)(de)增加(更多的(de)(de)ECUs，數(shu)據)，這是一(yi)個越來越大的(de)(de)挑戰。
Ø CAN FD提(ti)供兩個關鍵的指標：
n 數(shu)據傳輸速(su)率達到8Mbit/s——遠遠超出(chu)常規的1Mbit/s。
n 64字節的數據包——而不(bu)是8字節。
CAN總線物理(li)結構與特性
CAN總線網絡
CAN總(zong)線網絡主(zhu)要(yao)掛在CAN_H和(he)CAN_L，各(ge)個節點通(tong)過這兩條線實現(xian)信號的(de)串行差(cha)分傳(chuan)輸，為了(le)避(bi)免信號的(de)反射和(he)干擾，還需要(yao)在CAN_H和(he)CAN_L之間接上120歐姆(mu)的(de)終端電阻(zu)，但是(shi)為什么是(shi)120歐姆(mu)呢(ni)?那是(shi)因為電纜的(de)特性阻(zu)抗為120歐。
CAN收發器
CAN收(shou)發器的作用(yong)是負責邏(luo)輯電平和信號(hao)電平之間的轉換(huan)。
即從CAN控制芯(xin)片輸出邏輯(ji)電平(ping)到CAN收發器，然(ran)后經(jing)過CAN收發器內部轉(zhuan)換將邏輯(ji)電平(ping)轉(zhuan)換為差分信號輸出到CAN總線(xian)上，CAN總線(xian)上的(de)節點都可以決(jue)定(ding)自(zi)己是否需(xu)要總線(xian)上的(de)數(shu)據。具體的(de)管教定(ding)義如(ru)下：
CAN信號表示(shi)
CAN總線采用(yong)不歸(gui)零碼位填(tian)充技術(shu)，也(ye)就是(shi)說CAN總線上的信號有兩種不同的信號狀態，分別是(shi)顯性(xing)的(Dominant)邏(luo)(luo)輯(ji)0和隱形(xing)的(recessive)邏(luo)(luo)輯(ji)1，信號每一次傳輸完后不需要返回到邏(luo)(luo)輯(ji)0(顯性(xing))的電平。
CAN收發(fa)器有TXD，RXD是與(yu)CAN控(kong)制器連接的(de)(de)。發(fa)送器接到網(wang)絡(luo)的(de)(de)是CL和(he)CH。CL與(yu)CH是差(cha)分電(dian)路。CAN網(wang)絡(luo)上是用CL于CH的(de)(de)電(dian)壓(ya)差(cha)來表示(shi)邏(luo)(luo)輯(ji)“0”和(he)邏(luo)(luo)輯(ji)“1”。所以CAN網(wang)絡(luo)中只能單向傳輸(shu)。
CAN仲裁
只(zhi)要(yao)總線(xian)空閑，總線(xian)上任何(he)節(jie)點都(dou)可(ke)以發送報文(wen)，如果有兩個(ge)(ge)或兩個(ge)(ge)以上的節(jie)點開始傳送報文(wen)，那么就會存在總線(xian)訪問沖突的可(ke)能。但是CAN使用了標識(shi)符的逐位仲裁方法可(ke)以解決這個(ge)(ge)問題。
在(zai)仲(zhong)(zhong)裁期間，每一個(ge)發送(song)器都對(dui)發送(song)的(de)(de)電平(ping)(ping)與被監(jian)控的(de)(de)總線(xian)電平(ping)(ping)進行(xing)比較。如(ru)果電平(ping)(ping)相同(tong)，則這(zhe)個(ge)單元可以繼續發送(song)。如(ru)果發送(song)的(de)(de)是一"隱性"電平(ping)(ping)而(er)監(jian)視到的(de)(de)是一"顯性"電平(ping)(ping)，那么這(zhe)個(ge)節(jie)點失去了仲(zhong)(zhong)裁，必須退出(chu)發送(song)狀態。如(ru)果出(chu)現不(bu)匹配的(de)(de)位不(bu)是在(zai)仲(zhong)(zhong)裁期間則產生錯(cuo)誤(wu)事件(jian)。
幀ID越(yue)小，優(you)(you)先級越(yue)高。由于數據(ju)(ju)幀的(de)RTR位為顯性(xing)電平(ping)(ping)，遠程(cheng)幀為隱性(xing)電平(ping)(ping)，所以幀格式和(he)幀ID相同(tong)的(de)情況(kuang)下(xia)，數據(ju)(ju)幀優(you)(you)先于遠程(cheng)幀;由于標準幀的(de)IDE位為顯性(xing)電平(ping)(ping)，擴展幀的(de)IDE位為隱形電平(ping)(ping)，對(dui)于前(qian)11位ID相同(tong)的(de)標準幀和(he)擴展幀，標準幀優(you)(you)先級比擴展幀高。
CAN總線(xian)通信協議
協議格式
| 序號 | 名稱 | 位 | 描述 |
| 1 | SOF | 1 | 起始位，邏輯0使能，告訴其他ECU，消息即將到達。 |
| 2 | CAN-ID | 29 | 消息標識符，值越低優先級越高 |
| 3 | RTR | 1 | 遠程傳輸請求標志位，允許ECUs“請求”來自其他ECUs的消息。 |
| 4 | Control | 6 | 數據包長度 |
| 5 | Data | 0-64 | 數據內容 |
| 6 | CRC | 16 | 16位循環冗余校驗用于保證數據的完整性 |
| 7 | ACK | 2 | 應答標志，CRC是否校驗正確 |
| 8 | EOF | 7 | 結束標識符 |
如何解析
下面是使(shi)用CANLoggerX000的(de)汽車的(de)一個示例日志文件(jian):
# Logger type: CANLogger2000
# HW rev: 6.xx
# FW rev: 5.51
# Logger ID: ID0001
# Session No.: 9
# Split No.: 3
# Time: 20170508T064128
# Value separator: ";"
# Time format: 4
# Time separator: ""
# Time separator ms: ""
# Date separator: ""
# Time and date separator: "T"
# Bit-rate: 500000
# Silent mode: false
# Cyclic mode: false
Timestamp;Type;ID;Data
08T064254150;0;34d;1003fafa000d00ff
如(ru)果(guo)我們查看上(shang)面的原始(shi)CAN總線(xian)數據(ju)樣(yang)本，可能(neng)會注意到:
原(yuan)始的CAN總線數據沒有意義!
這是因為我們需要將數據轉換(huan)成按比例(li)計算(suan)的(de)工程值(zhi)——也就是人類可讀的(de)形式。
要做(zuo)到這(zhe)一點，我(wo)們需要知道一些事(shi)情(qing):
例(li)如(ru)，在34d中(zhong)的(de)64位數據中(zhong)，可能會(hui)有(you)3個不(bu)同參數的(de)數據，每個參數都有(you)一個特定的(de)起(qi)始點和位長。
針對這3個不同參數的數據，我們(men)需要(yao)要(yao)知(zhi)道如何解碼：
每個(ge)參(can)數都需要偏(pian)移量(liang)和刻度值
[數據值]=[偏(pian)移]+[刻度(du)]x[原始數據值]
