CAN 總線這東西搞嵌入式的遲早要碰。不管是做汽車電子、工業(yè)控制還是什么無人機、機械臂只要涉及多個節(jié)點之間穩(wěn)定通信CAN 總是那個繞不開的選項。用一句話概括它一對差分線多節(jié)點掛載無主機依賴靠報文 ID 裁決優(yōu)先級。這套機制聽起來簡單實際用起來細節(jié)極多像位時序采樣、終端電阻匹配、總線仲裁、錯誤處理、過濾器配置每一個環(huán)節(jié)都可能讓你調試到懷疑人生。我?guī)啄昵暗谝淮巫?CAN 通信的項目時也被速率配不對、收發(fā)超時這類問題折磨過。這篇文章不聊虛的直接從原理講到 STM32 上的手寫代碼把我踩過的坑和常用的套路一并交代清楚。這篇文章適合誰看如果你是剛接觸 CAN 的初學者可以從頭讀到尾建立起完整的知識框架如果你已經在用 STM32 做開發(fā)但只是照抄例程、不太清楚底層怎么回事那重點看協(xié)議細節(jié)、寄存器配置和調試經驗部分能解決現(xiàn)實中不少疑惑。整篇文章會用大量類比和實例盡量讓非汽車電子背景的讀者也能輕松跟上。1. 從物理層看懂 CAN為什么它這么抗干擾1.1 差分信號一對線解決所有問題CAN 總線物理層最核心的設計就是差分傳輸。常規(guī)串口用一根信號線對地傳遞電平受地電位差和電磁干擾影響大。CAN 用 CANH 和 CANL 兩根線傳輸電壓差接收端比較兩根線的電壓差來判斷邏輯電平而不是比較某根線對地的絕對電壓。干擾信號通常是共模形式的差分接收天然就把這種共模干擾抵消掉了所以 CAN 在電機、逆變器這類強電磁干擾環(huán)境里依然能穩(wěn)定工作。CAN 的顯性電平也就是邏輯 0對應 CANH 和 CANL 的電壓差約為 2V隱性電平對應邏輯 1電壓差約為 0V。如果你用示波器看總線波形空閑時總線電壓大約在 2.5V 附近波動顯性位會被拉低到 1.5V 左右而 CANH 會被拉高到 3.5V 左右。這種電平定義直接決定了總線仲裁機制的實現(xiàn)基礎后文會詳細展開。1.2 終端電阻不能省也不能亂接標準 CAN 總線要求在總線兩端各接一個 120Ω 終端電阻作用是匹配傳輸線阻抗減少信號反射。如果只接一個、接在中間或者干脆不接板子在短距離低速通信時可能還能工作但波特率一旦提高或者線長達到幾十米就會在隱性到顯性的跳變沿上產生嚴重的信號振鈴導致采樣錯誤。很多用 STM32 的人第一次調試 CAN 不通過就是因為沒接終端電阻。我自己測試時一般直接把 120Ω 電阻做在轉接板上兩端的節(jié)點才各放一個。還有一個常見誤區(qū)是兩個節(jié)點通信時哪怕只有兩個設備也需要在各自端各接一個 120Ω合起來總線上的等效阻抗才是 60Ω這是 CAN 收發(fā)器輸出驅動設計的目標負載。如果兩端各接一個但中間還有其他節(jié)點那就是過度端接同樣會出問題。注意部分開發(fā)板上已經集成了終端電阻并且有跳線開關控制使用前務必確認開關狀態(tài)以免出現(xiàn)兩個電阻并聯(lián)變成了 60Ω 的異常負載。1.3 收發(fā)器選型與電平轉換STM32 內部的 CAN 控制器只是協(xié)議控制器負責數(shù)據鏈路層的幀處理、錯誤管理和位時序它本身不能直接接總線?？刂破鬏敵龅氖?TX/RX 數(shù)字信號必須經過 CAN 收發(fā)器轉換成 CANH/CANL 差分電平才能掛上總線。常用收發(fā)器有 TJA1050、TJA1040、SN65HVD230 等。選型的時候要看速率、工作電壓和待機電流大部分應用選 TJA1050 這類就足夠穩(wěn)定。如果你的 MCU 是 3.3V而收發(fā)器是 5V 供電像 TJA1050即使單片機引腳是 3.3V 推挽輸出CAN 控制器和它對接也一般沒問題因為收發(fā)器的 TXD 輸入閾值兼容 3.3V 邏輯。但要注意有些老式收發(fā)器的高電平輸入閾值偏高最好選擇支持 3.3V 邏輯輸入的型號或者做電平轉換否則偶發(fā)性的發(fā)送異常就很難查了。2. 數(shù)據鏈路層拆解報文格式、仲裁和位填充2.1 標準幀與擴展幀別把 ID 位寬搞混CAN 2.0 協(xié)議定義了兩種幀格式標準幀和擴展幀。標準幀的標識符 ID 是 11 位擴展幀是 29 位后者在多節(jié)點復雜網絡中更常見因為它能容納更多不同優(yōu)先級的報文類型。兩者的幀頭字段區(qū)分就在 IDE 位。幀的基本結構包括 SOF 起始幀、仲裁段、控制段、數(shù)據段、CRC 校驗段、ACK 應答段和 EOF 結束段。其中控制段里的 DLC 表示數(shù)據長度CAN 規(guī)定單幀數(shù)據最多 8 個字節(jié)。很多人會問為什么不用更多這是當年總線速率和工業(yè)場景下的折中設計保證短幀快速傳輸和低延遲。雖然后來出現(xiàn)了 CAN FD數(shù)據段最長可到 64 字節(jié)但直到今天大量設備仍然跑經典 CAN應用層協(xié)議也大多兼容 8 字節(jié)格式。2.2 總線仲裁機制誰優(yōu)先級高誰先走這是 CAN 最核心的設計之一也是它和普通串口總線最大的區(qū)別。多個節(jié)點同時發(fā)送時總線不會像 I2C 那樣需要主機仲裁協(xié)調而是每一位進行比較發(fā)送節(jié)點一邊發(fā) ID 位一邊監(jiān)聽總線電平。如果某個節(jié)點發(fā)送的是隱性位1卻在總線上讀到顯性位0說明有其他節(jié)點在發(fā)送優(yōu)先級更高的報文這個節(jié)點就立刻退出發(fā)送轉為接收下次再自動重發(fā)。這種機制要求 ID 值越小優(yōu)先級越高。因為顯性位 0 能覆蓋隱性位 1ID 前面越多的 0越容易在仲裁中勝出。在工程上通常把控制類報文分配低 ID 值比如剎車、急停這類實時性要求極高的優(yōu)先分配 0x0xx信息類報文分配高 ID比如狀態(tài)監(jiān)測、溫度上報這些允許一定延遲的。設計應用層時如果一開始沒有規(guī)劃好 ID 分配策略后期增加節(jié)點會很痛苦這是實際項目中容易被低估的問題。2.3 位填充和同步機制CAN 協(xié)議規(guī)定連續(xù)發(fā)送 5 個相同電平的位之后必須插入一個相反電平的填充位。接收端在接收時會把這個填充位移除。這樣做的好處是保證總線上不會出現(xiàn)長時間無跳變沿的情況因為接收節(jié)點的時鐘同步依賴于電平跳變沿。收發(fā)雙方的時鐘始終存在微小誤差如果沒有頻繁的跳變沿來重新同步位時序時間一長采樣點就會偏移到錯誤的位區(qū)間通信立刻出錯。這里有個很容易踩的坑位填充規(guī)則不影響 CRC 計算的原始數(shù)據但發(fā)送時 CRC 序列本身也要做填充處理接收端校驗時則需要先剝離填充位。所以調試時別只看數(shù)據幀內容如果抓到的波形異?？紤]是不是位填充邏輯和 CRC 邊界沒對齊特別是你自己實現(xiàn) CAN 協(xié)議或者拿到非標準控制器做兼容時。3. STM32 bxCAN 外設過濾器、報文存儲和中斷3.1 為什么叫 bxCAN它的內存結構是什么樣的STM32 里集成的 CAN 控制器叫 bxCAN基于此前某半導體大廠的 IP 核。它有一個專門的報文存儲區(qū)不是簡單地給每個郵箱分配固定地址而是按照 SRAM 方式訪問控制邏輯來管理。bxCAN 提供 3 個發(fā)送郵箱和 2 個接收 FIFO每個 FIFO 深度為 3 個報文。對絕大多數(shù)應用來說這個硬件緩沖池完全夠用。bxCAN 還有一個顯著特點每個節(jié)點可以配置多個過濾器組STM32F103 系列提供 14 組過濾器F405 等系列更多。過濾器的作用是只讓感興趣的報文進入接收 FIFO不屬于當前節(jié)點的報文直接在硬件層面被丟棄這樣能大幅降低 MCU 的中斷負載。不理解過濾器的工程師容易把接收中斷寫成高頻率觸發(fā)結果 CPU 大部分時間都在處理無關中斷系統(tǒng)響應自然就慢了。3.2 過濾器模式列表模式和掩碼模式怎么選bxCAN 的過濾器支持兩種工作模式列表模式和掩碼模式。列表模式就是精確匹配規(guī)則里寫死的 ID 必須完全一致才接收。掩碼模式則是按位匹配把掩碼中為 1 的位視為需要嚴格匹配為 0 的位視為不關心。實際項目中掩碼模式更適合需要接收一組連續(xù) ID 報文的場景比如接收 ID 0x100 到 0x10F 之間的所有報文只需把掩碼低 4 位置 0其余位置 1。配置過濾器的時候要注意32 位過濾器寬度下標準幀的 ID 在寄存器中存儲位置和擴展幀不同而且數(shù)據位要左移對齊。不少初學者直接拿例程改發(fā)現(xiàn)濾出來的 ID 總是不對其實是因為沒理解寄存器位域的布局。建議配置完過濾器后先開一個全匹配的掩碼模式驗證接收鏈路通了再逐步收窄掩碼這樣能減少排查難度。3.3 發(fā)送郵箱機制與中斷標志發(fā)送時bxCAN 提供 3 個發(fā)送郵箱每個郵箱可以獨立提交報文。軟件提交后硬件自動按照優(yōu)先級順序發(fā)送郵箱中的報文并處理總線仲裁和重發(fā)。發(fā)送完成的標志是郵箱的 TXOK 位置 1這個標志可以通過中斷或輪詢方式讀取。一個常見的工程坑是不考慮郵箱是否空閑就直接往同一個郵箱反復寫數(shù)據導致丟幀。正確的做法是每次發(fā)送前檢查郵箱空滿狀態(tài)或者直接使用發(fā)送完成中斷在中斷回調里處理下一幀數(shù)據。多個節(jié)點或高頻率周期性發(fā)送時三個郵箱很容易被占滿如果發(fā)送失敗標志出現(xiàn)一定要記錄錯誤狀態(tài)并做重發(fā)策略不能悶頭發(fā)。3.4 中斷事件全貌接收中斷、發(fā)送中斷、錯誤中斷和喚醒中斷bxCAN 的中斷可分四類接收 FIFO 有報文時觸發(fā)接收中斷發(fā)送完成時觸發(fā)發(fā)送中斷發(fā)生錯誤時觸發(fā)錯誤中斷還有 CAN 喚醒中斷和睡眠中斷。用 STM32 開發(fā)時有些開發(fā)者只開了接收中斷錯誤中斷沒開結果總線一出錯代碼就跟傻了一樣沒有反饋。真正穩(wěn)定的通信系統(tǒng)錯誤中斷必須開起來哪怕只是在中斷里把一個錯誤計數(shù)器累加也對現(xiàn)場定位問題極其有幫助。接收中斷也分 FIFO0 和 FIFO1 兩個獨立中斷入口對應不同優(yōu)先級的報文策略。可以這樣設計將關鍵控制報文配置到 FIFO0 并開啟高優(yōu)先級中斷普通狀態(tài)報文進 FIFO1 用低優(yōu)先級處理或者直接輪詢這樣高實時性報文的中斷延遲大大縮短這是從實際項目里總結出的實用技巧。4. 手把手 STM32 配置從 CubeMX 到標準庫實戰(zhàn)4.1 波特率計算位時間與采樣點CAN 波特率計算公式是波特率 APB1 時鐘頻率 / (預分頻器 × (同步段 傳播段 相位緩沖段1 相位緩沖段2))。STM32F1 系列的 APB1 時鐘是 36MHz如果目標波特率是 500kbps可以這樣算預分頻 4時間單元 36MHz / 4 9MHz位時間 9000000 / 500000 18 個時間單元。常見分配方式同步段 1TQ傳播段 1TQ相位緩沖段1 為 8TQ相位緩沖段2 為 8TQ總位時間 18TQ。這些段的分配決定采樣點位置。采樣點一般設置在 75% 到 85% 之間比較穩(wěn)定這是綜合考慮線纜延遲、收發(fā)器傳播延遲和時鐘誤差的結果。如果你用 CubeMX 的默認配置BS1 8TQBS2 7TQ同步段 1TQ總位時間就是 16TQ采樣點約 87.5%對大多數(shù)短距離總線來說也行。但如果總線長度較長或者波特率高于 1Mbps建議手動設置采樣點在 80% 左右更穩(wěn)妥。4.2 引腳復用和時鐘配置用 CubeMX 時CAN 引腳默認在 PA11 和 PA12CAN RX 和 TX但確認一下目標板原理圖如果默認引腳被占用或者板子引出了其他復用引腳就需要重新映射。F1 系列 CAN 也支持復用映射到 PB8、PB9配置時要選擇正確的復用功能。初始化順序建議是先配置 GPIO再使能 CAN 外設時鐘然后初始化 CAN 參數(shù)最后配置過濾器。如果順序顛倒可能出現(xiàn) CAN 初始化失敗卻查不到原因的情況。需要提醒的是CAN 外設時鐘和 GPIO 時鐘可能掛在不同的 AHB1/APB1 總線上有些人初始化時忘記開某個時鐘就導致外設不工作這也是常見的低階錯誤。檢查時鐘樹時確認 CAN 和 GPIO 所在總線都已使能。這一點看起來基礎但調試中出現(xiàn)莫名問題后還是值得先排查一遍。4.3 初始化代碼參考下面給出一段基于標準庫風格的初始化參考代碼核心實現(xiàn)步驟與寄存器操作對 HAL 庫同樣適用void CAN_Init_Config(void) { GPIO_InitTypeDef GPIO_InitStructure; CAN_InitTypeDef CAN_InitStructure; CAN_FilterInitTypeDef CAN_FilterInitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_CAN1, ENABLE); GPIO_InitStructure.GPIO_Pin GPIO_Pin_11; // RX GPIO_InitStructure.GPIO_Mode GPIO_Mode_IPU; GPIO_Init(GPIOA, GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin GPIO_Pin_12; // TX GPIO_InitStructure.GPIO_Mode GPIO_Mode_AF_PP; GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOA, GPIO_InitStructure); CAN_DeInit(CAN1); CAN_StructInit(CAN_InitStructure); CAN_InitStructure.CAN_TTCM DISABLE; CAN_InitStructure.CAN_ABOM ENABLE; // 自動離線恢復 CAN_InitStructure.CAN_AWUM ENABLE; CAN_InitStructure.CAN_NART DISABLE; // 自動重傳 CAN_InitStructure.CAN_RFLM DISABLE; // FIFO 不鎖定 CAN_InitStructure.CAN_TXFP DISABLE; // 按 ID 優(yōu)先級發(fā)送 CAN_InitStructure.CAN_Mode CAN_Mode_Normal; CAN_InitStructure.CAN_SJW CAN_SJW_1tq; CAN_InitStructure.CAN_BS1 CAN_BS1_8tq; CAN_InitStructure.CAN_BS2 CAN_BS2_7tq; CAN_InitStructure.CAN_Prescaler 4; CAN_Init(CAN1, CAN_InitStructure); CAN_FilterInitStructure.CAN_FilterNumber 0; CAN_FilterInitStructure.CAN_FilterMode CAN_FilterMode_IdMask; CAN_FilterInitStructure.CAN_FilterScale CAN_FilterScale_32bit; CAN_FilterInitStructure.CAN_FilterIdHigh 0x0000; CAN_FilterInitStructure.CAN_FilterIdLow 0x0000; CAN_FilterInitStructure.CAN_FilterMaskIdHigh 0x0000; CAN_FilterInitStructure.CAN_FilterMaskIdLow 0x0000; CAN_FilterInitStructure.CAN_FilterFIFOAssignment CAN_FIFO0; CAN_FilterInitStructure.CAN_FilterActivation ENABLE; CAN_FilterInit(CAN_FilterInitStructure); CAN_ITConfig(CAN1, CAN_IT_FMP0 | CAN_IT_ERR, ENABLE); }初始化里比較關鍵的兩個參數(shù)是 ABOM自動離線恢復和 NART禁止自動重傳。ABOM 開啟后如果總線因嚴重錯誤進入離線狀態(tài)硬件會自動等待恢復條件再重新參與通信不需要軟件干預。NART 關閉意味著自動重傳開啟發(fā)送失敗的幀會硬件自動重傳直到成功或出錯。這個配置對實時性要求高的場景很重要。如果不想讓一幀失敗數(shù)據一直占用郵箱可以考慮打開 NART自己管理重傳邏輯。提示在雙 CAN 的 STM32 芯片上CAN2 的時鐘來自 CAN1要啟用 CAN2 必須先初始化 CAN1。這個坑很多人到后面才遇到。4.4 發(fā)送報文輪詢與中斷兩種姿勢先寫一個發(fā)送函數(shù)核心操作是選擇一個空閑郵箱、把 ID 和數(shù)據按位域填充進寄存器、提交發(fā)送請求。標準庫寫成這樣uint8_t CAN_SendStdFrame(uint32_t stdId, uint8_t *data, uint8_t len) { CanTxMsg TxMessage; uint8_t i; TxMessage.StdId stdId; TxMessage.ExtId 0; TxMessage.IDE CAN_Id_Standard; TxMessage.RTR CAN_RTR_Data; TxMessage.DLC len; for (i 0; i len; i) { TxMessage.Data[i] data[i]; } if (CAN_Transmit(CAN1, TxMessage) ! CAN_TxStatus_Ok) { return 1; } return 0; }這個函數(shù)只做了發(fā)送提交并不保證報文真的已經上總線。如果需要確認發(fā)送完成需要再輪詢郵箱狀態(tài)或者開發(fā)送完成中斷。實際項目中我一般用一個環(huán)形緩沖區(qū)保存待發(fā)送報文發(fā)送完成中斷里取下一個發(fā)送防止高頻調用發(fā)送函數(shù)時因為郵箱全滿而丟幀。另一個建議是發(fā)送函數(shù)返回錯誤時把錯誤碼記錄下來配合錯誤中斷去判斷是總線錯誤、仲裁丟失還是郵箱滿。如果發(fā)送一直失敗總線電壓、終端電阻、波特率和節(jié)點 ID 沖突是最先要排查的四個方向。4.5 接收報文中斷回調解析接收用中斷最直接。在中斷服務函數(shù)里讀取 FIFO 報文處理完必須清標志。標準庫的接收中斷處理大致如下void USB_LP_CAN1_RX0_IRQHandler(void) { CanRxMsg RxMessage; CAN_Receive(CAN1, CAN_FIFO0, RxMessage); // 根據 RxMessage.StdId 分發(fā)處理 // 放到應用層環(huán)形緩沖區(qū)再置事件標志 }如果 FIFO 溢出中斷可能會進不來此時要檢查溢出標志 CAN_FLAG_FOV0。一旦發(fā)生溢出說明接收處理太慢或丟棄策略有問題需要優(yōu)化中斷里的處理邏輯盡量減少耗時操作只做存 buffer 和置標志具體解析放到主循環(huán)或專用任務里。5. 不得不說的坑波特率容差、錯誤狀態(tài)機和總線離線恢復5.1 波特率容差到底有多大CAN 通信要求每個節(jié)點的位時序誤差保持在特定的容差范圍內。以 500kbps 為例位時間 2us在 16TQ 的采樣點配置下采樣窗口大約是 1.75us 處。晶振精度一般 ±0.1% 到 ±0.5%這是沒問題的。問題是很多人用了內部 RC 振蕩器精度可能到 ±1% 甚至更高在很多情況下也能跑通但總線一旦拉長、干擾變大就容易偶發(fā)錯誤。所以 CAN 通信推薦使用外部晶振或者至少保證所有節(jié)點時鐘精度滿足協(xié)議要求。調試時最有效的辦法是用示波器看總線波形測量顯性位寬度是否等于理論位時間。如果位寬差太多說明波特率配錯了如果位寬正確但波形毛刺密集優(yōu)先檢查終端電阻和線纜質量。總線上如果出現(xiàn)連續(xù)錯誤幀先用 CAN 分析儀抓包看看錯誤幀的類型是填充錯誤、CRC 錯誤還是應答錯誤這些信息能快速定位問題方向。5.2 錯誤計數(shù)器和總線離線恢復機制CAN 控制器內部有發(fā)送錯誤計數(shù)器和接收錯誤計數(shù)器。發(fā)送錯誤每錯誤一次加 8接收錯誤每錯誤一次加 1成功發(fā)送或接收一次則減 1。當發(fā)送錯誤計數(shù)超過 255節(jié)點進入 Bus-Off 狀態(tài)徹底與總線隔離不再發(fā)送任何報文。在 Bus-Off 狀態(tài)下如果 ABOM 使能硬件會自動等待 128 次總線空閑重新恢復如果未使能軟件需要手動觸發(fā)恢復流程。錯誤狀態(tài)可以通過讀取 ESR 寄存器或調用庫函數(shù)狀態(tài)位來獲取。調試時我習慣在主循環(huán)里周期性讀取錯誤計數(shù)一旦發(fā)現(xiàn)持續(xù)增長就說明鏈路存在系統(tǒng)性問題而不是偶發(fā)干擾。工程現(xiàn)場如果出現(xiàn)間歇性 Bus-Off需要考慮屏蔽線接地、總線拓撲結構不要接成星形以及線纜長度與波特率的匹配關系。5.3 用測試模式驗證硬件鏈路在查詢具體協(xié)議問題之前先用回環(huán)模式驗證 MCU 那一側是否正常。bxCAN 支持靜默回環(huán)模式Silent Loopback和回環(huán)模式Loopback?；丨h(huán)模式中控制器發(fā)出的報文會在內部直接被接收不經過外部收發(fā)器。初始化時把 CAN_Mode 設置為 CAN_Mode_LoopBack然后自發(fā)自收如果接收成功說明控制器和中斷配置沒問題再切到 Normal 模式并連接總線測試如果失敗問題就鎖定在收發(fā)器、接線或對端節(jié)點。這個簡明的排除法能省大量時間特別是多人協(xié)作調試時可以先各自確認自發(fā)自收通過再對接聯(lián)調避免兩邊互相懷疑浪費精力。6. 實戰(zhàn)經驗工程中如何設計與調試一套 CAN 節(jié)點6.1 應用層協(xié)議設計選擇實際做一個 CAN 項目首先要確定應用層協(xié)議。CAN 2.0 只規(guī)定了物理層和數(shù)據鏈路層的幀格式并沒有定義數(shù)據內容的標準含義所以每個項目都要自己約定報文 ID 映射和數(shù)據字段含義。工業(yè)領域常用 CANopen汽車領域常用 J1939這些協(xié)議棧已經幫你規(guī)劃了 ID 分配、對象字典、周期通信和診斷機制。如果是簡單應用自己定義一套輕量協(xié)議也完全可行關鍵要在一開始就明確哪些報文是周期發(fā)送哪些是事件觸發(fā)哪些是主站請求哪些是從站主動上報。我的習慣是先整理一張報文定義表列出每個 ID 的發(fā)送節(jié)點、接收節(jié)點、周期、數(shù)據長度、字節(jié)含義和字節(jié)序。后期調試對照這張表比翻代碼快得多。尤其是多團隊協(xié)作時這張表本身就要同步更新不然代碼寫出來各調各的聯(lián)調必然一團亂。6.2 多節(jié)點組網和線纜規(guī)則CAN 總線拓撲推薦直線型也就是一根主線上掛所有節(jié)點每個節(jié)點的連接 STUB 線盡量短。STUB 線超過 1 米時高速通信很容易出現(xiàn)信號反射。工業(yè)現(xiàn)場如果節(jié)點分散考慮使用帶 CAN 收發(fā)器的中繼器做分段隔離。總線供電方式也有講究有些設備回環(huán)供電但同一網絡中多個節(jié)點供電時要注意地電位差不要太大不然即使有共模抑制也扛不住地面環(huán)路噪音。最好在網絡兩端之一做單點接地。終端電阻的選擇上標準 120Ω 是常規(guī)配置但低速短距離應用有時會用 1kΩ 甚至不接也能工作。從長期可靠性的角度我不建議利用這種無意中的寬松性還是按規(guī)范來這樣設備和設備之間互換時不會出莫名其妙的問題。6.3 測試工具CAN 分析儀和示波器做 CAN 開發(fā)最好有一臺 CAN 分析儀市面上很多 USB 轉 CAN 的小工具價格不貴。它可以抓取總線報文、模擬節(jié)點發(fā)送、統(tǒng)計錯誤幀功能非常實用。沒有分析儀時示波器也是必需品至少能觀察波形、測量位寬度和跳變沿質量。示波器探頭要接在 CANH 和 CANL 之間也就是差分測量不要分別對地測量然后口頭比較誤差那樣很容易被噪聲誤導。調試時如果發(fā)現(xiàn)總線波形高電平不到 3.5V 或者電壓擺幅偏小檢查收發(fā)器供電電壓是否偏低。波形上升沿明顯傾斜先懷疑線纜電容太大或驅動能力不足必要時更換更高驅動能力的收發(fā)器。波形上莫名其妙的凹陷和振鈴檢查 STUB 線和終端電阻位置。這些觀察比盲目改代碼高效得多。6.4 高可靠場景的冗余與診斷設計在一些穩(wěn)定性要求極高的場景比如電梯控制、車輛通信CAN 網絡往往采用雙冗余總線或者增加健康狀態(tài)報文。健康狀態(tài)報文就是節(jié)點周期性上報運行狀態(tài)、錯誤計數(shù)和供電電壓等信息主控側一旦超時未收到某個節(jié)點的健康報文就能作出離線判斷。這個設計不復雜對定位故障節(jié)點和總線故障非常有幫助。還可以考慮使用 CAN 的遠程幀RTR機制讓主站請求從站數(shù)據。遠程幀的優(yōu)先級和數(shù)據幀一樣靠 ID 仲裁。不過遠程幀的應用沒有想象中那么普遍在很多協(xié)議棧里已經弱化了自己設計協(xié)議時按需使用即可不要為了用而用。7. 常見問題速查表與調試技巧下面整理一份經常遇到的 CAN 故障排查表基本都是我在實際項目中反復看到的問題現(xiàn)象可能原因排查方向完全收不到報文終端電阻未接或接錯示波器測 CANH/CANL 波形確認顯隱性電平變化波特率不一致節(jié)點配置的位時序不通計算各節(jié)點實際波特率比對采樣點偶發(fā)錯誤幀STUB 線過長、接線松動檢查拓撲抓錯誤幀類型看 CRC 錯誤比例某個節(jié)點單獨發(fā)不出過濾器配置錯誤先開全匹配掩碼確認鏈路總線處于 Bus-Off嚴重短路或 ID 沖突斷開節(jié)點逐個排查檢查線纜是否短路發(fā)送超時且 error 計數(shù)持續(xù)增長對端節(jié)點不存在確認節(jié)點是否上電、地址是否匹配、ACK 是否正常還有一個容易被忽略的問題STM32 復位期間CAN 引腳是默認的浮空輸入狀態(tài)。如果在復用外設配置完成后才初始化這段時間內引腳可能被外部總線電平影響導致寄生上電或電平競爭問題。板子上若有其他外設復用同一引腳務必檢查引腳沖突這也是排查 CAN 不工作的一個方向。調試技巧方面我想強調日志的重要性。如果固件里開了錯誤中斷把錯誤狀態(tài)和時間戳打印到調試串口存成日志聯(lián)調時對照時間軸分析總線事件很多時候能直接定位是哪個節(jié)點在哪一步觸發(fā)了錯誤。我見過不少同事調試時不打錯誤日志就靠眼睛盯邏輯分析儀效率確實低很多。再一個技巧是開發(fā)階段抓包記錄正常發(fā)送報文的周期和時序作為后續(xù)回歸測試的基準改代碼后如果報文時序出現(xiàn)明顯漂移說明代碼引入了額外延遲。8. 從 CAN 到 CAN FD后續(xù)擴展思路CAN FDCAN with Flexible Data-rate是經典 CAN 的升級版最大變化是數(shù)據段可以長達 64 字節(jié)并且在數(shù)據段支持更高的可變速率。它和經典 CAN 在幀格式上做了兼容設計總線上可以混合運行但需要所有節(jié)點都支持才能完全發(fā)揮 FD 特性。新項目中如果確定未來會有大數(shù)據量傳輸、固件升級這類需求直接選支持 CAN FD 的 MCU如 STM32F405 以上系列是更長遠的選擇。固件升級是 CAN 應用的經典場景通過 CAN 總線把新的固件分包發(fā)給目標節(jié)點節(jié)點收到后寫入 Flash 再跳轉運行。這個功能對通信可靠性的要求比普通控制報文更高通常需要一個簡單的傳輸層協(xié)議包括幀序號、總幀數(shù)、CRC32 校驗和重傳機制。實現(xiàn)這類功能時參考 CANopen 的 SDO 分段傳輸思想會很有啟發(fā)它把大塊數(shù)據拆成多幀傳輸?shù)臋C制非常成熟完全可以借鑒。還有多 CAN 網絡橋接的需求比如車身網絡和動力網絡之間需要網關。網關節(jié)點用兩個 CAN 通道分別接入兩個網絡類似 STM32F105 的雙 CAN 特性內部做 ID 映射和數(shù)據轉發(fā)。這種場景下過濾器和發(fā)送優(yōu)先級配置尤為重要否則大量無關報文穿過網關會顯著增加負載。我在實際使用中對 CAN 最大的感受是它是一種需要從物理層、協(xié)議層到應用層全鏈路理解的總線。有時候問題明明出在應用層的 ID 規(guī)劃不合理但排查時總習慣先懷疑硬件。反過來也一樣很多人代碼調了很久最后發(fā)現(xiàn)是時鐘精度不夠或者終端電阻沒焊。所以我建議新做 CAN 項目的朋友先不要急著上代碼把協(xié)議設計、硬件連接和調試工具都想清楚后面能省下大量時間。最后再分享一個小技巧在 STM32 工程里提前寫好一個 CAN 狀態(tài)打印函數(shù)周期性輸出錯誤計數(shù)、發(fā)送失敗次數(shù)、接收 FIFO 剩余空間等數(shù)據。這個函數(shù)在開發(fā)階段和現(xiàn)場調試階段都能用稍微花點時間回報率非常高。等以后做復雜網絡時你會發(fā)現(xiàn)當初花在調試工具上的時間遠比想象中值錢。