議入門：從物理層仲裁機制到STM32實戰(zhàn))
嵌入式項目做到一定階段總會遇到“多設(shè)備通信”的需求。串口簡單直接但點對點通信不夠靈活I(lǐng)2C / SPI 適合板內(nèi)通信距離一遠(yuǎn)就不太合適RS485 能組網(wǎng)但主從輪詢模式下節(jié)點多了之后實時性很難保證。這時候CAN 總線往往是最合適的選擇。本文是嵌入式入門系列的第七講主題是 CAN 總線協(xié)議。我會從協(xié)議解決什么問題講起依次分析物理層電平、幀結(jié)構(gòu)、仲裁機制、波特率配置最后給出一個基于 STM32 的 CAN 收發(fā)工程示例以及常見故障排查思路。學(xué)完之后你應(yīng)該能獨立讀懂 CAN 報文理解為什么兩根差分線能掛在幾十個節(jié)點并能完成兩個節(jié)點之間的 CAN 通信調(diào)試。1. 為什么嵌入式開發(fā)要學(xué) CAN 總線協(xié)議1.1 CAN 總線到底解決了什么問題CAN 是 Controller Area Network 的縮寫翻譯過來就是“控制器局域網(wǎng)”。它最早由 BOSCH 公司提出后來形成了 ISO 11898 系列標(biāo)準(zhǔn)主要面向汽車電子和工業(yè)控制場景。在沒有 CAN 的早期汽車中每個傳感器、控制器之間要通過大量線束點對點連接。車上有幾十個 ECU每個 ECU 又可能需要多個傳感器信號線束數(shù)量會急劇膨脹不僅成本高而且故障排查困難。CAN 總線的作用就是讓所有控制器共享同一對差分線通過統(tǒng)一的報文機制交換數(shù)據(jù)從而大幅減少線束。從軟件角度看CAN 不是簡單的“兩個設(shè)備之間傳數(shù)據(jù)”而是解決了一組問題多主通信總線上任何一個節(jié)點都可以主動發(fā)起發(fā)送不需要主機統(tǒng)一調(diào)度。多節(jié)點互聯(lián)一條總線上可以掛幾十個節(jié)點理論上受 CAN 收發(fā)器驅(qū)動能力和協(xié)議尋址限制。實時性保障協(xié)議自帶優(yōu)先級仲裁高優(yōu)先級報文可以搶占總線?？煽啃员Ｕ蠀f(xié)議自帶 CRC 校驗、幀格式檢查、ACK 確認(rèn)和錯誤重發(fā)機制。這些特性決定了 CAN 很適合作為汽車、工業(yè)現(xiàn)場、醫(yī)療設(shè)備、工程機械等場景的骨干通信總線。1.2 CAN 與 UART、I2C、SPI、RS485 的定位差異初學(xué)者最常問的一個問題是CAN 和串口、RS485 到底有什么區(qū)別下面把常見總線的定位做一個簡單對比?？偩€類型通信模式節(jié)點數(shù)量距離實時性典型場景UART單主單從2短無仲裁調(diào)試口、模塊通信I2C單主多從多板級主從輪詢板內(nèi)傳感器、存儲芯片SPI單主多從多板級主從輪詢Flash、屏幕、ADCRS485一主多從多長主從輪詢工業(yè)儀表、PLC 通信CAN多主多從多中長硬件仲裁汽車 ECU、工業(yè)控制從表中能看出RS485 和 CAN 都是差分信號抗干擾能力都比較強但兩者有一個關(guān)鍵差異RS485 在同一時刻只能有一個節(jié)點發(fā)送數(shù)據(jù)沒有硬件級仲裁通常依賴主站輪詢或令牌機制CAN 則允許節(jié)點同時開始發(fā)送由協(xié)議在物理層自動仲裁優(yōu)先級低的節(jié)點自動退出發(fā)送并且不破壞高優(yōu)先級報文的完整性。所以如果你需要一套“多個節(jié)點都能主動上報、實時性要求高、數(shù)據(jù)量不大”的通信系統(tǒng)CAN 比 RS485 更合適。1.3 CAN 的典型應(yīng)用場景CAN 的應(yīng)用范圍很廣下面幾個場景比較典型汽車電子發(fā)動機 ECU、變速箱、ABS、車身控制器、儀表盤、BMS 電池管理之間的通信。傳統(tǒng)汽車和電動車都在大量使用 CAN。工業(yè)控制傳感器、伺服驅(qū)動器、PLC 之間的現(xiàn)場總線通信。無人機與機器人飛控、電調(diào)、云臺之間傳輸控制指令和狀態(tài)信息很多飛控內(nèi)部或外界擴(kuò)展總線用的就是 CAN。醫(yī)療設(shè)備手術(shù)臺、監(jiān)護(hù)儀、影像設(shè)備等內(nèi)部模塊通信利用 CAN 的可靠性和錯誤檢測能力。軌道交通、船舶、農(nóng)用機械等可靠性要求較高的場景。即使你當(dāng)前做的是嵌入式 Linux 應(yīng)用開發(fā)、單片機裸機開發(fā)或者嵌入式測試方向CAN 協(xié)議都可能出現(xiàn)在項目需求里。這也是它成為嵌入式面試高頻考點的原因之一。2. CAN 總線整體架構(gòu)與核心機制2.1 物理層與數(shù)據(jù)鏈路層CAN 協(xié)議體系可以粗略分成兩層物理層和數(shù)據(jù)鏈路層。物理層定義了信號電平、傳輸介質(zhì)、線束接口和終端電阻。最常用的是高速 CAN兩條信號線分別叫作 CAN_H 和 CAN_L使用差分電壓傳輸靜態(tài)時兩條線電壓接近邏輯上表示為隱性Recessive傳輸顯性Dominant電平時CAN_H 被拉高CAN_L 被拉低。數(shù)據(jù)鏈路層則定義了報文如何組幀、如何仲裁、如何校驗、如何錯誤重發(fā)。對寫代碼的工程師來說數(shù)據(jù)鏈路層是最需要下功夫的部分因為協(xié)議芯片或 MCU 內(nèi)部 CAN 控制器已經(jīng)做了大部分底層工作我們平時操作的就是數(shù)據(jù)鏈路層的收發(fā)接口。2.2 顯性與隱性電平的“線與”原理CAN 總線邏輯電平不是簡單的高電平為 1、低電平為 0。協(xié)議里面隱性電平對應(yīng)邏輯 1表示“釋放總線”。顯性電平對應(yīng)邏輯 0表示“占用總線”。關(guān)鍵規(guī)則是“線與”當(dāng)總線上多個節(jié)點同時發(fā)送只要有一個節(jié)點輸出顯性電平總線上就是顯性電平只有當(dāng)所有節(jié)點都輸出隱性電平總線才表現(xiàn)為隱性。舉個例子。節(jié)點 A 發(fā)送隱位“1”節(jié)點 B 發(fā)送顯位“0”總線上的結(jié)果是顯位“0”。這個特性的直接意義是發(fā)送節(jié)點在發(fā)送的每一個位周期內(nèi)都能實時回讀總線電平一旦發(fā)現(xiàn)“我發(fā)的是隱性但總線讀到顯性”就知道有其他更高優(yōu)先級的節(jié)點正在發(fā)送于是本節(jié)點自動停止發(fā)送。正是因為有了這種機制CAN 才能在不需要主機調(diào)度的情況下實現(xiàn)多主并發(fā)通信。2.3 多主通信與非破壞性仲裁仲裁是 CAN 協(xié)議中最核心的設(shè)計之一。多個節(jié)點同時發(fā)送時它們會從幀起始位開始同步發(fā)送隨后在仲裁段逐位比較。具體過程是每個節(jié)點在發(fā)送 ID 的同時回讀總線電平。當(dāng)某個節(jié)點發(fā)送的是隱性位 1但讀到的總線電平是顯性位 0說明存在優(yōu)先級更高的節(jié)點本節(jié)點退出競爭。仲裁獲勝的節(jié)點繼續(xù)發(fā)送剩余幀內(nèi)容不被打斷。仲裁依據(jù) ID 進(jìn)行ID 數(shù)值越小優(yōu)先級越高。例如有兩個節(jié)點同時發(fā)送節(jié)點 A 發(fā)送 ID 0x100節(jié)點 B 發(fā)送 ID 0x200二進(jìn)制比較時0x100 的高位比 0x200 更早出現(xiàn)顯性位因此節(jié)點 A 贏得仲裁節(jié)點 B 自動進(jìn)入接收狀態(tài)。這個仲裁過程是在硬件中自動完成的不需要軟件參與。對開發(fā)者來說設(shè)計報文 ID 時就要考慮優(yōu)先級關(guān)鍵控制報文分配小 ID比如電機控制、剎車控制普通狀態(tài)報文分配大 ID比如傳感器周期上報。2.4 錯誤處理機制CAN 的可靠性很大程度上來自完善的錯誤檢測機制。協(xié)議規(guī)定了多種錯誤類型位錯誤節(jié)點發(fā)送某一位后回讀結(jié)果與自己發(fā)送的不同。填充錯誤連續(xù) 5 個相同極性位后沒有出現(xiàn)反相位填充位。CRC 錯誤接收方計算出的 CRC 與發(fā)送方寫入的 CRC 不一致。形式錯誤固定格式的位段值不合法例如 EOF 段應(yīng)當(dāng)全部是隱性位。ACK 錯誤發(fā)送方?jīng)]有收到接收節(jié)點的顯性 ACK 應(yīng)答。發(fā)生錯誤后節(jié)點會產(chǎn)生錯誤幀。每個 CAN 控制器內(nèi)部還有錯誤計數(shù)器根據(jù)錯誤類型累加或減少。節(jié)點錯誤狀態(tài)分為主動錯誤、被動錯誤和總線關(guān)閉主動錯誤正常參與通信發(fā)現(xiàn)錯誤后發(fā)送主動錯誤標(biāo)志。被動錯誤仍然能收發(fā)但只能發(fā)送被動錯誤標(biāo)志發(fā)送優(yōu)先級也受到限制?？偩€關(guān)閉退出總線通信無法參與收發(fā)需要軟件處理或等待恢復(fù)條件滿足后重新進(jìn)入總線。這里不展開錯誤計數(shù)的具體算法但嵌入式面試中經(jīng)常出現(xiàn)“錯誤幀是什么”“節(jié)點進(jìn)入 Bus Off 后怎么辦”這樣的問題。你需要記住錯誤幀不是某一種壞報文而是節(jié)點在檢測到錯誤之后按協(xié)議規(guī)定主動上報的一種幀類型錯誤幀本身也是合法的 CAN 幀不是隨意發(fā)的垃圾數(shù)據(jù)。3. CAN 報文類型與幀格式詳解3.1 數(shù)據(jù)幀數(shù)據(jù)幀是最常用的幀類型用于發(fā)送實際數(shù)據(jù)。一個完整數(shù)據(jù)幀包含以下段位段名稱作用幀起始 SOF1 位顯性位表示幀開始仲裁段包含 ID 和 RTR 位用于仲裁控制段包含 IDE、DLC 等控制信息數(shù)據(jù)段0 到 8 字節(jié)有效數(shù)據(jù)CRC 段15 位 CRC 校驗和 CRC 界定符ACK 段接收節(jié)點回復(fù)顯性 ACK幀結(jié)束 EOF7 位隱性位表示幀結(jié)束標(biāo)準(zhǔn)幀使用 11 位 ID所以標(biāo)準(zhǔn)幀 ID 范圍是 0x000 到 0x7FF。擴(kuò)展幀使用 29 位 ID取值范圍更大。一個標(biāo)準(zhǔn)數(shù)據(jù)幀中實際有效數(shù)據(jù)最多 8 字節(jié)這也是 CAN 協(xié)議比較適合傳輸控制命令、小包狀態(tài)數(shù)據(jù)的原因。在 STM32 等 MCU 的 CAN 控制器中發(fā)送數(shù)據(jù)幀時通常只需要填好標(biāo)準(zhǔn) ID、數(shù)據(jù)長度碼 DLC 和數(shù)據(jù)緩沖區(qū)控制器會自動完成 SOF、CRC、ACK、EOF 的插入。3.2 遠(yuǎn)程幀遠(yuǎn)程幀用于請求某個節(jié)點發(fā)送數(shù)據(jù)。它和普通數(shù)據(jù)幀的格式很接近但有兩個明顯區(qū)別RTR 位為 1表示這是一個遠(yuǎn)程幀。數(shù)據(jù)段長度 DLC 為 0遠(yuǎn)程幀本身不攜帶數(shù)據(jù)。當(dāng)一個節(jié)點收到遠(yuǎn)程幀后如果請求的 ID 與自身配置一致這個節(jié)點可以發(fā)送對應(yīng)的數(shù)據(jù)幀作為響應(yīng)。實際工程中遠(yuǎn)程幀使用頻率低于數(shù)據(jù)幀很多基于 CAN 的應(yīng)用協(xié)議干脆規(guī)定只使用數(shù)據(jù)幀所有節(jié)點通過 ID 區(qū)分和處理報文。3.3 錯誤幀與過載幀錯誤幀是節(jié)點發(fā)現(xiàn)總線上存在錯誤時主動發(fā)送的幀用于通知其他節(jié)點本次傳輸失敗。錯誤幀由兩部分組成錯誤標(biāo)志主動錯誤節(jié)點發(fā)出 6 個顯性位被動錯誤節(jié)點發(fā)出 6 個隱性位。錯誤界定符8 個隱性位用于恢復(fù)總線狀態(tài)。錯誤幀會把當(dāng)前正在傳輸?shù)膱笪拇驍嗳缓笏泄?jié)點重新開始競爭總線。如果總線上頻繁出現(xiàn)錯誤幀通常意味著總線物理層問題、波特率不一致或某個節(jié)點存在故障。過載幀用于接收節(jié)點來不及處理數(shù)據(jù)時請求延遲后續(xù)報文實際使用中不如錯誤幀常見。入門階段先知道它的存在即可。3.4 幀間隔與位填充幀與幀之間并不是緊挨著的協(xié)議規(guī)定了一般幀間至少要有一段間隔。主流幀類型之間還包含標(biāo)準(zhǔn)的 3 位隱性中斷間隔這保證了總線上的幀清晰可分辨。另一個值得了解的概念是位填充。CAN 總線在從 SOF 到 CRC 段的傳輸過程中如果連續(xù)出現(xiàn) 5 個相同極性的位會自動插入 1 個反極性位。接收端收到數(shù)據(jù)后會再把這 1 個填充位去掉恢復(fù)原始數(shù)據(jù)。位填充的目的是避免長時間沒有跳變導(dǎo)致接收節(jié)點失去位同步同時它也是一種錯誤檢測手段。如果接收端發(fā)現(xiàn)超過 5 個連續(xù)相同位而沒有填充位就會判定為填充錯誤。4. 波特率、位時序與采樣點4.1 CAN 波特率構(gòu)成CAN 通信雙方必須使用相同波特率否則會頻繁觸發(fā)錯誤幀。一個 CAN 位時間可以拆分成多個時間量子Time Quantum簡稱 Tq常見位時間由四部分組成同步段 SYNC_SEG固定 1 Tq用于同步總線上所有節(jié)點。傳播段 PROP_SEG用于補償信號在總線上傳播的物理延遲。相位緩沖段 1 PHASE_SEG1用于補償上升沿誤差。相位緩沖段 2 PHASE_SEG2用于補償下降沿誤差。同步跳轉(zhuǎn)寬度 SJW 表示重新同步時允許相位緩沖段調(diào)整的最大 Tq 數(shù)。波特率計算公式如下波特率 外設(shè)時鐘頻率 / (Prescaler * (1 TimeSeg1 TimeSeg2))其中 Prescaler 是波特率預(yù)分頻系數(shù)。TimeSeg1 通常包含傳播段和相位緩沖段 1 的長度HAL 庫中的 BS1 就是這兩段之和TimeSeg2 對應(yīng)相位緩沖段 2HAL 庫中的 BS2。4.2 采樣點計算公式采樣點位置決定了 CAN 通信的穩(wěn)定性尤其在不同線纜長度和節(jié)點距離下采樣點設(shè)置不合理會出現(xiàn)偶發(fā)通信失敗。采樣點公式采樣點 (SYNC_SEG BS1) / (SYNC_SEG BS1 BS2)如果用 Tq 表示采樣點 (1 BS1) / (1 BS1 BS2)常見的采樣點推薦范圍是 75% 到 87.5%。采樣點太靠前信號可能還沒穩(wěn)定采樣點太靠后對傳播延遲的容忍度就會下降。4.3 常用波特率配置思路以 STM32F1 系列為例如果 APB1 外設(shè)時鐘為 36MHz目標(biāo)波特率是 500kbps可以這樣分配Prescaler 4得到 Tq 時鐘頻率 36MHz / 4 9MHz。每個位時間需要 9000000 / 500000 18 個 Tq。分配SYNC_SEG 1 TqBS1 13 TqBS2 4 TqSJW 1 Tq。采樣點 (1 13) / 18 ≈ 77.8%。對應(yīng) HAL 庫初始化代碼如下hcan.Init.Prescaler 4; hcan.Init.SyncJumpWidth CAN_SJW_1TQ; hcan.Init.TimeSeg1 CAN_BS1_13TQ; hcan.Init.TimeSeg2 CAN_BS2_4TQ;這里特別提醒不同芯片的 CAN 控制器位時序范圍不一樣STM32 的 BS1 范圍通常是 1 到 16BS2 范圍是 1 到 8但其他廠家的 MCU 不一定只有相同選項。配置波特率時優(yōu)先查閱芯片參考手冊和 HAL 驅(qū)動說明不要照搬值。5. 實戰(zhàn)STM32 最小 CAN 收發(fā)工程5.1 硬件連接起步階段建議準(zhǔn)備兩塊開發(fā)板比如常見 STM32F103 系列開發(fā)板再配兩個 CAN 收發(fā)器模塊例如 TJA1050、MCP2551 等。連接方式如下開發(fā)板 CAN_TX 引腳接收發(fā)器 TXD。開發(fā)板 CAN_RX 引腳接收發(fā)器 RXD。收發(fā)器 CAN_H 接總線 CAN_H。收發(fā)器 CAN_L 接總線 CAN_L。兩個節(jié)點之間共地GND 相連。高速 CAN 總線兩端分別接 120Ω 終端電阻。很多開發(fā)板已經(jīng)集成了 CAN 收發(fā)器和終端電阻使用前建議先看原理圖確認(rèn)是否需要外接電阻避免重復(fù)接入導(dǎo)致信號幅值異常。5.2 基于 STM32CubeMX 的配置思路以 STM32CubeMX HAL 庫為例配置步驟大致如下選擇 MCU 型號。開啟 CAN1。配置 CAN 參數(shù)模式選擇 Normal 或 Loopback波特率按芯片時鐘重新計算。配置一個串口用于打印調(diào)試信息。生成工程后在 main.c 中補充過濾器配置、啟動 CAN 和中斷回調(diào)。需要注意的是不同 CubeMX 版本生成的代碼結(jié)構(gòu)略有差別下面代碼主要演示核心邏輯不保證直接復(fù)制到所有工程都能運行。5.3 CAN 初始化代碼CAN 初始化函數(shù)中需要設(shè)置 CAN 控制器外設(shè)實例、預(yù)分頻器、位時序和工作模式。// 文件路徑Core/Src/can.c void MX_CAN1_Init(void) { hcan.Instance CAN1; hcan.Init.Prescaler 4; hcan.Init.Mode CAN_MODE_NORMAL; hcan.Init.SyncJumpWidth CAN_SJW_1TQ; hcan.Init.TimeSeg1 CAN_BS1_13TQ; hcan.Init.TimeSeg2 CAN_BS2_4TQ; hcan.Init.TimeTriggeredMode DISABLE; hcan.Init.AutoBusOff DISABLE; hcan.Init.AutoWakeUp DISABLE; hcan.Init.AutoRetransmission ENABLE; hcan.Init.ReceiveFifoLocked DISABLE; hcan.Init.TransmitFifoPriority ENABLE; if (HAL_CAN_Init(hcan) ! HAL_OK) { Error_Handler(); } }關(guān)于參數(shù)說明Mode 設(shè)置為 Normal 是正常參與總線通信如果設(shè)置為 Loopback則節(jié)點自發(fā)自收不經(jīng)過外部總線。AutoRetransmission 開啟后發(fā)送失敗會自動重發(fā)適合需要可靠傳輸?shù)膱鼍?。AutoBusOff 設(shè)置為 DISABLE 時進(jìn)入 Bus Off 后不會自動恢復(fù)需要軟件干預(yù)便于排查問題。5.4 過濾器配置STM32 CAN 接收過濾器可以篩選 ID也可以接收全部報文。調(diào)試階段最簡單的方式是配置成接收所有報文void CAN_Filter_Config(void) { CAN_FilterTypeDef filterConfig; filterConfig.FilterBank 0; filterConfig.FilterMode CAN_FILTERMODE_IDMASK; filterConfig.FilterScale CAN_FILTERSCALE_32BIT; filterConfig.FilterIdHigh 0x0000; filterConfig.FilterIdLow 0x0000; filterConfig.FilterMaskIdHigh 0x0000; filterConfig.FilterMaskIdLow 0x0000; filterConfig.FilterFIFOAssignment CAN_RX_FIFO0; filterConfig.FilterActivation ENABLE; if (HAL_CAN_ConfigFilter(hcan, filterConfig) ! HAL_OK) { Error_Handler(); } }當(dāng) Mask 全部為 0 時表示不關(guān)心 ID 的每一位所有報文都能進(jìn)入接收 FIFO。等通信穩(wěn)定后再根據(jù)業(yè)務(wù)需求配置 ID 掩碼只接收自己關(guān)心的報文。5.5 CAN 發(fā)送函數(shù)發(fā)送一個標(biāo)準(zhǔn)數(shù)據(jù)幀核心是填充 CAN_TxHeaderTypeDef 結(jié)構(gòu)體uint8_t CAN_SendData(uint32_t stdId, uint8_t *data, uint8_t len) { CAN_TxHeaderTypeDef txHeader; uint32_t txMailbox 0; txHeader.StdId stdId; txHeader.ExtId 0; txHeader.IDE CAN_ID_STD; txHeader.RTR CAN_RTR_DATA; txHeader.DLC len; if (HAL_CAN_AddTxMessage(hcan, txHeader, data, txMailbox) ! HAL_OK) { return 0; } return 1; }說明StdId 是標(biāo)準(zhǔn)幀 ID范圍 0 到 0x7FF。IDE 選擇 CAN_ID_STD 為標(biāo)準(zhǔn)幀CAN_ID_EXT 為擴(kuò)展幀。RTR 為 CAN_RTR_DATA 表示數(shù)據(jù)幀CAN_RTR_REMOTE 表示遠(yuǎn)程幀。DLC 表示數(shù)據(jù)長度CAN 最大是 8。5.6 CAN 接收中斷回調(diào)配置好 CAN 接收中斷后每收到一個報文HAL 庫會調(diào)用接收 FIFO0 消息掛起回調(diào)函數(shù)。在回調(diào)中讀取報文內(nèi)容void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef rxHeader; uint8_t rxData[8]; if (HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, rxHeader, rxData) ! HAL_OK) { return; } printf(RX: ID0x%03X DLC%d\n, rxHeader.StdId, rxHeader.DLC); for (uint8_t i 0; i rxHeader.DLC; i) { printf(%02X , rxData[i]); } printf(\n); }實際項目中不建議在中斷回調(diào)里直接調(diào)用 printf因為 printf 會阻塞中斷執(zhí)行可能導(dǎo)致后續(xù)報文丟失。更穩(wěn)妥的做法是把接收到的報文拷貝到一個環(huán)形緩沖區(qū)或消息隊列在主循環(huán)中處理。5.7 主循環(huán)測試代碼主函數(shù)啟動 CAN 后可以周期發(fā)送一幀測試數(shù)據(jù)int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART2_UART_Init(); MX_CAN1_Init(); CAN_Filter_Config(); HAL_CAN_Start(hcan); HAL_CAN_ActivateNotification(hcan, CAN_IT_RX_FIFO0_MSG_PENDING); uint8_t txData[8] {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08}; while (1) { CAN_SendData(0x123, txData, 8); HAL_Delay(1000); } }將兩塊開發(fā)板下載相同程序后如果接線正確、波特率一致串口上應(yīng)該能看到對方發(fā)來的 CAN 報文。如果只有一塊開發(fā)板可以先把 CAN 模式改成 Loopback測試 CAN 控制器驅(qū)動是否正常。5.8 使用回環(huán)模式自測回環(huán)模式適合在沒有外部收發(fā)器或沒有第二塊板子時驗證驅(qū)動。配置也很簡單把初始化中的 Mode 改為 CAN_MODE_LOOPBACK 即可。在回環(huán)模式下MCU 發(fā)送的報文會直接進(jìn)入自己接收 FIFO所以可以在接收回調(diào)中打印自己發(fā)送的內(nèi)容。此時不需要物理總線上的另一個節(jié)點來應(yīng)答。6. CAN 總線常見異常與排查思路6.1 只有單節(jié)點時發(fā)送失敗如果總線上只有一個節(jié)點發(fā)送數(shù)據(jù)幀時發(fā)送方會一直等待其他節(jié)點回復(fù) ACK。由于沒有第二個節(jié)點確認(rèn)接收發(fā)送端會產(chǎn)生 ACK 錯誤并且反復(fù)重發(fā)最終可能報 Bus Off。排查思路確認(rèn)是否真的連接了第二個節(jié)點。如果用調(diào)試工具確認(rèn)總線終端電阻是否接好。單節(jié)點調(diào)試時先把 CAN 模式改為回環(huán)模式驗證控制器基本收發(fā)鏈路。6.2 通信失敗或偶發(fā)失敗兩個節(jié)點之間通信不穩(wěn)定最常見原因是波特率不一致或采樣點設(shè)置不合理。如果兩個節(jié)點使用的位時序計算方式不同雖然名義上都是 500kbps但實際波特率會有誤差導(dǎo)致某些幀可以被識別某些幀出現(xiàn)錯誤幀。排查思路統(tǒng)一兩側(cè)波特率預(yù)分頻和位時序參數(shù)。使用 CAN 分析工具實際監(jiān)測總線上波特率。如果距離較遠(yuǎn)檢查采樣點位置是否在推薦范圍內(nèi)。6.3 錯誤幀頻繁出現(xiàn)總線上頻繁出現(xiàn)錯誤幀可以從物理層和數(shù)據(jù)鏈路層兩個方向排查。常見的物理層問題包括CAN_H 和 CAN_L 接反。兩個節(jié)點沒有共地。終端電阻缺失、位置不對或阻抗異常。線纜過長、干擾過大?？偩€被某個故障節(jié)點持續(xù)拉低。常見的數(shù)據(jù)鏈路層問題包括波特率不一致。不同節(jié)點采樣點差異過大。幀類型不匹配比如一端配置成擴(kuò)展幀另一端發(fā)送的是標(biāo)準(zhǔn)幀。排查時建議使用示波器或邏輯分析儀觀察 CAN_H 和 CAN_L 波形先確認(rèn)波形形態(tài)正確再深入查看協(xié)議層錯誤。6.4 接收回調(diào)不觸發(fā)接收中斷不觸發(fā)但示波器能看到總線上有報文通常是過濾器和中斷配置問題過濾器掩碼配置過嚴(yán)導(dǎo)致報文被過濾掉。FIFO 分配錯誤報文進(jìn)入 FIFO1但只使能了 FIFO0 中斷。沒有調(diào)用 HAL_CAN_ActivateNotification 使能接收中斷。中斷優(yōu)先級配置錯誤導(dǎo)致中斷一直被其他中斷搶占或者無法響應(yīng)。調(diào)試時先按“接收所有報文”配置過濾器排除過濾器因素。6.5 常見問題排查清單問題現(xiàn)象常見原因解決思路單節(jié)點發(fā)送報錯無 ACK 應(yīng)答增加節(jié)點或使用回環(huán)模式自測通信時好時壞波特率不一致、采樣點不當(dāng)統(tǒng)一位時序參數(shù)用分析儀確認(rèn)實際波特率錯誤幀頻繁終端電阻缺失、線序接反、未共地檢查物理連接用示波器查看差分波形發(fā)送成功但收不到過濾器配置過嚴(yán)先配置為接收所有報文再逐步收斂接收中斷不觸發(fā)中斷未使能或 FIFO 分配錯誤檢查 HAL_CAN_ActivateNotification 和 FIFO 配置發(fā)送失敗但總線有波形設(shè)置了 AutoBusOff 且已進(jìn)入 Bus Off等待恢復(fù)或軟件復(fù)位 CAN 控制器7. CAN 總線工程落地的最佳實踐7.1 報文 ID 規(guī)劃與 DBCCAN 總線不是把幾個報文發(fā)出來就結(jié)束了。工程中最容易踩坑的是報文 ID 沒有統(tǒng)一規(guī)劃后續(xù)增加功能時出現(xiàn) ID 沖突或優(yōu)先級混亂。建議在項目初期做一份 ID 分配表至少包含ID 數(shù)值。報文名稱。報文類型周期/事件/診斷。發(fā)送節(jié)點。接收節(jié)點。數(shù)據(jù)長度和具體信號定義。當(dāng)系統(tǒng)節(jié)點較多時可以使用 DBC 文件描述報文和信號信息。DBC 是 CAN 總線的通用描述格式很多 CAN 分析工具都支持直接導(dǎo)入 DBC聯(lián)調(diào)和測試時不用反復(fù)問每個信號在第幾個字節(jié)。7.2 周期報文與事件報文在 CAN 報文設(shè)計中常見的發(fā)送策略有兩類周期報文按固定時間間隔發(fā)送比如電機轉(zhuǎn)速每 10ms 發(fā)送一次節(jié)點狀態(tài)每 100ms 發(fā)送一次。周期報文適合狀態(tài)類數(shù)據(jù)接收方可以通過報文超時判斷發(fā)送節(jié)點是否故障。事件報文當(dāng)某個事件發(fā)生時發(fā)送比如急停按鈕被按下、故障觸發(fā)。事件報文實時性高但要注意限流防止異常情況下節(jié)點瘋狂發(fā)報文。實際系統(tǒng)中通?；旌鲜褂脙烧摺ｊP(guān)鍵控制命令既要快速響應(yīng)又需要接收方及時判斷鏈路是否中斷所以往往采用較短周期發(fā)送或者“事件觸發(fā) 周期兜底”的雙重策略。7.3 節(jié)點故障隔離與總線關(guān)閉策略每個 CAN 節(jié)點都應(yīng)當(dāng)考慮錯誤狀態(tài)監(jiān)控。當(dāng)錯誤計數(shù)器持續(xù)上升說明節(jié)點通信環(huán)境可能存在問題。如果節(jié)點進(jìn)入 Bus Off它會徹底退出總線通信這對汽車、工業(yè)控制來說可能非常危險。更好的做法是在軟件中讀取錯誤狀態(tài)確定是否進(jìn)入被動錯誤或 Bus Off。根據(jù)錯誤等級執(zhí)行降級策略例如停止周期性發(fā)送、保留故障診斷信息、記錄錯誤日志。不要無腦自動恢復(fù)發(fā)送否則總線環(huán)境未恢復(fù)時節(jié)點會反復(fù)制造錯誤幀。需要恢復(fù)時通過錯誤狀態(tài)分析、延時重啟或重新初始化 CAN 外設(shè)來恢復(fù)正常通信。開啟 AutoRetransmission 可以讓硬件自動重發(fā)失敗報文但也要結(jié)合具體場景評估。對于實時性要求極高的控制報文連續(xù)重發(fā)會占用總線時間反而影響其他節(jié)點。7.4 安全與可靠性建議雖然 CAN 協(xié)議本身有 CRC 校驗但在實際工程中仍需要額外的安全措施對重要的報文增加序號和校驗和防止漏幀或數(shù)據(jù)被篡改后仍能通過協(xié)議 CRC。對控制類命令做超時管理接收方在指定時間內(nèi)沒有收到新命令應(yīng)進(jìn)入安全狀態(tài)。懷疑數(shù)據(jù)可靠性時不要直接信任單幀數(shù)據(jù)可以連續(xù)多幀一致后才執(zhí)行。在硬件設(shè)計中CAN 收發(fā)器附近應(yīng)做好 ESD 防護(hù)、TVS 管使用雙絞屏蔽線必要時增加共模電感。信號線應(yīng)避免與電源線、大電流線長期平行走線減少電磁干擾。7.5 接收中斷中少做耗時操作CAN 報文是短報文但遇到高波特率時一秒鐘可能收到幾千幀。如果在接收中斷回調(diào)中做數(shù)據(jù)解析、日志打印、甚至驅(qū)動電機很容易導(dǎo)致中斷溢出。建議把接收回調(diào)只當(dāng)作“數(shù)據(jù)搬運工”從 CAN 控制器讀出數(shù)據(jù)后馬上放入隊列或環(huán)形緩沖區(qū)立刻返回中斷。解析、濾波、協(xié)議處理放到主循環(huán)或?qū)Ｓ萌蝿?wù)中完成。8. 總結(jié)與下一步學(xué)習(xí)建議8.1 本講核心掌握點這一講圍繞 CAN 總線協(xié)議最重要的幾個知識點可以這樣梳理CAN 是一個多主、帶優(yōu)先級仲裁、帶錯誤自檢的串行通信協(xié)議適合實時性要求高的多節(jié)點場景。物理層使用差分信號總線邏輯為“線與”顯性位 0 優(yōu)先級高于隱性位 1。幀結(jié)構(gòu)核心是數(shù)據(jù)幀和遠(yuǎn)程幀標(biāo)準(zhǔn)幀 ID 為 11 位擴(kuò)展幀 ID 為 29 位數(shù)據(jù)最多 8 字節(jié)。錯誤幀頻繁出現(xiàn)時重點排查波特率、終端電阻、線序、共地問題。波特率與采樣點要統(tǒng)一規(guī)劃不能只看名義上的波特率數(shù)值。對嵌入式初學(xué)者來說能做 CAN 收發(fā)只是第一步能夠定位“為什么總線上一堆錯誤幀”才是真正體現(xiàn)調(diào)試能力的地方。8.2 繼續(xù)深入學(xué)習(xí)路線把基礎(chǔ)收發(fā)跑通之后下一步可以往兩個方向深入一是協(xié)議方向。學(xué)習(xí)了裸的 CAN 報文之后可以接觸 CANopen、J1939、UDS 等應(yīng)用層協(xié)議理解它們?nèi)绾位?CAN 幀定義對象字典、報文周期、診斷流程。汽車電子方向特別需要 UDS 和 J1939 的知識。二是系統(tǒng)方向。如果你在做嵌入式 Linux可以學(xué)習(xí) SocketCAN它把 CAN 設(shè)備抽象成網(wǎng)絡(luò)接口應(yīng)用層可以使用標(biāo)準(zhǔn) socket 讀寫 CAN 報文。這樣可以把 CAN 和上位機、復(fù)雜的應(yīng)用邏輯結(jié)合起來工程能力會提升一個臺階。如果你準(zhǔn)備嵌入式面試數(shù)據(jù)幀的字段、仲裁規(guī)則、錯誤幀和錯誤狀態(tài)這幾個點是必刷內(nèi)容。建議親手用開發(fā)板抓一次總線波形把 ID、DLC、CRC、ACK 都對照著看一遍這類經(jīng)驗很難僅靠背概念替代。 CAN總線協(xié)議入門：從物理層仲裁機制到STM32實戰(zhàn)
嵌入式項目做到一定階段總會遇到“多設(shè)備通信”的需求。串口簡單直接但點對點通信不夠靈活I(lǐng)2C / SPI 適合板內(nèi)通信距離一遠(yuǎn)就不太合適RS485 能組網(wǎng)但主從輪詢模式下節(jié)點多了之后實時性很難保證。這時候CAN 總線往往是最合適的選擇。本文是嵌入式入門系列的第七講主題是 CAN 總線協(xié)議。我會從協(xié)議解決什么問題講起依次分析物理層電平、幀結(jié)構(gòu)、仲裁機制、波特率配置最后給出一個基于 STM32 的 CAN 收發(fā)工程示例以及常見故障排查思路。學(xué)完之后你應(yīng)該能獨立讀懂 CAN 報文理解為什么兩根差分線能掛在幾十個節(jié)點并能完成兩個節(jié)點之間的 CAN 通信調(diào)試。1. 為什么嵌入式開發(fā)要學(xué) CAN 總線協(xié)議1.1 CAN 總線到底解決了什么問題CAN 是 Controller Area Network 的縮寫翻譯過來就是“控制器局域網(wǎng)”。它最早由 BOSCH 公司提出后來形成了 ISO 11898 系列標(biāo)準(zhǔn)主要面向汽車電子和工業(yè)控制場景。在沒有 CAN 的早期汽車中每個傳感器、控制器之間要通過大量線束點對點連接。車上有幾十個 ECU每個 ECU 又可能需要多個傳感器信號線束數(shù)量會急劇膨脹不僅成本高而且故障排查困難。CAN 總線的作用就是讓所有控制器共享同一對差分線通過統(tǒng)一的報文機制交換數(shù)據(jù)從而大幅減少線束。從軟件角度看CAN 不是簡單的“兩個設(shè)備之間傳數(shù)據(jù)”而是解決了一組問題多主通信總線上任何一個節(jié)點都可以主動發(fā)起發(fā)送不需要主機統(tǒng)一調(diào)度。多節(jié)點互聯(lián)一條總線上可以掛幾十個節(jié)點理論上受 CAN 收發(fā)器驅(qū)動能力和協(xié)議尋址限制。實時性保障協(xié)議自帶優(yōu)先級仲裁高優(yōu)先級報文可以搶占總線?？煽啃员Ｕ蠀f(xié)議自帶 CRC 校驗、幀格式檢查、ACK 確認(rèn)和錯誤重發(fā)機制。這些特性決定了 CAN 很適合作為汽車、工業(yè)現(xiàn)場、醫(yī)療設(shè)備、工程機械等場景的骨干通信總線。1.2 CAN 與 UART、I2C、SPI、RS485 的定位差異初學(xué)者最常問的一個問題是CAN 和串口、RS485 到底有什么區(qū)別下面把常見總線的定位做一個簡單對比?？偩€類型通信模式節(jié)點數(shù)量距離實時性典型場景UART單主單從2短無仲裁調(diào)試口、模塊通信I2C單主多從多板級主從輪詢板內(nèi)傳感器、存儲芯片SPI單主多從多板級主從輪詢Flash、屏幕、ADCRS485一主多從多長主從輪詢工業(yè)儀表、PLC 通信CAN多主多從多中長硬件仲裁汽車 ECU、工業(yè)控制從表中能看出RS485 和 CAN 都是差分信號抗干擾能力都比較強但兩者有一個關(guān)鍵差異RS485 在同一時刻只能有一個節(jié)點發(fā)送數(shù)據(jù)沒有硬件級仲裁通常依賴主站輪詢或令牌機制CAN 則允許節(jié)點同時開始發(fā)送由協(xié)議在物理層自動仲裁優(yōu)先級低的節(jié)點自動退出發(fā)送并且不破壞高優(yōu)先級報文的完整性。所以如果你需要一套“多個節(jié)點都能主動上報、實時性要求高、數(shù)據(jù)量不大”的通信系統(tǒng)CAN 比 RS485 更合適。1.3 CAN 的典型應(yīng)用場景CAN 的應(yīng)用范圍很廣下面幾個場景比較典型汽車電子發(fā)動機 ECU、變速箱、ABS、車身控制器、儀表盤、BMS 電池管理之間的通信。傳統(tǒng)汽車和電動車都在大量使用 CAN。工業(yè)控制傳感器、伺服驅(qū)動器、PLC 之間的現(xiàn)場總線通信。無人機與機器人飛控、電調(diào)、云臺之間傳輸控制指令和狀態(tài)信息很多飛控內(nèi)部或外界擴(kuò)展總線用的就是 CAN。醫(yī)療設(shè)備手術(shù)臺、監(jiān)護(hù)儀、影像設(shè)備等內(nèi)部模塊通信利用 CAN 的可靠性和錯誤檢測能力。軌道交通、船舶、農(nóng)用機械等可靠性要求較高的場景。即使你當(dāng)前做的是嵌入式 Linux 應(yīng)用開發(fā)、單片機裸機開發(fā)或者嵌入式測試方向CAN 協(xié)議都可能出現(xiàn)在項目需求里。這也是它成為嵌入式面試高頻考點的原因之一。2. CAN 總線整體架構(gòu)與核心機制2.1 物理層與數(shù)據(jù)鏈路層CAN 協(xié)議體系可以粗略分成兩層物理層和數(shù)據(jù)鏈路層。物理層定義了信號電平、傳輸介質(zhì)、線束接口和終端電阻。最常用的是高速 CAN兩條信號線分別叫作 CAN_H 和 CAN_L使用差分電壓傳輸靜態(tài)時兩條線電壓接近邏輯上表示為隱性Recessive傳輸顯性Dominant電平時CAN_H 被拉高CAN_L 被拉低。數(shù)據(jù)鏈路層則定義了報文如何組幀、如何仲裁、如何校驗、如何錯誤重發(fā)。對寫代碼的工程師來說數(shù)據(jù)鏈路層是最需要下功夫的部分因為協(xié)議芯片或 MCU 內(nèi)部 CAN 控制器已經(jīng)做了大部分底層工作我們平時操作的就是數(shù)據(jù)鏈路層的收發(fā)接口。2.2 顯性與隱性電平的“線與”原理CAN 總線邏輯電平不是簡單的高電平為 1、低電平為 0。協(xié)議里面隱性電平對應(yīng)邏輯 1表示“釋放總線”。顯性電平對應(yīng)邏輯 0表示“占用總線”。關(guān)鍵規(guī)則是“線與”當(dāng)總線上多個節(jié)點同時發(fā)送只要有一個節(jié)點輸出顯性電平總線上就是顯性電平只有當(dāng)所有節(jié)點都輸出隱性電平總線才表現(xiàn)為隱性。舉個例子。節(jié)點 A 發(fā)送隱位“1”節(jié)點 B 發(fā)送顯位“0”總線上的結(jié)果是顯位“0”。這個特性的直接意義是發(fā)送節(jié)點在發(fā)送的每一個位周期內(nèi)都能實時回讀總線電平一旦發(fā)現(xiàn)“我發(fā)的是隱性但總線讀到顯性”就知道有其他更高優(yōu)先級的節(jié)點正在發(fā)送于是本節(jié)點自動停止發(fā)送。正是因為有了這種機制CAN 才能在不需要主機調(diào)度的情況下實現(xiàn)多主并發(fā)通信。2.3 多主通信與非破壞性仲裁仲裁是 CAN 協(xié)議中最核心的設(shè)計之一。多個節(jié)點同時發(fā)送時它們會從幀起始位開始同步發(fā)送隨后在仲裁段逐位比較。具體過程是每個節(jié)點在發(fā)送 ID 的同時回讀總線電平。當(dāng)某個節(jié)點發(fā)送的是隱性位 1但讀到的總線電平是顯性位 0說明存在優(yōu)先級更高的節(jié)點本節(jié)點退出競爭。仲裁獲勝的節(jié)點繼續(xù)發(fā)送剩余幀內(nèi)容不被打斷。仲裁依據(jù) ID 進(jìn)行ID 數(shù)值越小優(yōu)先級越高。例如有兩個節(jié)點同時發(fā)送節(jié)點 A 發(fā)送 ID 0x100節(jié)點 B 發(fā)送 ID 0x200二進(jìn)制比較時0x100 的高位比 0x200 更早出現(xiàn)顯性位因此節(jié)點 A 贏得仲裁節(jié)點 B 自動進(jìn)入接收狀態(tài)。這個仲裁過程是在硬件中自動完成的不需要軟件參與。對開發(fā)者來說設(shè)計報文 ID 時就要考慮優(yōu)先級關(guān)鍵控制報文分配小 ID比如電機控制、剎車控制普通狀態(tài)報文分配大 ID比如傳感器周期上報。2.4 錯誤處理機制CAN 的可靠性很大程度上來自完善的錯誤檢測機制。協(xié)議規(guī)定了多種錯誤類型位錯誤節(jié)點發(fā)送某一位后回讀結(jié)果與自己發(fā)送的不同。填充錯誤連續(xù) 5 個相同極性位后沒有出現(xiàn)反相位填充位。CRC 錯誤接收方計算出的 CRC 與發(fā)送方寫入的 CRC 不一致。形式錯誤固定格式的位段值不合法例如 EOF 段應(yīng)當(dāng)全部是隱性位。ACK 錯誤發(fā)送方?jīng)]有收到接收節(jié)點的顯性 ACK 應(yīng)答。發(fā)生錯誤后節(jié)點會產(chǎn)生錯誤幀。每個 CAN 控制器內(nèi)部還有錯誤計數(shù)器根據(jù)錯誤類型累加或減少。節(jié)點錯誤狀態(tài)分為主動錯誤、被動錯誤和總線關(guān)閉主動錯誤正常參與通信發(fā)現(xiàn)錯誤后發(fā)送主動錯誤標(biāo)志。被動錯誤仍然能收發(fā)但只能發(fā)送被動錯誤標(biāo)志發(fā)送優(yōu)先級也受到限制?？偩€關(guān)閉退出總線通信無法參與收發(fā)需要軟件處理或等待恢復(fù)條件滿足后重新進(jìn)入總線。這里不展開錯誤計數(shù)的具體算法但嵌入式面試中經(jīng)常出現(xiàn)“錯誤幀是什么”“節(jié)點進(jìn)入 Bus Off 后怎么辦”這樣的問題。你需要記住錯誤幀不是某一種壞報文而是節(jié)點在檢測到錯誤之后按協(xié)議規(guī)定主動上報的一種幀類型錯誤幀本身也是合法的 CAN 幀不是隨意發(fā)的垃圾數(shù)據(jù)。3. CAN 報文類型與幀格式詳解3.1 數(shù)據(jù)幀數(shù)據(jù)幀是最常用的幀類型用于發(fā)送實際數(shù)據(jù)。一個完整數(shù)據(jù)幀包含以下段位段名稱作用幀起始 SOF1 位顯性位表示幀開始仲裁段包含 ID 和 RTR 位用于仲裁控制段包含 IDE、DLC 等控制信息數(shù)據(jù)段0 到 8 字節(jié)有效數(shù)據(jù)CRC 段15 位 CRC 校驗和 CRC 界定符ACK 段接收節(jié)點回復(fù)顯性 ACK幀結(jié)束 EOF7 位隱性位表示幀結(jié)束標(biāo)準(zhǔn)幀使用 11 位 ID所以標(biāo)準(zhǔn)幀 ID 范圍是 0x000 到 0x7FF。擴(kuò)展幀使用 29 位 ID取值范圍更大。一個標(biāo)準(zhǔn)數(shù)據(jù)幀中實際有效數(shù)據(jù)最多 8 字節(jié)這也是 CAN 協(xié)議比較適合傳輸控制命令、小包狀態(tài)數(shù)據(jù)的原因。在 STM32 等 MCU 的 CAN 控制器中發(fā)送數(shù)據(jù)幀時通常只需要填好標(biāo)準(zhǔn) ID、數(shù)據(jù)長度碼 DLC 和數(shù)據(jù)緩沖區(qū)控制器會自動完成 SOF、CRC、ACK、EOF 的插入。3.2 遠(yuǎn)程幀遠(yuǎn)程幀用于請求某個節(jié)點發(fā)送數(shù)據(jù)。它和普通數(shù)據(jù)幀的格式很接近但有兩個明顯區(qū)別RTR 位為 1表示這是一個遠(yuǎn)程幀。數(shù)據(jù)段長度 DLC 為 0遠(yuǎn)程幀本身不攜帶數(shù)據(jù)。當(dāng)一個節(jié)點收到遠(yuǎn)程幀后如果請求的 ID 與自身配置一致這個節(jié)點可以發(fā)送對應(yīng)的數(shù)據(jù)幀作為響應(yīng)。實際工程中遠(yuǎn)程幀使用頻率低于數(shù)據(jù)幀很多基于 CAN 的應(yīng)用協(xié)議干脆規(guī)定只使用數(shù)據(jù)幀所有節(jié)點通過 ID 區(qū)分和處理報文。3.3 錯誤幀與過載幀錯誤幀是節(jié)點發(fā)現(xiàn)總線上存在錯誤時主動發(fā)送的幀用于通知其他節(jié)點本次傳輸失敗。錯誤幀由兩部分組成錯誤標(biāo)志主動錯誤節(jié)點發(fā)出 6 個顯性位被動錯誤節(jié)點發(fā)出 6 個隱性位。錯誤界定符8 個隱性位用于恢復(fù)總線狀態(tài)。錯誤幀會把當(dāng)前正在傳輸?shù)膱笪拇驍嗳缓笏泄?jié)點重新開始競爭總線。如果總線上頻繁出現(xiàn)錯誤幀通常意味著總線物理層問題、波特率不一致或某個節(jié)點存在故障。過載幀用于接收節(jié)點來不及處理數(shù)據(jù)時請求延遲后續(xù)報文實際使用中不如錯誤幀常見。入門階段先知道它的存在即可。3.4 幀間隔與位填充幀與幀之間并不是緊挨著的協(xié)議規(guī)定了一般幀間至少要有一段間隔。主流幀類型之間還包含標(biāo)準(zhǔn)的 3 位隱性中斷間隔這保證了總線上的幀清晰可分辨。另一個值得了解的概念是位填充。CAN 總線在從 SOF 到 CRC 段的傳輸過程中如果連續(xù)出現(xiàn) 5 個相同極性的位會自動插入 1 個反極性位。接收端收到數(shù)據(jù)后會再把這 1 個填充位去掉恢復(fù)原始數(shù)據(jù)。位填充的目的是避免長時間沒有跳變導(dǎo)致接收節(jié)點失去位同步同時它也是一種錯誤檢測手段。如果接收端發(fā)現(xiàn)超過 5 個連續(xù)相同位而沒有填充位就會判定為填充錯誤。4. 波特率、位時序與采樣點4.1 CAN 波特率構(gòu)成CAN 通信雙方必須使用相同波特率否則會頻繁觸發(fā)錯誤幀。一個 CAN 位時間可以拆分成多個時間量子Time Quantum簡稱 Tq常見位時間由四部分組成同步段 SYNC_SEG固定 1 Tq用于同步總線上所有節(jié)點。傳播段 PROP_SEG用于補償信號在總線上傳播的物理延遲。相位緩沖段 1 PHASE_SEG1用于補償上升沿誤差。相位緩沖段 2 PHASE_SEG2用于補償下降沿誤差。同步跳轉(zhuǎn)寬度 SJW 表示重新同步時允許相位緩沖段調(diào)整的最大 Tq 數(shù)。波特率計算公式如下波特率 外設(shè)時鐘頻率 / (Prescaler * (1 TimeSeg1 TimeSeg2))其中 Prescaler 是波特率預(yù)分頻系數(shù)。TimeSeg1 通常包含傳播段和相位緩沖段 1 的長度HAL 庫中的 BS1 就是這兩段之和TimeSeg2 對應(yīng)相位緩沖段 2HAL 庫中的 BS2。4.2 采樣點計算公式采樣點位置決定了 CAN 通信的穩(wěn)定性尤其在不同線纜長度和節(jié)點距離下采樣點設(shè)置不合理會出現(xiàn)偶發(fā)通信失敗。采樣點公式采樣點 (SYNC_SEG BS1) / (SYNC_SEG BS1 BS2)如果用 Tq 表示采樣點 (1 BS1) / (1 BS1 BS2)常見的采樣點推薦范圍是 75% 到 87.5%。采樣點太靠前信號可能還沒穩(wěn)定采樣點太靠后對傳播延遲的容忍度就會下降。4.3 常用波特率配置思路以 STM32F1 系列為例如果 APB1 外設(shè)時鐘為 36MHz目標(biāo)波特率是 500kbps可以這樣分配Prescaler 4得到 Tq 時鐘頻率 36MHz / 4 9MHz。每個位時間需要 9000000 / 500000 18 個 Tq。分配SYNC_SEG 1 TqBS1 13 TqBS2 4 TqSJW 1 Tq。采樣點 (1 13) / 18 ≈ 77.8%。對應(yīng) HAL 庫初始化代碼如下hcan.Init.Prescaler 4; hcan.Init.SyncJumpWidth CAN_SJW_1TQ; hcan.Init.TimeSeg1 CAN_BS1_13TQ; hcan.Init.TimeSeg2 CAN_BS2_4TQ;這里特別提醒不同芯片的 CAN 控制器位時序范圍不一樣STM32 的 BS1 范圍通常是 1 到 16BS2 范圍是 1 到 8但其他廠家的 MCU 不一定只有相同選項。配置波特率時優(yōu)先查閱芯片參考手冊和 HAL 驅(qū)動說明不要照搬值。5. 實戰(zhàn)STM32 最小 CAN 收發(fā)工程5.1 硬件連接起步階段建議準(zhǔn)備兩塊開發(fā)板比如常見 STM32F103 系列開發(fā)板再配兩個 CAN 收發(fā)器模塊例如 TJA1050、MCP2551 等。連接方式如下開發(fā)板 CAN_TX 引腳接收發(fā)器 TXD。開發(fā)板 CAN_RX 引腳接收發(fā)器 RXD。收發(fā)器 CAN_H 接總線 CAN_H。收發(fā)器 CAN_L 接總線 CAN_L。兩個節(jié)點之間共地GND 相連。高速 CAN 總線兩端分別接 120Ω 終端電阻。很多開發(fā)板已經(jīng)集成了 CAN 收發(fā)器和終端電阻使用前建議先看原理圖確認(rèn)是否需要外接電阻避免重復(fù)接入導(dǎo)致信號幅值異常。5.2 基于 STM32CubeMX 的配置思路以 STM32CubeMX HAL 庫為例配置步驟大致如下選擇 MCU 型號。開啟 CAN1。配置 CAN 參數(shù)模式選擇 Normal 或 Loopback波特率按芯片時鐘重新計算。配置一個串口用于打印調(diào)試信息。生成工程后在 main.c 中補充過濾器配置、啟動 CAN 和中斷回調(diào)。需要注意的是不同 CubeMX 版本生成的代碼結(jié)構(gòu)略有差別下面代碼主要演示核心邏輯不保證直接復(fù)制到所有工程都能運行。5.3 CAN 初始化代碼CAN 初始化函數(shù)中需要設(shè)置 CAN 控制器外設(shè)實例、預(yù)分頻器、位時序和工作模式。// 文件路徑Core/Src/can.c void MX_CAN1_Init(void) { hcan.Instance CAN1; hcan.Init.Prescaler 4; hcan.Init.Mode CAN_MODE_NORMAL; hcan.Init.SyncJumpWidth CAN_SJW_1TQ; hcan.Init.TimeSeg1 CAN_BS1_13TQ; hcan.Init.TimeSeg2 CAN_BS2_4TQ; hcan.Init.TimeTriggeredMode DISABLE; hcan.Init.AutoBusOff DISABLE; hcan.Init.AutoWakeUp DISABLE; hcan.Init.AutoRetransmission ENABLE; hcan.Init.ReceiveFifoLocked DISABLE; hcan.Init.TransmitFifoPriority ENABLE; if (HAL_CAN_Init(hcan) ! HAL_OK) { Error_Handler(); } }關(guān)于參數(shù)說明Mode 設(shè)置為 Normal 是正常參與總線通信如果設(shè)置為 Loopback則節(jié)點自發(fā)自收不經(jīng)過外部總線。AutoRetransmission 開啟后發(fā)送失敗會自動重發(fā)適合需要可靠傳輸?shù)膱鼍?。AutoBusOff 設(shè)置為 DISABLE 時進(jìn)入 Bus Off 后不會自動恢復(fù)需要軟件干預(yù)便于排查問題。5.4 過濾器配置STM32 CAN 接收過濾器可以篩選 ID也可以接收全部報文。調(diào)試階段最簡單的方式是配置成接收所有報文void CAN_Filter_Config(void) { CAN_FilterTypeDef filterConfig; filterConfig.FilterBank 0; filterConfig.FilterMode CAN_FILTERMODE_IDMASK; filterConfig.FilterScale CAN_FILTERSCALE_32BIT; filterConfig.FilterIdHigh 0x0000; filterConfig.FilterIdLow 0x0000; filterConfig.FilterMaskIdHigh 0x0000; filterConfig.FilterMaskIdLow 0x0000; filterConfig.FilterFIFOAssignment CAN_RX_FIFO0; filterConfig.FilterActivation ENABLE; if (HAL_CAN_ConfigFilter(hcan, filterConfig) ! HAL_OK) { Error_Handler(); } }當(dāng) Mask 全部為 0 時表示不關(guān)心 ID 的每一位所有報文都能進(jìn)入接收 FIFO。等通信穩(wěn)定后再根據(jù)業(yè)務(wù)需求配置 ID 掩碼只接收自己關(guān)心的報文。5.5 CAN 發(fā)送函數(shù)發(fā)送一個標(biāo)準(zhǔn)數(shù)據(jù)幀核心是填充 CAN_TxHeaderTypeDef 結(jié)構(gòu)體uint8_t CAN_SendData(uint32_t stdId, uint8_t *data, uint8_t len) { CAN_TxHeaderTypeDef txHeader; uint32_t txMailbox 0; txHeader.StdId stdId; txHeader.ExtId 0; txHeader.IDE CAN_ID_STD; txHeader.RTR CAN_RTR_DATA; txHeader.DLC len; if (HAL_CAN_AddTxMessage(hcan, txHeader, data, txMailbox) ! HAL_OK) { return 0; } return 1; }說明StdId 是標(biāo)準(zhǔn)幀 ID范圍 0 到 0x7FF。IDE 選擇 CAN_ID_STD 為標(biāo)準(zhǔn)幀CAN_ID_EXT 為擴(kuò)展幀。RTR 為 CAN_RTR_DATA 表示數(shù)據(jù)幀CAN_RTR_REMOTE 表示遠(yuǎn)程幀。DLC 表示數(shù)據(jù)長度CAN 最大是 8。5.6 CAN 接收中斷回調(diào)配置好 CAN 接收中斷后每收到一個報文HAL 庫會調(diào)用接收 FIFO0 消息掛起回調(diào)函數(shù)。在回調(diào)中讀取報文內(nèi)容void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef rxHeader; uint8_t rxData[8]; if (HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, rxHeader, rxData) ! HAL_OK) { return; } printf(RX: ID0x%03X DLC%d\n, rxHeader.StdId, rxHeader.DLC); for (uint8_t i 0; i rxHeader.DLC; i) { printf(%02X , rxData[i]); } printf(\n); }實際項目中不建議在中斷回調(diào)里直接調(diào)用 printf因為 printf 會阻塞中斷執(zhí)行可能導(dǎo)致后續(xù)報文丟失。更穩(wěn)妥的做法是把接收到的報文拷貝到一個環(huán)形緩沖區(qū)或消息隊列在主循環(huán)中處理。5.7 主循環(huán)測試代碼主函數(shù)啟動 CAN 后可以周期發(fā)送一幀測試數(shù)據(jù)int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USART2_UART_Init(); MX_CAN1_Init(); CAN_Filter_Config(); HAL_CAN_Start(hcan); HAL_CAN_ActivateNotification(hcan, CAN_IT_RX_FIFO0_MSG_PENDING); uint8_t txData[8] {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08}; while (1) { CAN_SendData(0x123, txData, 8); HAL_Delay(1000); } }將兩塊開發(fā)板下載相同程序后如果接線正確、波特率一致串口上應(yīng)該能看到對方發(fā)來的 CAN 報文。如果只有一塊開發(fā)板可以先把 CAN 模式改成 Loopback測試 CAN 控制器驅(qū)動是否正常。5.8 使用回環(huán)模式自測回環(huán)模式適合在沒有外部收發(fā)器或沒有第二塊板子時驗證驅(qū)動。配置也很簡單把初始化中的 Mode 改為 CAN_MODE_LOOPBACK 即可。在回環(huán)模式下MCU 發(fā)送的報文會直接進(jìn)入自己接收 FIFO所以可以在接收回調(diào)中打印自己發(fā)送的內(nèi)容。此時不需要物理總線上的另一個節(jié)點來應(yīng)答。6. CAN 總線常見異常與排查思路6.1 只有單節(jié)點時發(fā)送失敗如果總線上只有一個節(jié)點發(fā)送數(shù)據(jù)幀時發(fā)送方會一直等待其他節(jié)點回復(fù) ACK。由于沒有第二個節(jié)點確認(rèn)接收發(fā)送端會產(chǎn)生 ACK 錯誤并且反復(fù)重發(fā)最終可能報 Bus Off。排查思路確認(rèn)是否真的連接了第二個節(jié)點。如果用調(diào)試工具確認(rèn)總線終端電阻是否接好。單節(jié)點調(diào)試時先把 CAN 模式改為回環(huán)模式驗證控制器基本收發(fā)鏈路。6.2 通信失敗或偶發(fā)失敗兩個節(jié)點之間通信不穩(wěn)定最常見原因是波特率不一致或采樣點設(shè)置不合理。如果兩個節(jié)點使用的位時序計算方式不同雖然名義上都是 500kbps但實際波特率會有誤差導(dǎo)致某些幀可以被識別某些幀出現(xiàn)錯誤幀。排查思路統(tǒng)一兩側(cè)波特率預(yù)分頻和位時序參數(shù)。使用 CAN 分析工具實際監(jiān)測總線上波特率。如果距離較遠(yuǎn)檢查采樣點位置是否在推薦范圍內(nèi)。6.3 錯誤幀頻繁出現(xiàn)總線上頻繁出現(xiàn)錯誤幀可以從物理層和數(shù)據(jù)鏈路層兩個方向排查。常見的物理層問題包括CAN_H 和 CAN_L 接反。兩個節(jié)點沒有共地。終端電阻缺失、位置不對或阻抗異常。線纜過長、干擾過大?？偩€被某個故障節(jié)點持續(xù)拉低。常見的數(shù)據(jù)鏈路層問題包括波特率不一致。不同節(jié)點采樣點差異過大。幀類型不匹配比如一端配置成擴(kuò)展幀另一端發(fā)送的是標(biāo)準(zhǔn)幀。排查時建議使用示波器或邏輯分析儀觀察 CAN_H 和 CAN_L 波形先確認(rèn)波形形態(tài)正確再深入查看協(xié)議層錯誤。6.4 接收回調(diào)不觸發(fā)接收中斷不觸發(fā)但示波器能看到總線上有報文通常是過濾器和中斷配置問題過濾器掩碼配置過嚴(yán)導(dǎo)致報文被過濾掉。FIFO 分配錯誤報文進(jìn)入 FIFO1但只使能了 FIFO0 中斷。沒有調(diào)用 HAL_CAN_ActivateNotification 使能接收中斷。中斷優(yōu)先級配置錯誤導(dǎo)致中斷一直被其他中斷搶占或者無法響應(yīng)。調(diào)試時先按“接收所有報文”配置過濾器排除過濾器因素。6.5 常見問題排查清單問題現(xiàn)象常見原因解決思路單節(jié)點發(fā)送報錯無 ACK 應(yīng)答增加節(jié)點或使用回環(huán)模式自測通信時好時壞波特率不一致、采樣點不當(dāng)統(tǒng)一位時序參數(shù)用分析儀確認(rèn)實際波特率錯誤幀頻繁終端電阻缺失、線序接反、未共地檢查物理連接用示波器查看差分波形發(fā)送成功但收不到過濾器配置過嚴(yán)先配置為接收所有報文再逐步收斂接收中斷不觸發(fā)中斷未使能或 FIFO 分配錯誤檢查 HAL_CAN_ActivateNotification 和 FIFO 配置發(fā)送失敗但總線有波形設(shè)置了 AutoBusOff 且已進(jìn)入 Bus Off等待恢復(fù)或軟件復(fù)位 CAN 控制器7. CAN 總線工程落地的最佳實踐7.1 報文 ID 規(guī)劃與 DBCCAN 總線不是把幾個報文發(fā)出來就結(jié)束了。工程中最容易踩坑的是報文 ID 沒有統(tǒng)一規(guī)劃后續(xù)增加功能時出現(xiàn) ID 沖突或優(yōu)先級混亂。建議在項目初期做一份 ID 分配表至少包含ID 數(shù)值。報文名稱。報文類型周期/事件/診斷。發(fā)送節(jié)點。接收節(jié)點。數(shù)據(jù)長度和具體信號定義。當(dāng)系統(tǒng)節(jié)點較多時可以使用 DBC 文件描述報文和信號信息。DBC 是 CAN 總線的通用描述格式很多 CAN 分析工具都支持直接導(dǎo)入 DBC聯(lián)調(diào)和測試時不用反復(fù)問每個信號在第幾個字節(jié)。7.2 周期報文與事件報文在 CAN 報文設(shè)計中常見的發(fā)送策略有兩類周期報文按固定時間間隔發(fā)送比如電機轉(zhuǎn)速每 10ms 發(fā)送一次節(jié)點狀態(tài)每 100ms 發(fā)送一次。周期報文適合狀態(tài)類數(shù)據(jù)接收方可以通過報文超時判斷發(fā)送節(jié)點是否故障。事件報文當(dāng)某個事件發(fā)生時發(fā)送比如急停按鈕被按下、故障觸發(fā)。事件報文實時性高但要注意限流防止異常情況下節(jié)點瘋狂發(fā)報文。實際系統(tǒng)中通?；旌鲜褂脙烧摺ｊP(guān)鍵控制命令既要快速響應(yīng)又需要接收方及時判斷鏈路是否中斷所以往往采用較短周期發(fā)送或者“事件觸發(fā) 周期兜底”的雙重策略。7.3 節(jié)點故障隔離與總線關(guān)閉策略每個 CAN 節(jié)點都應(yīng)當(dāng)考慮錯誤狀態(tài)監(jiān)控。當(dāng)錯誤計數(shù)器持續(xù)上升說明節(jié)點通信環(huán)境可能存在問題。如果節(jié)點進(jìn)入 Bus Off它會徹底退出總線通信這對汽車、工業(yè)控制來說可能非常危險。更好的做法是在軟件中讀取錯誤狀態(tài)確定是否進(jìn)入被動錯誤或 Bus Off。根據(jù)錯誤等級執(zhí)行降級策略例如停止周期性發(fā)送、保留故障診斷信息、記錄錯誤日志。不要無腦自動恢復(fù)發(fā)送否則總線環(huán)境未恢復(fù)時節(jié)點會反復(fù)制造錯誤幀。需要恢復(fù)時通過錯誤狀態(tài)分析、延時重啟或重新初始化 CAN 外設(shè)來恢復(fù)正常通信。開啟 AutoRetransmission 可以讓硬件自動重發(fā)失敗報文但也要結(jié)合具體場景評估。對于實時性要求極高的控制報文連續(xù)重發(fā)會占用總線時間反而影響其他節(jié)點。7.4 安全與可靠性建議雖然 CAN 協(xié)議本身有 CRC 校驗但在實際工程中仍需要額外的安全措施對重要的報文增加序號和校驗和防止漏幀或數(shù)據(jù)被篡改后仍能通過協(xié)議 CRC。對控制類命令做超時管理接收方在指定時間內(nèi)沒有收到新命令應(yīng)進(jìn)入安全狀態(tài)。懷疑數(shù)據(jù)可靠性時不要直接信任單幀數(shù)據(jù)可以連續(xù)多幀一致后才執(zhí)行。在硬件設(shè)計中CAN 收發(fā)器附近應(yīng)做好 ESD 防護(hù)、TVS 管使用雙絞屏蔽線必要時增加共模電感。信號線應(yīng)避免與電源線、大電流線長期平行走線減少電磁干擾。7.5 接收中斷中少做耗時操作CAN 報文是短報文但遇到高波特率時一秒鐘可能收到幾千幀。如果在接收中斷回調(diào)中做數(shù)據(jù)解析、日志打印、甚至驅(qū)動電機很容易導(dǎo)致中斷溢出。建議把接收回調(diào)只當(dāng)作“數(shù)據(jù)搬運工”從 CAN 控制器讀出數(shù)據(jù)后馬上放入隊列或環(huán)形緩沖區(qū)立刻返回中斷。解析、濾波、協(xié)議處理放到主循環(huán)或?qū)Ｓ萌蝿?wù)中完成。8. 總結(jié)與下一步學(xué)習(xí)建議8.1 本講核心掌握點這一講圍繞 CAN 總線協(xié)議最重要的幾個知識點可以這樣梳理CAN 是一個多主、帶優(yōu)先級仲裁、帶錯誤自檢的串行通信協(xié)議適合實時性要求高的多節(jié)點場景。物理層使用差分信號總線邏輯為“線與”顯性位 0 優(yōu)先級高于隱性位 1。幀結(jié)構(gòu)核心是數(shù)據(jù)幀和遠(yuǎn)程幀標(biāo)準(zhǔn)幀 ID 為 11 位擴(kuò)展幀 ID 為 29 位數(shù)據(jù)最多 8 字節(jié)。錯誤幀頻繁出現(xiàn)時重點排查波特率、終端電阻、線序、共地問題。波特率與采樣點要統(tǒng)一規(guī)劃不能只看名義上的波特率數(shù)值。對嵌入式初學(xué)者來說能做 CAN 收發(fā)只是第一步能夠定位“為什么總線上一堆錯誤幀”才是真正體現(xiàn)調(diào)試能力的地方。8.2 繼續(xù)深入學(xué)習(xí)路線把基礎(chǔ)收發(fā)跑通之后下一步可以往兩個方向深入一是協(xié)議方向。學(xué)習(xí)了裸的 CAN 報文之后可以接觸 CANopen、J1939、UDS 等應(yīng)用層協(xié)議理解它們?nèi)绾位?CAN 幀定義對象字典、報文周期、診斷流程。汽車電子方向特別需要 UDS 和 J1939 的知識。二是系統(tǒng)方向。如果你在做嵌入式 Linux可以學(xué)習(xí) SocketCAN它把 CAN 設(shè)備抽象成網(wǎng)絡(luò)接口應(yīng)用層可以使用標(biāo)準(zhǔn) socket 讀寫 CAN 報文。這樣可以把 CAN 和上位機、復(fù)雜的應(yīng)用邏輯結(jié)合起來工程能力會提升一個臺階。如果你準(zhǔn)備嵌入式面試數(shù)據(jù)幀的字段、仲裁規(guī)則、錯誤幀和錯誤狀態(tài)這幾個點是必刷內(nèi)容。建議親手用開發(fā)板抓一次總線波形把 ID、DLC、CRC、ACK 都對照著看一遍這類經(jīng)驗很難僅靠背概念替代。