1. 項目緣起為什么要在RT-Thread上折騰STM32F103的CAN最近在做一個工業數據采集節點的項目主控芯片選用了經典的STM32F103ZET6通信接口上除了常規的串口還必須支持CAN總線。原因很簡單現場環境里PLC、變頻器、傳感器這些設備很多都靠CAN總線互聯它抗干擾能力強傳輸距離遠多主仲裁的機制也適合分布式控制。一開始我打算用裸機開發自己寫一套CAN驅動和簡單的任務調度。但轉念一想設備后期功能肯定會增加比如遠程固件升級、文件系統記錄運行日志、更復雜的網絡協議棧等裸機那套狀態機輪詢的架構后期維護會是個噩夢。這時候RT-Thread就進入了我的視線。它是一個國產的、開源且組件豐富的實時操作系統內核小巧但生態完整。最關鍵的是它的BSP板級支持包對STM32系列的支持非常成熟特別是F1系列這種“老兵”驅動完善社區資料也多。在RT-Thread上使用CAN意味著我可以直接調用官方或社區維護好的、經過驗證的CAN設備驅動框架不用再從寄存器層面去配置波特率、過濾器這些底層細節能把精力集中在應用邏輯上。而且RT-Thread的ulog日志組件可以輕松對接文件系統把CAN通信的收發狀態、錯誤幀記錄下來這對于現場調試和故障排查簡直是神器。基于這些考慮我決定將項目遷移到RT-Thread平臺核心任務就是搞定STM32F103ZET6的CAN通信。這個組合——RT-Thread STM32F103 CAN——看似平凡卻是很多嵌入式工程師從單片機裸機開發轉向RTOS實戰的經典跳板。它涉及RTOS的基本使用、設備驅動框架的理解、以及工業現場總線通信的實踐是一個綜合性很強的練手項目。下面我就把從環境搭建、驅動配置、到應用編程、調試排坑的完整過程梳理一遍希望能給正在類似道路上摸索的朋友一份詳細的參考。2. 環境搭建與工程創建從零開始的正確姿勢在開始敲代碼之前一個穩定、高效的開發環境是基石。對于RT-Thread項目目前最主流的方式是使用RT-Thread Studio這個官方IDE或者使用Env工具配合MDK-Keil或IAR。我個人更傾向于RT-Thread Studio因為它集成了RT-Thread的配置、構建和包管理功能對新手更友好。2.1 硬件準備與原理圖核對我的核心板是STM32F103ZET6這是一款基于ARM Cortex-M3內核的MCU擁有512KB Flash和64KB RAM對于運行RT-Thread和常規應用綽綽有余。在動手寫軟件之前必須反復確認硬件連接。STM32F103ZET6有兩個CAN控制器CAN1和CAN2。它們通常與特定的GPIO引腳復用。CAN1: 默認的RX是PA11TX是PA12。這是最常用的引腳。CAN2: 它的RX和TX需要重映射通常使用PB5和PB6或者PB12和PB13具體取決于芯片的引腳復用功能。我的電路板上CAN收發器我用的是TJA1050連接到了MCU的PA11和PA12這意味著我將使用CAN1。這里第一個坑務必確認你的CAN收發器與MCU之間的接線正確并且終端電阻通常是120Ω是否已經連接在CAN_H和CAN_L之間。對于總線兩端必須各接一個120Ω電阻如果只有你一個節點在調試至少要在板子上把這個電阻焊上否則通信極不穩定波形會嚴重畸變。2.2 使用RT-Thread Studio創建項目打開RT-Thread Studio選擇“文件 - 新建 - RT-Thread項目”。基于開發板在“選擇廠商與開發板”頁面搜索“STM32F103ZET6”。RT-Thread Studio通常已經提供了許多標準開發板的BSP。如果你的板子恰好是某款熱門開發板如正點原子、野火可以直接選擇。如果找不到完全一致的可以選擇一個引腳兼容的F103ZE系列開發板作為基礎后續再修改引腳定義。設置項目名稱和路徑給項目起個名字比如rtthread_can_demo。選擇RT-Thread版本建議選擇最新的LTS長期支持版本穩定性有保障。Finish點擊完成后Studio會自動為你生成一個完整的、基于所選BSP的工程框架。這個框架包含了RT-Thread內核、該BSP對應的所有驅動包括CAN、以及根目錄下的main.c。創建完成后工程目錄結構非常清晰/board存放板級相關的代碼如board.c系統時鐘、內存初始化等和drv_can.cCAN驅動實現。/driversRT-Thread的通用設備驅動框架。/applications用戶應用代碼main.c就在這里。/rt-threadRT-Thread內核源碼。/packages用于存放通過包管理器添加的軟件包。RT-Thread Settings這是一個圖形化的配置工具是工程配置的核心。2.3 關鍵配置通過RT-Thread Settings使能CAN雙擊工程根目錄下的RT-Thread Settings文件會打開一個可視化配置界面。這里是我們“武裝”系統的武器庫。硬件配置在“硬件”欄目下找到“On-chip Peripheral”或“設備驅動程序”。展開“CAN”選項你會看到“Enable CAN1 BUS”和“Enable CAN2 BUS”。因為我們使用PA11/PA12所以勾選“Enable CAN1 BUS”。勾選后通常會自動配置好引腳。但你必須點開右側的配置詳情或去檢查代碼確認引腳是否正確。對于F103CAN1的RX/TX引腳配置通常在board/CubeMX_Config/下的MX_GPIO_Init函數中或者在board/drv_can.c的開頭以宏定義形式出現。確保它們是#define CAN1_RX_PIN GET_PIN(A, 11) #define CAN1_TX_PIN GET_PIN(A, 12)波特率配置這是第二個容易踩坑的地方。配置界面可能有一個默認波特率如500kbps。你需要根據你的總線網絡實際需求來設置。CAN波特率計算涉及波特率分頻器、時間段1、時間段2和重同步跳轉寬度。對于初學者可以先用一個經典配置比如1Mbps。在drv_can.c的初始化函數里你會找到類似hcan1.Init.Prescaler xx;的配置。一個常見的1Mbps配置系統時鐘72MHz可能是hcan.Init.Prescaler 9; // 分頻系數 hcan.Init.TimeSeg1 CAN_BS1_4TQ; // 時間段1為4個時間單元 hcan.Init.TimeSeg2 CAN_BS2_3TQ; // 時間段2為3個時間單元 hcan.Init.SJW CAN_SJW_1TQ; // 同步跳轉寬度為1個時間單元 // 計算(1/(72MHz / ((143) * 9))) ≈ 1 Mbps如果不確定可以先使用一個保守的值如125kbps或250kbps確保通信穩定后再提高。軟件包與組件配置ulog日志在“軟件包”或“組件”中心搜索并啟用ulog。這是RT-Thread的日志組件。我們需要將它配置為“異步日志”并“啟用文件系統后端”。這樣日志不僅能打印到串口還能自動寫入文件比如SD卡。這對于記錄CAN通信的長期運行狀態至關重要。文件系統如果要用ulog寫文件必須啟用文件系統。通常選擇FATFS這個軟件包并配置好對應的存儲設備如SPI Flash或SD卡的驅動。FinSH控制臺強烈建議啟用。它是一個命令行組件可以通過串口輸入命令來查看線程狀態、內存使用、甚至動態調用CAN的發送接收函數是調試的利器。配置完成后點擊保存。RT-Thread Studio會自動執行scons --targetmdk5如果你用Keil或類似的命令更新工程文件將你選擇的配置如CAN驅動、ulog的源代碼鏈接到項目中。3. CAN驅動框架解析與應用層編程實戰環境配好了接下來就是理解RT-Thread如何操作CAN設備并編寫我們的應用代碼。RT-Thread使用一套名為“設備驅動框架”的模型來統一管理硬件外設CAN也不例外。3.1 RT-Thread的設備驅動模型一切皆文件在RT-Thread中所有的硬件設備如UART、SPI、I2C、CAN在系統初始化后都會注冊為一個“設備對象”并掛載到設備框架中。應用程序通過標準的“打開-讀寫-控制-關閉”接口來操作設備類似于Linux下的文件操作。對于CAN設備這套接口被封裝得更加符合CAN通信的特點。首先在main.c或你的應用線程中你需要找到并打開CAN設備#include rtdevice.h // 必須包含這個頭文件 static rt_device_t can_dev RT_NULL; // 定義設備句柄 void can_thread_entry(void *parameter) { /* 1. 查找設備 */ can_dev rt_device_find(can1); // “can1”就是在BSP驅動中注冊的設備名稱 if (can_dev RT_NULL) { rt_kprintf(Error: Find CAN1 device failed!\n); return; } /* 2. 以中斷接收模式打開設備 */ if (rt_device_open(can_dev, RT_DEVICE_FLAG_INT_RX) ! RT_EOK) { rt_kprintf(Error: Open CAN1 device failed!\n); return; } rt_kprintf(CAN1 device opened successfully.\n); /* 3. 設置接收回調函數 */ rt_device_set_rx_indicate(can_dev, can_rx_callback); /* 4. 設置發送完成回調函數可選 */ rt_device_set_tx_complete(can_dev, can_tx_done_callback); // ... 后續的發送和接收邏輯 }關鍵點解析rt_device_find(can1)這里的字符串can1必須與BSP驅動中注冊的名字一致。通常可以在drv_can.c里找到rt_hw_can_init()函數里面有rt_device_register(can_dev, can1, ...)的調用。RT_DEVICE_FLAG_INT_RX這是打開模式。這里指定了“中斷接收模式”意味著當CAN控制器收到報文時會產生中斷驅動層會自動將數據存入緩沖區并調用我們設置的回調函數。這是最常用、最高效的方式。也可以使用輪詢模式但不推薦。can_rx_callback這是你定義的回調函數。當有數據到達時系統會在中斷上下文或中斷下半部調用它。注意回調函數里不能做耗時操作通常只用于釋放一個信號量或發送一個消息通知應用線程來處理數據。3.2 定義數據結構與回調函數CAN報文有標準格式。RT-Thread在rtdevice.h中定義了struct rt_can_msg結構體我們需要熟悉它struct rt_can_msg { rt_uint32_t id; /* 報文ID */ rt_uint32_t ide; /* 擴展幀標識RT_CAN_STDID 或 RT_CAN_EXTID */ rt_uint32_t rtr; /* 遠程幀標識RT_CAN_DTR 或 RT_CAN_RTR */ rt_uint32_t len; /* 數據長度 (0-8) */ rt_uint8_t data[8]; /* 數據 */ };接下來實現回調函數。一個典型的模式是使用rt_sem信號量進行線程同步static rt_sem_t rx_sem RT_NULL; // 接收信號量 static struct rt_can_msg rx_msg; // 用于存放接收到的報文 /* 接收回調函數 */ static rt_err_t can_rx_callback(rt_device_t dev, rt_size_t size) { /* 當驅動收到數據中斷服務程序會調用此函數 */ if (size 0) { rt_sem_release(rx_sem); // 釋放信號量通知處理線程 } return RT_EOK; } /* 發送完成回調用于非阻塞發送 */ static rt_err_t can_tx_done_callback(rt_device_t dev, void *buffer) { rt_kprintf(CAN message sent.\n); return RT_EOK; }在應用線程初始化時創建這個信號量rx_sem rt_sem_create(can_rx, 0, RT_IPC_FLAG_FIFO);。3.3 應用線程發送與接收的完整循環現在我們可以在應用線程里編寫主循環等待信號量并處理數據同時也可以主動發送數據。void can_thread_entry(void *parameter) { // ... 前面的設備查找、打開、回調設置代碼 struct rt_can_msg tx_msg; rt_size_t send_size; while (1) { /* 等待CAN接收信號量超時時間設為RT_WAITING_FOREVER或一個具體值 */ if (rt_sem_take(rx_sem, RT_WAITING_FOREVER) RT_EOK) { /* 信號量到來說明有數據可讀 */ rt_size_t recv_size rt_device_read(can_dev, 0, rx_msg, sizeof(rx_msg)); if (recv_size 0) { // 處理接收到的報文 rx_msg rt_kprintf([CAN RX] ID:0x%08X, Len:%d, Data:, rx_msg.id, rx_msg.len); for (int i 0; i rx_msg.len; i) { rt_kprintf(%02X , rx_msg.data[i]); } rt_kprintf(\n); // 示例簡單回環將收到的數據原樣發回ID加1以示區別 tx_msg.id rx_msg.id 1; tx_msg.ide rx_msg.ide; tx_msg.rtr RT_CAN_DTR; tx_msg.len rx_msg.len; rt_memcpy(tx_msg.data, rx_msg.data, rx_msg.len); send_size rt_device_write(can_dev, 0, tx_msg, sizeof(tx_msg)); if (send_size 0) { // rt_kprintf(Loopback message sent.\n); } } } /* 也可以主動定時發送一些數據 */ // static rt_tick_t last_send_tick 0; // if (rt_tick_get() - last_send_tick 1000) // 約1秒 // { // tx_msg.id 0x123; // tx_msg.ide RT_CAN_STDID; // tx_msg.len 4; // tx_msg.data[0] 0xAA; tx_msg.data[1] 0xBB; tx_msg.data[2] 0xCC; tx_msg.data[3] 0xDD; // rt_device_write(can_dev, 0, tx_msg, sizeof(tx_msg)); // last_send_tick rt_tick_get(); // } } }關鍵操作解析rt_device_read從CAN設備讀取數據。第二個參數0是讀取的起始位置對于CAN設備通常為0。它會從驅動的接收緩沖區中取出一幀報文。rt_device_write向CAN設備寫入發送數據。同樣第二個參數0對于CAN設備是固定的。這是一個阻塞調用直到報文被放入CAN控制器的發送郵箱或發送FIFO才會返回。如果郵箱已滿線程會阻塞等待。如果需要非阻塞發送可以使用rt_device_write配合RT_DEVICE_FLAG_NONBLOCK標志打開設備并依賴can_tx_done_callback來確認發送完成。數據打印這里使用了rt_kprintf它會輸出到控制臺如串口。在實際項目中更推薦使用ulog來記錄格式更規范還能存文件。4. 進階配置與深度排坑指南把基本的收發跑通只是第一步。在真實的工業或車載應用中CAN的配置要復雜和嚴謹得多。下面分享幾個進階主題和踩過的坑。4.1 CAN過濾器配置精準接收的關鍵STM32的CAN控制器有強大的硬件過濾器組可以只接收特定ID范圍的報文極大地減輕CPU負擔。在RT-Thread的驅動框架中通常通過rt_device_control函數來配置過濾器。假設我們只接收標準ID為0x100到0x1FF的報文可以這樣配置#include rtdevice.h struct rt_can_filter_item filter_item; struct rt_can_filter_config filter_config; /* 配置一個過濾器項 */ filter_item.id 0x100; // 要過濾的ID filter_item.mask 0x700; // 掩碼0x700 二進制 0111 0000 0000表示我們關心高3位即0x1XX低8位不關心。 filter_item.mode RT_CAN_FILTER_MODE_ID_MASK; // 標識符掩碼模式 filter_item.hdr -1; // -1表示由驅動自動分配一個可用的過濾器組 /* 將過濾器項放入配置結構 */ filter_config.count 1; // 只有一個過濾器項 filter_config.items filter_item; /* 使用控制命令配置過濾器 */ if (rt_device_control(can_dev, RT_CAN_CMD_SET_FILTER, filter_config) ! RT_EOK) { rt_kprintf(Error: Set CAN filter failed!\n); } else { rt_kprintf(CAN filter configured. Will only accept ID 0x100~0x1FF.\n); }掩碼計算解釋掩碼的每一位為1表示必須匹配ID對應的位為0表示不關心。0x700的二進制是0111 0000 0000這意味著ID的bit10~bit8即從高位開始的第11~9位對于標準ID是29-18位中的一部分這里簡化理解必須是001即0x1而低8位可以是任意值。所以它能過濾出0x100到0x1FF的所有ID。踩坑記錄1過濾器數量有限。STM32F103的CAN1和CAN2共享最多14個過濾器組具體數量查數據手冊。每個組可以配置為一個32位過濾器或兩個16位過濾器。如果你的過濾規則很多需要精心設計合理使用掩碼模式或列表模式避免過濾器組不夠用。在RT-Thread中如果hdr設為-1驅動會嘗試自動分配一個空閑組如果分配失敗rt_device_control會返回錯誤。4.2 錯誤處理與狀態監控讓系統更健壯CAN總線在惡劣環境下可能出現各種錯誤如總線離線、錯誤警告、被動錯誤等。一個好的驅動應該能報告這些狀態。RT-Thread的CAN驅動框架提供了獲取錯誤狀態的接口。rt_err_t result; struct rt_can_status status; result rt_device_control(can_dev, RT_CAN_CMD_GET_STATUS, status); if (result RT_EOK) { rt_kprintf(CAN Status:\n); rt_kprintf( Error Code: %d\n, status.rcverrcnt); // 接收錯誤計數器 rt_kprintf( Error Code: %d\n, status.snderrcnt); // 發送錯誤計數器 rt_kprintf( LEC: %d (Last Error Code)\n, status.lec); // LEC: 0無錯誤, 1填充錯誤, 2格式錯誤, 3應答錯誤, 4隱性位錯誤, 5顯性位錯誤, 6CRC錯誤, 7未用 if (status.status RT_CAN_STATUS_BUS_OFF) { rt_kprintf( ** BUS OFF State! **\n); // 總線離線需要軟件干預恢復。通常需要調用 rt_device_control(can_dev, RT_CAN_CMD_SET_MODE, RT_CAN_MODE_INIT) 進入初始化模式再重新配置。 } }建議在應用線程中定期比如每10秒查詢一次CAN狀態并通過ulog記錄到文件。當錯誤計數器持續增加或進入總線離線狀態時可以觸發報警或自動恢復流程。4.3 使用ulog記錄CAN通信日志前面提到了ulog這里詳細說一下如何集成。首先確保在RT-Thread Settings中使能了ulog和文件系統并配置了存儲設備。在代碼中使用起來非常簡單#include ulog.h // 在文件開頭定義日志標簽 #define LOG_TAG CAN void can_thread_entry(void *parameter) { // ... 初始化代碼 while(1) { if (rt_sem_take(rx_sem, RT_WAITING_FOREVER) RT_EOK) { rt_device_read(can_dev, 0, rx_msg, sizeof(rx_msg)); // 使用ulog的不同級別記錄日志 LOG_D([CAN RX] ID:0x%X, DLC:%d, rx_msg.id, rx_msg.len); // DEBUG級別調試信息 LOG_I(Received data: %02X %02X %02X %02X, rx_msg.data[0], rx_msg.data[1], rx_msg.data[2], rx_msg.data[3]); // INFO級別 // 如果發現錯誤幀 if (rx_msg.rtr RT_CAN_RTR) // 假設遠程幀我們不處理記錄警告 { LOG_W(Received RTR frame with ID 0x%X, ignored., rx_msg.id); } } // 定期記錄狀態 static rt_tick_t last_log_tick 0; if (rt_tick_get() - last_log_tick 10000) // 10秒 { struct rt_can_status status; if (rt_device_control(can_dev, RT_CAN_CMD_GET_STATUS, status) RT_EOK) { LOG_I(CAN Health: RecvErr%d, SendErr%d, status.rcverrcnt, status.snderrcnt); } last_log_tick rt_tick_get(); } } }ulog會自動將日志輸出到控制臺如果使能了后端同時也會按照配置寫入到文件系統中例如/sd/can_log_20240515.log。在RT-Thread的mshFinSH中你還可以動態調整日志級別ulog_lvl CAN I將CAN標簽的日志級別設置為INFO只顯示INFO及以上級別的日志非常方便。4.4 性能優化與注意事項接收緩沖區大小在drv_can.c中驅動會為每個CAN通道定義一個接收緩沖區通常是環形隊列。如果總線數據量很大需要適當調大這個緩沖區的大小防止數據丟失。找到struct rt_can_device實例化時的rxbuffer大小參數進行修改。中斷優先級CAN接收中斷的優先級需要合理設置。如果中斷優先級過低可能被其他高優先級中斷打斷導致數據接收不及時。如果優先級過高又可能影響系統實時性。通常設置為中等偏上的優先級。在CubeMX生成的代碼或drv_can.c的HAL_CAN_ConfigFilter和HAL_CAN_ActivateNotification相關部分可以找到中斷配置。發送超時處理rt_device_write是阻塞的。如果總線負載很高發送郵箱長時間滿線程會一直阻塞。可以考慮使用rt_device_write的非阻塞模式或者在一個獨立的發送線程中操作并設置一個合理的超時等待時間超時后記錄錯誤并丟棄舊報文避免整個線程卡死。多線程訪問CAN設備句柄can_dev是一個共享資源。如果多個線程都需要發送CAN報文必須做好互斥保護使用rt_mutex互斥鎖確保同一時間只有一個線程在操作發送。接收回調函數由于在中斷上下文被調用其內部釋放信號量等操作必須是線程安全的RT-Thread的內核對象操作通常是安全的。5. 調試技巧與常見問題排查即使按照步驟一步步來第一次調通CAN也難免遇到問題。下面是我總結的一套排查流程。現象根本收不到任何數據也發不出去。檢查硬件連接萬用表測量CAN_H和CAN_L對地電壓。靜默時CAN_H約2.5VCAN_L約2.5V。差分電壓為0V。如果電壓異常比如接近0或VCC檢查收發器供電、引腳是否虛焊、終端電阻是否接上。用示波器看波形是最直接的。在發送時應該能看到清晰的差分信號。標準CAN波形在顯性位邏輯0時CAN_H約3.5VCAN_L約1.5V差分電壓約2V。檢查軟件配置波特率這是頭號殺手。確保發送和接收節點的波特率設置完全一致包括分頻、時間段1、時間段2和SJW。最好用計算工具算好直接寫死參數。工作模式確認CAN控制器是否已正確進入正常工作模式Normal Mode而不是初始化模式或回環模式。在drv_can.c的初始化函數末尾應有調用HAL_CAN_Start或類似函數。過濾器如果你配置了過濾器但過濾條件設置錯誤可能會屏蔽掉所有報文。調試初期可以先將過濾器設置為“接收所有報文”模式。在RT-Thread中可以通過RT_CAN_CMD_SET_FILTER命令傳入一個空的filter_configcount0來禁用所有過濾器或者設置一個全通過濾器掩碼為0。中斷是否開啟檢查驅動中是否使能了CAN接收中斷HAL_CAN_ActivateNotification(hcan, CAN_IT_RX_FIFO0_MSG_PENDING)。利用RT-Thread工具診斷list_device在FinSH控制臺輸入list_device查看是否注冊了名為can1的設備以及其狀態。ps輸入ps查看你的CAN應用線程是否在正常運行狀態是否為ready或running。日志確保ulog控制臺后端已打開查看啟動日志和運行日志看是否有CAN初始化失敗的錯誤信息。現象能發送但收不到或者能收到自己的回環數據但收不到其他節點的。回環測試在驅動初始化時將CAN模式設置為回環模式RT_CAN_MODE_LOOPBACK。在這個模式下控制器自己發送的報文會被自己接收不經過外部總線。用這個模式可以快速驗證MCU的CAN控制器和驅動代碼是否正常。如果回環模式能自發自收說明軟件和芯片本身沒問題問題出在外部總線或另一個節點上。檢查另一個節點確認另一個節點是否正常工作、波特率是否匹配、終端電阻是否已接。檢查硬件差異有些CAN收發器如TJA1050有靜默模式引腳STB。確保它被正確拉高或拉低使收發器處于正常工作狀態。現象通信不穩定偶爾丟幀或出現錯誤幀。總線負載用CAN分析儀監控總線負載率。如果負載率長期超過70%-80%可能會因為仲裁和延遲導致丟幀。需要優化通信協議減少不必要的報文或提高波特率。布線干擾CAN總線對布線很敏感。應使用雙絞線并確保屏蔽層良好接地。避免與電源線、電機驅動線等強干擾源平行走線。地線問題所有CAN節點必須有良好的共地。地線環路或地電位差會引入巨大噪聲。查看錯誤計數器如4.2節所述定期讀取錯誤計數器。如果接收錯誤計數器增長很快可能是總線上的顯性/隱性位識別有問題檢查硬件連接和終端電阻。如果發送錯誤計數器增長可能是發送節點無法獲得總線仲裁ID優先級低或沒有收到應答總線上無其他正常節點。通過以上步驟你應該能解決RT-Thread下STM32F103ZET6 CAN通信的大部分問題。這個組合的穩定性已經經過大量項目驗證一旦調通在RT-Thread豐富的組件生態支持下你可以輕松地在此基礎上擴展出更復雜的應用比如通過CAN總線實現固件升級IAP、接入物聯網網關等。