搞嵌入式或者汽車電子的朋友對CAN總線應該都不陌生。車載網(wǎng)絡里到處是CAN發(fā)動機、車身控制器、電池管理、儀表全靠一根差分對在傳數(shù)據(jù)。去年我在某個項目上寫了一套CAN通信代碼當時主要是驗證功能跑得倒也正常但一放到真實工程里就暴露出不少問題配置寫死在代碼里、接收靠輪詢、多幀數(shù)據(jù)來不及處理會丟、出錯之后不會恢復傳輸中斷只能重啟。這次出的升級版把這些問題逐個收拾掉了順手把結(jié)構(gòu)重構(gòu)成能直接拿到其他項目復用的模塊。這篇文章主要講清楚升級版是怎么設計的、每個模塊為什么這么寫、移植時又踩了哪些坑適合正在寫或者準備用CAN通信代碼的嵌入式工程師尤其是想從“能收發(fā)”往“可靠收發(fā)”走一步的朋友。1. 升級版究竟升級了什么先給初版“算算賬”1.1 初版代碼的幾個經(jīng)典痛點先說初版代碼。當時驗證功能思路很簡單初始化一個CAN控制器配置好波特率然后在主循環(huán)里輪詢接收標志位有幀就進中斷或者標志判斷里讀出來打印到串口。代碼幾十行就能跑通在桌面上用兩個開發(fā)板對測效果挺理想?？墒虑橐坏Q到真實項目里問題就全冒出來了。第一個痛點是配置硬編碼。波特率、濾波ID、工作模式全都寫在初始化函數(shù)里換一個MCU型號整個文件就得重寫甚至同一個芯片換了一個應用場景也要重新翻代碼改參數(shù)。這個問題的根源不是配置項本身多而是配置和驅(qū)動邏輯攪在一起一改配置就容易把驅(qū)動邏輯改壞。第二個痛點是純輪詢收發(fā)。主循環(huán)在等著一幀數(shù)據(jù)的時候如果總線上一段時間沒有報文整個CPU全被空轉(zhuǎn)占掉中斷里有數(shù)據(jù)要處理的時候主循環(huán)又在忙其他的兩邊一撞就丟幀。說白了就是沒有緩沖機制數(shù)據(jù)來一條收一條收不過來就放棄。第三個痛點是錯誤處理約等于零。初版代碼只在出錯時點亮一顆LED具體是什么錯誤、需不需要恢復、恢復之后怎么重新參與通信完全沒有設計。CAN總線上任何一個節(jié)點出錯進入bus-off狀態(tài)如果不處理整個節(jié)點就永遠脫離網(wǎng)絡了這在整車上是很嚴重的問題。1.2 升級版定下的四個目標升級版動手之前我給自己定了四個目標后面所有代碼都是圍繞這四個目標展開的。一是可配置。所有的波特率、過濾器、工作模式、中斷優(yōu)先級全部通過配置文件注入驅(qū)動代碼里不允許出現(xiàn)魔法數(shù)字。這樣換個場景只需要改配置頭文件驅(qū)動層一行不用動。二是可移植。把代碼分成兩層跟具體芯片寄存器相關(guān)的HAL層和通用邏輯的協(xié)議/驅(qū)動層。換芯片只改HAL層上層邏輯原封不動搬走。這一步看似費工但_project多了以后回報很高。三是可靠。錯誤計數(shù)器要能讀出來狀態(tài)遷移要有清晰邏輯bus-off要能自動恢復收發(fā)要有緩沖區(qū)不能讓“來不及處理”成為丟幀的借口。四是可擴展。數(shù)據(jù)結(jié)構(gòu)里預留好擴展幀、遠程幀、CAN FD幀的位置后續(xù)如果需要診斷協(xié)議或升級到CAN FD不用把整個模塊重寫。這四條定下來整個代碼的骨架就比較清楚了。下面直接說架構(gòu)和實現(xiàn)。2. 代碼怎么分層才經(jīng)得起折騰一個清晰的框架比什么都重要2.1 從“裸機直寫”到“分層模塊”的思路初版代碼最大的問題就是“一把梭”。所有邏輯都堆在一個文件里寄存器操作、協(xié)議解析、應用處理全部混在一起看著代碼不多維護起來很痛苦。升級版第一件事就是把職責拆開。我采用的是四層結(jié)構(gòu)應用層只需要調(diào)用發(fā)送接口、注冊接收回調(diào)完全不關(guān)心CAN控制器寄存器長什么樣。協(xié)議/驅(qū)動層負責幀封裝、解析、校驗、過濾規(guī)則匹配這里不出現(xiàn)具體寄存器操作。HAL層封裝所有跟芯片相關(guān)的寄存器讀寫、中斷入口、時鐘配置這一層換平臺時才動。配置層一份配置文件定義波特率、過濾器、通道數(shù)量和回調(diào)函數(shù)。打個比方這就像快遞鏈條。HAL層是各家物流網(wǎng)點負責把包裹搬上車協(xié)議層是運輸路線和分揀規(guī)則應用層是收件人只關(guān)心包裹到?jīng)]到、內(nèi)容對不對。各干各的哪一環(huán)壞了只修那一環(huán)不用把整條鏈拆了。層與層之間的接口要定義干凈。我用一個can_send(ch, msg)和一個接收回調(diào)can_on_rx(ch, msg)作為上下層之間的唯一通道。HAL層收到中斷把數(shù)據(jù)搬進緩沖區(qū)驅(qū)動層在緩沖區(qū)里取幀應用層在回調(diào)里拿最終結(jié)果。這樣每一層都能單獨測試也方便將來換成RTOS環(huán)境。2.2 核心數(shù)據(jù)結(jié)構(gòu)是怎么設計的升級版里最重要的一個結(jié)構(gòu)體是報文消息所有上層收發(fā)都靠它傳遞數(shù)據(jù)。我把它設計成這樣typedef struct { uint32_t id; /* 標準幀11bit擴展幀29bit */ uint8_t data[64]; /* 經(jīng)典CAN最多8字節(jié)CAN FD最多64字節(jié) */ uint8_t dlc; /* 當前幀實際數(shù)據(jù)長度 */ uint8_t ch; /* 通道號多路CAN時用 */ uint8_t flags; /* bit0: 擴展幀; bit1: 遠程幀; bit2: FD幀 */ uint32_t ts_ms; /* 接收時間戳單位毫秒 */ } can_msg_t;這里每個字段都有講究。id用uint32_t是為了同時容納標準幀和擴展幀避免為ID類型單獨開兩個結(jié)構(gòu)體。data[64]看著有點浪費但我特意留到64字節(jié)因為后續(xù)如果做CAN FD升級數(shù)據(jù)結(jié)構(gòu)這塊就不用再動了。flags比單純一個bool好用它把所有“幀類型”信息合成一個字節(jié)將來加新類型也容易。ts_ms是最容易被忽略的字段但調(diào)試的時候特別有用——能知道某條報文距離上一條過去了多久定位周期超時問題靠它。配置文件里的過濾器和運行參數(shù)也用結(jié)構(gòu)體統(tǒng)一管理typedef struct { uint32_t id; /* 參考ID */ uint32_t mask; /* 掩碼0表示不關(guān)心1表示必須匹配 */ uint8_t extended; /* 1-擴展幀0-標準幀 */ } can_filter_t; typedef struct { uint32_t baudrate; /* 期望波特率如500000 */ uint8_t sample_pos; /* 采樣點百分制建議75~85 */ uint8_t mode; /* 0-正常1-回環(huán)2-靜默 */ can_filter_t filters[8]; uint8_t filter_num; uint8_t fd_enable; /* 是否啟用CAN FD */ } can_config_t;為什么過濾規(guī)則要用“ID 掩碼”而不是給一串ID列表因為當前市面上的CAN控制器幾乎都支持“掩碼模式”內(nèi)核里是一套位比較邏輯比逐個ID匹配省資源而且能通過一個配置覆蓋一段地址范圍的幀。比如要接收ID 0x100到0x10F的所有幀列表模式要寫16條掩碼模式一條就夠ID設為0x100掩碼設為0x1F0低4位不關(guān)心。2.3 環(huán)形緩沖區(qū)中斷和主循環(huán)之間的“快遞中轉(zhuǎn)站”這個問題在初版代碼里完全沒處理升級版必須補上。真實總線上數(shù)據(jù)不會等你主循環(huán)可能在刷寫Flash或者在處理優(yōu)先級更高的事中斷里讀出來的幀不可能一直保存在寄存器里必須搬到內(nèi)存緩沖區(qū)。收發(fā)兩端速度不匹配就用一個隊列來“削峰填谷”。我用的是一塊環(huán)形緩沖區(qū)變量就兩個head寫指針和tail讀指針。#define RX_FIFO_SIZE 32 typedef struct { can_msg_t buf[RX_FIFO_SIZE]; volatile uint16_t head; volatile uint16_t tail; uint32_t overruns; } can_rx_fifo_t; static void fifo_push(can_rx_fifo_t *f, const can_msg_t *m) { uint16_t next (uint16_t)((f-head 1) % RX_FIFO_SIZE); if (next ! f-tail) { f-buf[f-head] *m; f-head next; } else { f-overruns; } } static int fifo_pop(can_rx_fifo_t *f, can_msg_t *m) { if (f-head f-tail) { return 0; } *m f-buf[f-tail]; f-tail (uint16_t)((f-tail 1) % RX_FIFO_SIZE); return 1; }這套代碼看著簡單有幾個關(guān)鍵點必須注意。head和tail加了volatile因為它們在中斷和主循環(huán)兩側(cè)被訪問。單生產(chǎn)者單消費者模式下中斷只寫head主循環(huán)只寫tail不需要加鎖但如果你用了我上面這種“先取next再判斷滿”的寫法要確認編譯器的內(nèi)存序處理。更穩(wěn)妥的做法是在fifo_push前后關(guān)閉CAN接收中斷但那樣會增加中斷關(guān)閉時間我在實測中采用“只用兩個變量順序?qū)憽钡姆桨概芰艘荒甓鄾]出問題。如果你的平臺有DMA或者雙核共享內(nèi)存這里需要重新評估。緩沖區(qū)大小RX_FIFO_SIZE選32幀。經(jīng)典CAN一條報文最多8字節(jié)32幀也就256字節(jié)對RAM壓力幾乎為零。但如果你跑的是那種一包接一包的刷寫場景建議評估峰值幀率算出一個保守值再往上加。我后面的調(diào)試經(jīng)歷里就因為這個吃了虧。3. 核心代碼實現(xiàn)全過程該抄作業(yè)的環(huán)節(jié)都在這了3.1 配置項與波特率計算用公式替代魔法數(shù)字配置文件的引入讓“換個波特率就要翻代碼”這件事徹底成為過去。但配置只是第一步波特率怎么計算成寄存器值里面的坑不少。CAN的位時間由四段組成同步段、傳播段、相位緩沖段1、相位緩沖段2。波特率公式是can_bus_clk / (presc * (1 seg1 seg2))其中同步段固定在1個TQseg1是傳播段加相位緩沖段1seg2是相位緩沖段2。采樣點就是(1 seg1) / (1 seg1 seg2)一般建議75%到85%之間放在比較靠后的位置是因為總線存在信號傳播延遲和節(jié)點時鐘偏差采樣點太靠前容易誤判顯性位的邊沿。我寫了一個工具函數(shù)傳入外設時鐘、目標波特率和采樣點百分比自動算出預分頻和段長度static int can_brr_calc(uint32_t sys_clk, uint32_t baud, uint8_t sample_point, uint32_t *brr_reg) { uint32_t target sys_clk / baud; for (uint32_t ps 1; ps 64; ps) { if (target % ps ! 0) { continue; } uint32_t tq target / ps; if (tq 8 || tq 25) { continue; } uint8_t seg1 (uint8_t)((tq * sample_point / 100) - 1); uint8_t seg2 (uint8_t)(tq - seg1 - 2); if (seg1 1 seg2 1 seg2 8) { *brr_reg (ps - 1) | ((seg1 - 1) 8) | ((seg2 - 1) 12); return 0; } } return -1; }這里brr_reg的位域定義是我按通用CAN控制器畫的示意具體芯片可能不同但“預分頻、時間段1、時間段2”三段式的思路是通用的。拿到實際數(shù)據(jù)手冊后把位域的位置對應改一下就能用。說一個經(jīng)驗target sys_clk / baud能整除的情況最理想如果除不盡別硬湊。有一條CAN規(guī)則是位時間TQ總數(shù)差值不能太大8到25這個范圍是我在實際選型時常用的安全區(qū)間。波特率偏差大于1.5%左右就很難在一個長報文上保證同步了所以優(yōu)先選能整除的預分頻值。采樣點這個值也值得認真選。我在一個項目里剛開始用50%的采樣點點對點通信沒問題可一旦總線掛了十幾個節(jié)點、線纜長度超過3米錯誤幀明顯變多。改成80%之后問題消失。原因就是采樣點太靠中間干擾疊加后很容易在采樣時刻讀到錯誤電平。建議不要低于70%。3.2 初始化流程的順序不能亂初始化代碼很多人隨手寫先配置GPIO再開啟時鐘或者先配CAN控制器再配過濾器。實際上順序錯了大概率跑不通。我整理了一個穩(wěn)定的初始化順序?qū)懗珊瘮?shù)后就不用再動開啟CAN外設時鐘、GPIO時鐘配置CAN_TX、CAN_RX引腳為復用功能先退出初始化模式再進設置模式按控制器狀態(tài)機要求操作把波特率寄存器值寫入位時序寄存器設置工作模式正常/回環(huán)/靜默配置過濾器組和掩碼清空中斷標志使能收發(fā)中斷請求進入正常模式確認模式切換成功。這里第3步和第8步是最容易漏的。很多控制器有“初始化模式”和“正常模式”之間的切換過程模式切換不是瞬間完成要讀模式狀態(tài)寄存器確認如果直接寫一個“請求正常模式”的位然后立刻開中斷中斷往往沒真正觸發(fā)。初始化失敗的情況真要遇到我建議把模式狀態(tài)寄存器、時鐘狀態(tài)寄存器、錯誤寄存器全部打出來先確認控制器是不是真的進了想要的狀態(tài)。別急著改GPIO配置因為大部分“一上電不能通信”的問題根本不是引腳配錯而是模式?jīng)]切過去。3.3 報文發(fā)送阻塞、超時與發(fā)送完成標志發(fā)送函數(shù)的設計核心是“不能因為發(fā)送失敗把主循環(huán)堵死”。我種做法是發(fā)送函數(shù)只負責“把幀寫入發(fā)送郵箱并請求發(fā)送”發(fā)送完成與否交給發(fā)送完成中斷來置標志。主循環(huán)調(diào)用發(fā)送函數(shù)時等待一個超時時間超時就返回錯誤。int can_send(uint8_t ch, can_msg_t *msg) { can_dev_t *dev g_can[ch]; uint32_t tickout get_ticks() 10; while (dev-tx_busy) { if (tick_before(get_ticks(), tickout)) { return CAN_ERR_TIMEOUT; } } if (dev-mode CAN_MODE_LOOPBACK) { /* 回環(huán)模式直接進接收路徑不走總線 */ } fill_tx_mailbox(dev, msg); dev-tx_busy 1; return CAN_OK; }這個實現(xiàn)看著簡單背后的思路是“忙標志”管理。tx_busy在發(fā)送完成中斷里被清零void CAN_TX_ISR(can_dev_t *dev) { if (tx_ok_flag(dev)) { dev-tx_busy 0; clear_tx_ok_flag(dev); } }為什么要用發(fā)送完成中斷而不是發(fā)送請求后直接說完成因為硬件寫進郵箱只是“排隊成功”真正把報文發(fā)送到總線上還需要時間如果郵箱忙或總線正處于錯誤恢復階段請求發(fā)送的動作可能失敗。等發(fā)送完成中斷拉低tx_busy才能準確知道這幀已經(jīng)送出去了。發(fā)送失敗時控制器會置一個錯誤標志此時及時清標志并返回應用層才能決定是否重發(fā)。阻塞等待的10ms是拍腦袋定的嗎不是。500kbps下最長的經(jīng)典CAN報文擴展幀8字節(jié)數(shù)據(jù)總長約145ns到160ns換算下來1ms能傳幾千幀發(fā)送一幀從請求到送出的時間在微秒到幾百微秒量級。10ms的超時足夠?qū)捜萦帜懿m住“控制器已經(jīng)異?！边@種嚴重情況。如果你的波特率特別低比如125kbps單幀時間會更長超時值要相應放大。3.4 中斷接收、過濾器與回調(diào)處理接收這半邊是升級版的重頭戲。我的做法是CAN接收中斷里用最快的速度把郵箱里的幀搬進環(huán)形緩沖區(qū)清標志位然后把“有數(shù)據(jù)”這件事用一個全局標志暴露給主循環(huán)主循環(huán)或應用層再從緩沖區(qū)里取幀處理。中斷服務函數(shù)里只有三個動作任何多余判斷都往外拿void CAN_RX_ISR(can_dev_t *dev) { while (rx_mailbox_pending(dev)) { can_msg_t m; read_rx_mailbox(dev, m); fifo_push(dev-rx_fifo, m); } clear_rx_flag(dev); }這里用while循環(huán)把郵箱里所有待讀幀一次搬完清一次標志就行。如果你在中斷里只讀一幀就退出而硬件FIFO里還有好幾幀下次中斷什么時候來就不確定了——有的控制器會立刻重新觸發(fā)有的不會表現(xiàn)就是“丟幀其實是沒讀干凈”。這是我踩過的一個坑。過濾器這塊單獨說一下。掩碼模式下的“1”到底是“必須檢查”還是“忽略”不同芯片定義不一樣有的甚至反過來。我看到很多初學者在這里栽過配置完過濾器之后一條幀都收不到或者什么幀都能收到。所以我的建議是先回環(huán)模式跑一遍確認過濾邏輯跟預期一致再接真實總線。void CAN_FILTER_CFG(can_dev_t *dev, can_filter_t *f, int num) { /* 對每個f按芯片寄存器要求寫入ID和掩碼 */ for (int i 0; i num; i) { set_filter_id(dev, i, f[i].id); set_filter_mask(dev, i, f[i].mask); set_filter_ext(dev, i, f[i].extended); } }應用層收數(shù)據(jù)的回調(diào)我故意做得很薄回調(diào)里只允許做兩件事拷貝消息、置一個“應用層待處理”的信號量或標志。絕對不要在回調(diào)里做協(xié)議解析、打印或者Flash寫入。原因很簡單回調(diào)如果執(zhí)行時間過長接收緩沖區(qū)很快就滿了新幀只能被丟棄。真實項目中我有一次把一條UDS響應解析放在接收回調(diào)里結(jié)果刷寫速率一下子掉了30%去掉之后立刻恢復。3.5 錯誤狀態(tài)遷移與自動恢復錯誤處理是升級版里最值錢的部分。CAN控制器內(nèi)部有發(fā)送錯誤計數(shù)和接收錯誤計數(shù)兩個寄存器根據(jù)計數(shù)大小節(jié)點會處于三種狀態(tài)狀態(tài)錯誤計數(shù)范圍行為表現(xiàn)錯誤主動0 ~ 127正常參與通信出錯時可以主動發(fā)送錯誤幀錯誤被動128 ~ 255只監(jiān)聽總線不能主動發(fā)錯誤幀重傳前需要等待6個隱藏位總線關(guān)閉256以上完全脫離總線既不收發(fā)也不應答真實項目里最容易出現(xiàn)的是連上總線后誰都不說話查了半天發(fā)現(xiàn)某個節(jié)點的錯誤計數(shù)已經(jīng)超過256處于bus-off狀態(tài)。這種情況下的恢復策略是void can_err_state_update(can_dev_t *dev) { uint8_t tec get_tec(dev); uint8_t rec get_rec(dev); if (dev-err_state ERR_BUSOFF) { if (tec 0) { /* 控制器內(nèi)部已經(jīng)恢復重新參與通信 */ dev-err_state ERR_ACTIVE; request_normal_mode(dev); } return; } if (tec 128 || rec 128) { dev-err_state ERR_PASSIVE; } else { dev-err_state ERR_ACTIVE; } }總線關(guān)閉的恢復不同控制器有不同策略。有些硬件會自動重發(fā)等待有些需要軟件把控制器復位重來一遍。我的建議是能軟件恢復就不要硬件斷電。在整車環(huán)境里一個節(jié)點反復重啟會拖累整個網(wǎng)絡的穩(wěn)定性而且重啟過程中如果總線上正好在跑多幀傳輸也容易干擾其他節(jié)點。錯誤中斷里除了讀計數(shù)還要記一條日志。哪怕是往一個全局數(shù)組里塞一個錯誤碼也比“亮個燈然后什么都不知道”強。我調(diào)試時最常用的做法是把錯誤碼和時間戳打印出來看是發(fā)送錯誤、接收錯誤還是應答錯誤——總線負載高時這三種錯誤的處理思路完全不一樣。4. 移植和調(diào)試中遇到的典型問題這些問題基本人人都遇到過4.1 波特率差一點點總線就靜默我遇到過一個很典型的問題兩個板子都配置成500kbps軟件里波特率寄存器看起來也對但連上總線就是通信失敗用示波器看波形卻看不出問題。后來用CAN協(xié)議分析儀去讀實際波特率發(fā)現(xiàn)一個節(jié)點實際是497kbps另一個是503kbps差了1.2%。單幀短的時候沒事一碰上連續(xù)多幀傳輸偶爾就撞出錯誤幀表現(xiàn)成“時好時壞”。原因是兩個節(jié)點用了不同的時鐘源一個外接20MHz晶振精度高另一個用的是MCU內(nèi)部RC振蕩器標稱20MHz實際偏差在±1%以上。這種問題在實驗室用開發(fā)板測試時不容易出現(xiàn)因為開發(fā)板上都有晶振一放到量產(chǎn)的控制器上就暴露了。排查思路是先用工具函數(shù)把波特率誤差算出來再確認兩個節(jié)點的時鐘源精度如果對精度沒把握優(yōu)先選低波特率比如把500k降到250k容忍度會高很多。4.2 過濾器把該收的幀全擋了過濾器的問題是“配了等于沒配”和“不配就收垃圾”兩個方向都存在。有過一次經(jīng)歷我把過濾器配置成“全部通過”結(jié)果總線上所有節(jié)點的報文都進了緩沖區(qū)主循環(huán)被塞到死循環(huán)其它任務全卡住。問題根源不是緩沖區(qū)太小而是“所有幀都接收”這個配置讓中斷頻率變得極高CPU大部分時間花在搬數(shù)據(jù)上。反過來把掩碼配成“全部必須精確匹配”之后一條幀都收不到。排查時看了半天最后發(fā)現(xiàn)是掩碼寄存器里面位定義里1表示忽略而不是必須匹配我之前理解反了。所以這個坑的教訓是寫過濾寄存器前先把數(shù)據(jù)手冊里“mask”位的含義抄到代碼注釋里避免下次再踩。過濾器還有一個容易出錯的地方是擴展幀和標準幀的ID存放位置不一樣。29位擴展ID在寄存器里被拆成兩段低16位和高13位你如果按標準幀的11位格式往寄存器里塞擴展幀永遠收不到。4.3 字節(jié)序、位序、DLC的坑CAN協(xié)議本身并沒有規(guī)定數(shù)據(jù)場的字節(jié)序用大端還是小端完全看應用層怎么定義。做整車診斷的時候經(jīng)常遇到兩種格式混用有的信號按Motorola格式高字節(jié)在前有的按Intel格式低字節(jié)在前。初版代碼里我直接拿memcpy復制數(shù)據(jù)結(jié)果解析出來的值完全不對。正確的做法是寫專門的打包/解包函數(shù)所有跨字節(jié)的信號都明確指定字節(jié)序和位序不要依賴編譯器對齊和平臺端序。要警惕DLC。DLC是數(shù)據(jù)長度代碼在某些變種協(xié)議里它代表的是“數(shù)據(jù)長度相對8的倍數(shù)”而不是真正的字節(jié)數(shù)。CAN FD出現(xiàn)后DLC編碼方式變了8字節(jié)以下表示通常長度8以上按離散值對應到12、16、20、24等。所以我在數(shù)據(jù)結(jié)構(gòu)里專門存真實的dlc收發(fā)轉(zhuǎn)換時在驅(qū)動層做一次編碼映射上層永遠只跟“真實字節(jié)數(shù)”打交道。4.4 高負載下丟幀與接收溢出在某個刷寫場景里上位機以接近零間隔的方式發(fā)UDS寫入請求一包接一包不停地發(fā)升級版代碼出現(xiàn)了偶發(fā)丟幀。排查時先看接收緩沖區(qū)overruns計數(shù)器發(fā)現(xiàn)確實有溢出于是把RX_FIFO_SIZE從16改成32情況好了很多但壓力再大時還是偶發(fā)。進一步的定位是主循環(huán)里在處理其它任務處理時間超過了相鄰兩幀的間隔緩沖區(qū)的讀取速度跟不上寫入速度。最終方案不是無限加大緩沖區(qū)而是做了三件事把CAN接收中斷的優(yōu)先級提到最高一級確保中斷響應不會被別的任務阻塞中斷里只拷貝不做處理主循環(huán)里的耗時操作全部改到空閑時間片執(zhí)行。這樣改動之后即使緩沖區(qū)只有16幀也很穩(wěn)。這里想強調(diào)一點緩沖區(qū)空間是預算不是容量。如果設計時讓緩沖區(qū)經(jīng)常處于接近滿的狀態(tài)說明系統(tǒng)整體處理能力不足該優(yōu)化的是處理路徑而不是緩沖區(qū)。4.5 “能發(fā)不能收”的排查流程“能發(fā)不能收”是我收到問得最多的問題。這類問題的排查有一個固定套路按順序走一遍大部分都能快速定位。第一先確認是不是回環(huán)模式?jīng)]關(guān)。如果控制器的回環(huán)模式開啟發(fā)出的幀不會出現(xiàn)在總線上自己又能收到從本機看“收發(fā)都正?！绷硪慌_設備當然什么都收不到。第二檢查接收中斷是否使能這個看似簡單但很多芯片的中斷使能位是多級開關(guān)有一級漏配就全斷。第三檢查過濾器。第四確認總線PHY芯片的STB、RS引腳電平有一款常見的收發(fā)器芯片引腳不接電阻默認進入靜默模式只收不發(fā)。這類問題最容易蒙住人因為“能收到”說明總線物理層沒斷但“不能發(fā)”又指向驅(qū)動層實際上硬件配置就有問題。排查順序最好整理成一張自檢清單我在代碼里都加了相應的調(diào)試宏每步都往串口打一個狀態(tài)標記把定位時間從幾小時壓縮到幾分鐘。5. 性能、可靠性與后續(xù)擴展跑通只是第一步5.1 CPU占用率怎么量化別拍腦袋很多人說“我的CAN代碼占CPU很少”實際上是憑感覺。量化方法很簡單在接收中斷入口拉高一個GPIO出口拉低用示波器看這個GPIO的占空比就是接收中斷消耗的時間比例。同理發(fā)送完成中斷、錯誤中斷都可以各分配一個GPIO來測。我實測過一組數(shù)據(jù)500kbps總線下幀間隔大約幾十微秒一幀接收中斷從進入ISR到退出大概是2微秒到4微秒取決于讀取郵箱和拷貝次數(shù)占空比通常不到10%。但如果中斷里做了協(xié)議解析或者調(diào)用慢速外設這個比例能飆到50%以上。做實時系統(tǒng)時這個數(shù)字必須心中有數(shù)。5.2 重傳策略別做成“重傳風暴”發(fā)送失敗后要不要重傳我的結(jié)論是只重傳重要的、應用層需要保證送達的幀而且重傳要有退避機制。初版代碼里我做過一個錯誤的示范發(fā)送失敗后無限重傳總線負載一高幾個節(jié)點都在瘋狂重發(fā)錯誤幀越來越多形成惡性循環(huán)。升級版的策略是發(fā)送失敗時先進入一個“退避狀態(tài)”間隔指數(shù)增長重試最多重試3次同時把失敗次數(shù)上報到應用層由應用層決定是降級處理還是放棄。對于周期性報文簡單跳過一幀往往比重傳更合理因為下一幀很快就來了對于偶發(fā)性事件幀才需要可靠性保證。5.3 回環(huán)模式讓調(diào)試效率翻倍升級版的配置里保留了三種模式正常、回環(huán)、靜默。回環(huán)模式不經(jīng)過總線在內(nèi)部把發(fā)送數(shù)據(jù)直接送回接收路徑最適合單板自測。寫新代碼或者改過濾器配置之后先切到回環(huán)模式驗證一遍驅(qū)動邏輯再把模式改成正常接總線能省掉大量雙板聯(lián)調(diào)的痛苦。回環(huán)模式還有一個好處可以提前驗證中斷優(yōu)先級和緩沖區(qū)是否夠用。因為回環(huán)模式下收發(fā)頻率完全由你自己控制可以壓極限速率把緩沖區(qū)溢出問題在接真實總線之前暴露出來。5.4 給CAN FD留好接口經(jīng)典CAN在8字節(jié)數(shù)據(jù)場和1Mbps速率之下已經(jīng)越來越緊張CAN FD把數(shù)據(jù)場擴到最多64字節(jié)還能在數(shù)據(jù)段用更高的速率傳輸。升級版在設計時已經(jīng)把消息結(jié)構(gòu)的data[64]和flags的FD位預留好底層HAL層只需要增加一組寄存器操作驅(qū)動層的幀封裝邏輯要改動的地方不多。但有一點要特別提醒CAN FD不是所有控制器都支持換硬件之前要先確認。而且CAN FD的DLC編碼規(guī)則和位時序跟前文介紹的不一樣數(shù)據(jù)段的采樣點也要重新算。如果你現(xiàn)在用的還是經(jīng)典CAN控制器數(shù)據(jù)結(jié)構(gòu)先按上面的方式預留將來遷移時會輕松很多。最后再分享一點個人體會。CAN通信代碼真正做到“可靠”不是把寄存器的每一個位配對就行而是在“配置、緩沖、異常處理、分層結(jié)構(gòu)”這些看不見的地方下功夫。我先做回環(huán)自測再用GPIO把中斷的CPU占用量出來最后才敢上真實總線。這套代碼現(xiàn)在被我抽成固定模板換平臺只需要改HAL層和配置頭文件。如果讀者你現(xiàn)在正從零寫一套CAN驅(qū)動我建議不要只盯著“能收到數(shù)據(jù)”這個目標多花一點時間想想“收到之后怎么辦、出錯之后怎么辦”這個投入絕對值得。