CAN總線入門如此簡單
時間：2018-03-15 來源：can總線原理入門
很難找到一篇能夠適合初學者CAN總線原理的文章，因此小編本著通俗易懂的原則編寫此文!
什么是CAN總線?
CAN總線應用于汽車，實現電子控制器和傳感器之間的通信
Ø 高可靠性、低成本的通信協議。
Ø 最初由Robert Bosch于1986年開發。
Ø 主要應用于汽車、卡車、拖拉機、工業機器人。
想象一下，一輛汽車就像一個人：
Ø CAN總線是神經系統，使身體各部分之間的通信得以實現。
Ø ECU通過CAN總線連接，該總線相當于一個中央網絡系統。
什么是ECU?
Ø 在汽車CAN總線系統中，ECUs可以是發動機控制單元、安全氣囊或音頻系統。
Ø 一輛現代汽車最多可以有70輛ECUs。
CAN總線5大特性
Ø 低成本：ECUs通過單個CAN接口進行通信，布線成本低。
Ø 高集成：CAN總線系統允許在所有ECUs上進行集中錯誤診斷和配置。
Ø 可靠性：該系統對子系統的故障和電磁干擾具有很強的魯棒性，是汽車控制系統的理想選擇。
Ø 高效率：可以通過id對消息進行優先級排序，以便最高優先級的id不被中斷。
Ø 靈活性：每個ECU包含一個用于CAN總線收發芯片，隨意添加CAN總線節點。
CAN總線發展史
Ø 未出現前：汽車ECUs依靠越來越復雜的點對點布線。
Ø 1986年：Bosch公司開發了CAN總線協議作為汽車電子解決方案，并在SAE大會上發布。
Ø 1991年：Bosch公司發布了CAN2.0，包涵CAN 2.0A (11 位) 和CAN 2.0B (29 位)。
Ø 1993年：CAN總線列入國際標準(ISO 11898)。
Ø 2012年：Bosch公司發布了CAN FD 1.0
Ø 今天：幾乎每一輛汽車都有CAN總線系統，它廣泛應用于卡車、公共汽車、工業車輛、船舶、飛機和工業自動化。
CAN總線的未來
展望未來，CAN總線將繼續前行——而且更有可能是隨著云計算、物聯網和自動駕駛汽車的興起。這些趨勢還將增加可以使用WiFi /蜂窩網絡連接的CAN總線的需求——允許無線傳輸的CAN總線數據，例如云服務器。
為了實現這一目標，CAN FD將是一個關鍵的組成部分。基本上，今天的CAN總線系統面臨一個主要的障礙:1 Mbit/s的速度限制隨著數據速度的復雜性和需求的增加(更多的ECUs，數據)，這是一個越來越大的挑戰。
Ø CAN FD提供兩個關鍵的指標：
n 數據傳輸速率達到8Mbit/s——遠遠超出常規的1Mbit/s。
n 64字節的數據包——而不是8字節。
CAN總線物理結構與特性
CAN總線網絡
CAN總線網絡主要掛在CAN_H和CAN_L，各個節點通過這兩條線實現信號的串行差分傳輸，為了避免信號的反射和干擾，還需要在CAN_H和CAN_L之間接上120歐姆的終端電阻，但是為什么是120歐姆呢?那是因為電纜的特性阻抗為120歐。
CAN收發器
CAN收發器的作用是負責邏輯電平和信號電平之間的轉換。
即從CAN控制芯片輸出邏輯電平到CAN收發器，然后經過CAN收發器內部轉換將邏輯電平轉換為差分信號輸出到CAN總線上，CAN總線上的節點都可以決定自己是否需要總線上的數據。具體的管教定義如下：
CAN信號表示
CAN總線采用不歸零碼位填充技術，也就是說CAN總線上的信號有兩種不同的信號狀態，分別是顯性的(Dominant)邏輯0和隱形的(recessive)邏輯1，信號每一次傳輸完后不需要返回到邏輯0(顯性)的電平。
CAN收發器有TXD，RXD是與CAN控制器連接的。發送器接到網絡的是CL和CH。CL與CH是差分電路。CAN網絡上是用CL于CH的電壓差來表示邏輯“0”和邏輯“1”。所以CAN網絡中只能單向傳輸。
CAN仲裁
只要總線空閑，總線上任何節點都可以發送報文，如果有兩個或兩個以上的節點開始傳送報文，那么就會存在總線訪問沖突的可能。但是CAN使用了標識符的逐位仲裁方法可以解決這個問題。
在仲裁期間，每一個發送器都對發送的電平與被監控的總線電平進行比較。如果電平相同，則這個單元可以繼續發送。如果發送的是一"隱性"電平而監視到的是一"顯性"電平，那么這個節點失去了仲裁，必須退出發送狀態。如果出現不匹配的位不是在仲裁期間則產生錯誤事件。
幀ID越小，優先級越高。由于數據幀的RTR位為顯性電平，遠程幀為隱性電平，所以幀格式和幀ID相同的情況下，數據幀優先于遠程幀;由于標準幀的IDE位為顯性電平，擴展幀的IDE位為隱形電平，對于前11位ID相同的標準幀和擴展幀，標準幀優先級比擴展幀高。
CAN總線通信協議
協議格式
| 序號 | 名稱 | 位 | 描述 |
| 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 | 結束標識符 |
如何解析
下面是使用CANLoggerX000的汽車的一個示例日志文件:
# 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
如果我們查看上面的原始CAN總線數據樣本，可能會注意到:
原始的CAN總線數據沒有意義!
這是因為我們需要將數據轉換成按比例計算的工程值——也就是人類可讀的形式。
要做到這一點，我們需要知道一些事情:
例如，在34d中的64位數據中，可能會有3個不同參數的數據，每個參數都有一個特定的起始點和位長。
針對這3個不同參數的數據，我們需要要知道如何解碼：
每個參數都需要偏移量和刻度值
[數據值]=[偏移]+[刻度]x[原始數據值]
