簡介面向STM32開發(fā)者的開源CANopen協(xié)議棧Festival3.0源碼包適合需要在嵌入式項目中快速接入CANopen通信的工程師與學(xué)習(xí)者。協(xié)議棧覆蓋對象字典OD、節(jié)點ID管理、NMT網(wǎng)絡(luò)管理、SDO配置傳輸與PDO實時數(shù)據(jù)交換等核心機制可支撐工業(yè)自動化、汽車電子等多廠商設(shè)備互聯(lián)場景。壓縮包共65個文件以C源文件與頭文件為主體另含工程配置、調(diào)試信息及EDS/OD描述文件整體僅228KB便于快速下載和直接閱讀。目前已有2135人學(xué)習(xí)下載。資源提供完整示例工程與驅(qū)動代碼可對照主程序及inc/src/driver目錄梳理協(xié)議棧運行流程按需配置PDO映射、SDO服務(wù)和NMT事件處理從而完成從STM32 HAL庫驅(qū)動適配到應(yīng)用聯(lián)調(diào)的開發(fā)閉環(huán)也適合希望深入理解CANopen實現(xiàn)細(xì)節(jié)并做二次定制的開發(fā)者。1. 開源的CANopen源代碼配上STM32為什么說Festival 3.0是起步最快的選擇做工業(yè)設(shè)備聯(lián)網(wǎng)的工程師幾乎都會在某個項目里遇到CANopen。它是CAN總線上最普及的應(yīng)用層協(xié)議伺服、IO模塊、傳感器、PLC控制器都默認(rèn)支持它。手里有STM32做主控想讓它當(dāng)一個CANopen從站最直接的想法就是用開源協(xié)議棧而Festival 3.0就是那個被反復(fù)提起、社區(qū)里問得最多的開源版本。它的價值在于NMT、SDO、PDO、心跳這些協(xié)議細(xì)節(jié)不用自己寫了你只需要把CAN收發(fā)和定時器接好再填一張對象字典表設(shè)備就能上線被主站識別。這篇文章要解決的就是這個問題怎么把Festival 3.0快速移植到STM32上從驅(qū)動對接、對象字典配置到踩坑排查一條路走通。2. 協(xié)議棧選型與Festival 3.0工作方式先搞懂它里面裝著什么2.1 CANopen的下三層模型從CAN報文到對象字典很多工程師把CANopen當(dāng)成一個把“波特率、ID、報文”配置好的工具其實它和裸CAN的思維完全不同。裸CAN時代你自己定義ID和數(shù)據(jù)字節(jié)含義每個廠商一套規(guī)則CANopen則把這些全部規(guī)范化了。一個CANopen從站里核心是三樣?xùn)|西對象字典、通信對象、狀態(tài)機。對象字典是一張表格每個條目由索引和子索引定位。比如0x1000是設(shè)備類型0x1017是心跳生產(chǎn)時間0x2000到0x5FFF是廠商自定義區(qū)你的業(yè)務(wù)數(shù)據(jù)放這里。通信對象分四類NMT負(fù)責(zé)節(jié)點狀態(tài)切換啟動、停止、復(fù)位SDO負(fù)責(zé)配置和讀寫對象字典PDO負(fù)責(zé)周期性或事件觸發(fā)的實時數(shù)據(jù)傳輸心跳負(fù)責(zé)讓主站知道你的存活狀態(tài)。我一般會在移植前畫一張自己的數(shù)據(jù)流圖主站通過SDO給你下配置你把配置寫進(jìn)對象字典對應(yīng)的索引運行階段你周期性地把傳感器數(shù)據(jù)塞進(jìn)TPDO主站那邊就能直接收到實時值。這張圖畫清楚之后再看協(xié)議棧源碼你就知道該找哪些函數(shù)了。2.2 Festival 3.0的源碼結(jié)構(gòu)每個文件該改什么、該忽略什么關(guān)于Festival 3.0的源碼布局不同時期放出來的版本目錄會略有差異但核心套路是一致的。下面這個結(jié)構(gòu)是幾個常見fork的母版說明文件職責(zé)canopen-stack/ ├── include/ │ ├── canfestival.h /* 協(xié)議棧對外統(tǒng)一接口必須包含 */ │ ├── objdict.h /* 對象字典頭文件生成器產(chǎn)出 */ │ └── applicfg.h /* 平臺相關(guān)宏定義需要改 */ ├── src/ │ ├── canfestival.c /* 協(xié)議核心分發(fā)入口 */ │ ├── nmt.c /* 網(wǎng)絡(luò)管理狀態(tài)機 */ │ ├── sdo.c /* SDO服務(wù)器實現(xiàn) */ │ ├── pdo.c /* PDO收發(fā)處理 */ │ ├── hb.c /* 心跳生產(chǎn)與消費 */ │ ├── sync.c /* 同步報文處理 */ │ └── objacces.c /* 對象字典讀寫訪問 */ ├── drivers/ │ ├── can_io.c /* CAN收發(fā)必須重寫 */ │ └── timer.c /* 定時器節(jié)拍必須重寫 */ └── examples/ └── stm32/ /* 平臺示例工程 */移植時你只需要動drivers目錄下的兩個文件以及applicfg.h里的平臺宏。src目錄里的協(xié)議邏輯基本不用碰那是被驗證了無數(shù)遍的黑匣子動它反而容易翻車。objdict.h一般由對象字典編輯器生成手工寫容易錯后面章節(jié)會講怎么生成。2.3 移植前必須回答的四個問題第一個問題CAN控制器是什么型號。STM32系列大部分自帶bxCAN或FDCAN驅(qū)動寫法完全不同。bxCAN用CAN_TxHeaderTypeDef結(jié)構(gòu)體FDCAN用FDCAN_TxHeaderTypeDef接口參數(shù)差別很大選錯那一套驅(qū)動編譯能過、總線絕對不通。第二個問題時鐘頻率是多少。CAN波特率誤差超過1%bus-off會頻繁出現(xiàn)。比如某個開發(fā)板APB1是36MHz你套用網(wǎng)上72MHz的預(yù)分頻參數(shù)實際波特率就是正確的兩倍其他節(jié)點全部掉線。第三個問題內(nèi)存夠不夠。Festival 3.0的核心代碼加對象字典在IAR和GCC下編譯出來RAM占用大概4到8KBFlash占用20KB左右。STM32F103C8T6這種64KB Flash的片子夠用但如果你的業(yè)務(wù)代碼已經(jīng)把RAM占滿了就得把PDO緩沖區(qū)和對象字典的動態(tài)數(shù)組好好算一遍必要時裁剪掉不用的字典段。第四個問題主站側(cè)用什么工具。常見做法是準(zhǔn)備一個CAN分析儀和對應(yīng)上位機軟件有的總線分析儀自帶CANopen主站功能能自動掃描從站、讀寫對象字典、監(jiān)控PDO。沒有主站工具你只能盲調(diào)排查問題效率會低一個量級。選型結(jié)論如果你的目標(biāo)是快速做出一個能用的CANopen從站Festival 3.0值得投入。它代碼量不大、結(jié)構(gòu)清晰網(wǎng)上能搜到的移植經(jīng)驗貼也多踩坑成本遠(yuǎn)比從零實現(xiàn)低。接下來進(jìn)入實際移植。3. 把Festival 3.0移植到STM32最小工程搭建與CAN外設(shè)驅(qū)動3.1 新建工程與CAN外設(shè)初始化先把500kbps跑起來移植的第一步不是復(fù)制源碼而是先把STM32的CAN外設(shè)調(diào)通。我一般用STM32CubeMX生成基礎(chǔ)工程勾選CAN外設(shè)、配置一個1ms定時器然后手動改參數(shù)。下面這段代碼是典型的bxCAN初始化以500kbps、APB136MHz為例/* can_init.c - 基于HAL庫的CAN1外設(shè)初始化 */ #include can.h CAN_HandleTypeDef hcan1; void CAN1_Init(void) { hcan1.Instance CAN1; hcan1.Init.Prescaler 9; /* 36MHz / 9 4MHz */ hcan1.Init.SyncJumpWidth CAN_SJW_1TQ; hcan1.Init.TimeSeg1 CAN_BS1_5TQ; /* 5個時間量子 */ hcan1.Init.TimeSeg2 CAN_BS2_2TQ; /* 2個時間量子 */ hcan1.Init.Mode CAN_MODE_NORMAL; hcan1.Init.AutoBusOff ENABLE; hcan1.Init.AutoWakeUp DISABLE; hcan1.Init.AutoRetransmission DISABLE; hcan1.Init.ReceiveFifoLocked DISABLE; hcan1.Init.TransmitFifoPriority ENABLE; if (HAL_CAN_Init(hcan1) ! HAL_OK) { Error_Handler(); } }波特率計算公式是CAN時鐘頻率 / (Prescaler × (1 BS1 BS2))。上面這個配置總時間量子是1528預(yù)分頻后4MHz500kbps剛好落在誤差要求內(nèi)。注意AutoRetransmission一定要設(shè)成DISABLE否則協(xié)議棧超時重發(fā)邏輯會和控制器自動重發(fā)打架導(dǎo)致同一幀報文被主站收到兩次。3.2 驅(qū)動層對接發(fā)送、接收、定時器三個回調(diào)必須實現(xiàn)Festival 3.0核心不會直接調(diào)用HAL庫函數(shù)它留了一組驅(qū)動接口讓你填寫。最核心的是發(fā)送函數(shù)和分發(fā)入口。發(fā)送函數(shù)要做的事很簡單把協(xié)議棧內(nèi)部定義的Message結(jié)構(gòu)體翻譯成HAL庫的CAN_TxHeaderTypeDef/* driver.c - 協(xié)議棧驅(qū)動回調(diào)實現(xiàn) */ #include canfestival.h #include can.h static Message can_msg; /* 協(xié)議棧核心調(diào)用此函數(shù)把報文發(fā)到CAN總線 */ unsigned char canSend(CANPORT port, Message *m) { CAN_TxHeaderTypeDef tx; uint8_t data[8]; uint32_t mailbox; int i; tx.StdId m-cob_id; /* 協(xié)議棧已算好COB-ID */ tx.RTR (m-rtr 1) ? CAN_RTR_REMOTE : CAN_RTR_DATA; tx.DLC m-len; tx.IDE CAN_ID_STD; tx.ExtId 0; for (i 0; i 8; i) { data[i] m-data[i]; } if (HAL_CAN_AddTxMessage(hcan1, tx, data, mailbox) ! HAL_OK) { return 0; /* 發(fā)送失敗返回0給協(xié)議棧 */ } return 1; }協(xié)議棧里Message結(jié)構(gòu)體的data數(shù)組長度是8但PDO最長就是8字節(jié)所以直接拷過去沒問題。如果用的是FDCAN這里還要額外配置FDCAN_TxHeaderTypeDef的MessageSize等字段內(nèi)容多一截。3.3 接收中斷與定時器節(jié)拍把報文喂進(jìn)協(xié)議棧接收側(cè)最關(guān)鍵的一點是CAN接收中斷里只做“搬運”把報文從HAL的RxHeader轉(zhuǎn)成協(xié)議棧Message然后調(diào)用canDispatch。不要在中斷里做重活。/* stm32f1xx_it.c - CAN接收中斷回調(diào) */ void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { CAN_RxHeaderTypeDef rx; uint8_t data[8]; int i; if (hcan-Instance ! CAN1) return; HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, rx, data); can_msg.cob_id rx.StdId; can_msg.rtr (rx.RTR CAN_RTR_REMOTE) ? 1 : 0; can_msg.len rx.DLC; for (i 0; i 8; i) { can_msg.data[i] data[i]; } canDispatch(can_msg); /* 交給協(xié)議棧核心分發(fā) */ }定時器方面需要一個1ms周期的節(jié)拍來驅(qū)動協(xié)議棧的時鐘邏輯。用定時器3做1ms中斷在中斷里調(diào)用協(xié)議棧的TimerIntern函數(shù)/* timer.c - 1ms節(jié)拍喂給協(xié)議棧 */ void TIM3_IRQHandler(void) { if (TIM_GetITStatus(TIM3, TIM_IT_Update)) { TIM_ClearITPendingBit(TIM3, TIM_IT_Update); TimerIntern(); /* 協(xié)議棧內(nèi)部超時計時 */ } }TimerIntern會在內(nèi)部計數(shù)驅(qū)動心跳報文的生產(chǎn)、SDO超時、節(jié)點看門狗這些邏輯。如果你的主循環(huán)里有長時間阻塞的任務(wù)比如Flash擦寫請把擦寫放在CAN空閑時段實在避不開就提前把心跳周期的余量算夠否則主站會因為你心跳延遲而報節(jié)點丟失。3.4 最小驗證先讓從站上線能被主站掃描到驅(qū)動接完之后先不要寫任何應(yīng)用邏輯直接編譯燒錄用CAN分析儀主站掃描。此時從站應(yīng)該能發(fā)出心跳報文報文的COB-ID是0x700加節(jié)點號比如節(jié)點號1就是0x701。主站發(fā)NMT啟動節(jié)點命令0x000, 2字節(jié)0x01 0x01從站狀態(tài)應(yīng)該從Pre-operational切到Operational心跳繼續(xù)周期性地發(fā)。這一步如果通了說明驅(qū)動層和協(xié)議棧核心沒問題。如果掃描不到不要急著查對象字典先回到裸CAN層面用分析儀看總線上有沒有任何報文、波特率是不是真的500k、CAN收發(fā)器有沒有接對。很多移植失敗死在“裸CAN就沒通”這個最基礎(chǔ)的環(huán)節(jié)。確認(rèn)裸CAN收發(fā)正常、再用示波器看CAN_H和CAN_L的差分電平幅值是否在2V左右這一步排查完再碰協(xié)議棧。4. 對象字典與PDO映射讓設(shè)備真正能被上位機控制4.1 對象字典生成思路索引、子索引、數(shù)據(jù)類型怎么對應(yīng)協(xié)議棧跑通心跳之后就該把業(yè)務(wù)數(shù)據(jù)掛上去了。對象字典不是靠手寫維護(hù)的常見做法是用對象字典編輯器生成C文件。你只需要填索引、子索引、數(shù)據(jù)類型、讀寫權(quán)限它自動產(chǎn)出objdict.h和objdict.c。如果某個fork沒有配套編輯器你也可以直接改示例工程里的對象字典數(shù)組。先理解它的結(jié)構(gòu)一張indextable表每個條目對應(yīng)一個索引條目里是子索引列表每個子索引指向一個數(shù)據(jù)庫條目。數(shù)據(jù)庫條目描述了這個對象的訪問方式、存儲位置和數(shù)據(jù)類型。舉個最簡單的自定義對象在0x2000索引下面放一個16位只讀變量/* OD_1980.h - 自定義對象字典片段 */ UNS16 myCounter 0; /* 0x2000索引1個子索引 */ const ODCallback_t OD_0x2000_callbacks[1] { NULL }; const indextable OD_IndexTable[] { { 0x2000, 1, OD_0x2000_callbacks }, { 0, 0, NULL } };這里subindex從0開始子索引0通常是條目數(shù)量子索引1才是真正的數(shù)據(jù)。不要把業(yè)務(wù)變量直接暴露到通信層而應(yīng)該通過對象字典的讀寫回調(diào)做一層轉(zhuǎn)換。比如產(chǎn)品序列號存EEPROM里可以注冊一個回調(diào)讀的時候從EEPROM取寫的時候?qū)懟谽EPROM這樣上位機訪問到的始終是持久化數(shù)據(jù)而不是易變的RAM變量。4.2 通過SDO讀寫對象從0x2000開始自定義應(yīng)用對象SDO是配置用的主站通過它讀寫字對象。一旦對象字典里加了0x2000條目主站就能用SDO訪問。你不需要寫任何SDO處理代碼協(xié)議棧的sdo.c自動響應(yīng)主站的SDO請求。你要做的是確保對象字典里注冊的變量地址和類型正確。SDO請求的報文格式分兩種快速SDO讀寫4字節(jié)內(nèi)數(shù)據(jù)和普通SDO分段傳輸。對自定義對象來說I/O數(shù)據(jù)基本都是4字節(jié)內(nèi)的走快速SDO就夠了。注意SDO服務(wù)器默認(rèn)是阻塞式的協(xié)議棧在處理SDO請求期間會停住其他通信處理。如果你的主站喜歡一次連續(xù)讀幾十個對象從站側(cè)會明顯感覺響應(yīng)變慢這是正?，F(xiàn)象不是死機。真遇到那種“讀一個對象就卡2秒”的情況多半是對象字典回調(diào)函數(shù)里做了Flash讀寫又沒有做超時處理。4.3 PDO映射的兩種姿勢靜態(tài)映射和運行時修改PDO負(fù)責(zé)實時數(shù)據(jù)。一個從站通常有多個TPDO比如TPDO1發(fā)狀態(tài)字TPDO2發(fā)位置值。PDO的內(nèi)容由映射參數(shù)決定。0x1B00索引是TPDO1的通信參數(shù)0x1B01是映射參數(shù)。映射參數(shù)是一個列表每個條目寫成“對象索引.子索引.位寬”的編碼格式。映射一個16位的0x2000子索引1條目值就是0x20000110。最常見的坑是映射方向搞反。TPDO是“從站往主站推”映射的源必須是對象字典里的變量RPDO是“主站往從站灌”映射的目標(biāo)也必須先定義在對象字典里。你不能把一個不存在的對象掛進(jìn)映射表。映射參數(shù)可以在本地寫死也可以通過SDO在運行時修改。靜態(tài)映射適合生產(chǎn)固件簡單可靠動態(tài)映射適合調(diào)試期代價是運行時需要執(zhí)行SDO寫映射、映射使能這一整套流程。我建議量產(chǎn)固件用靜態(tài)映射調(diào)試期臨時開動態(tài)。4.4 心跳與同步周期1ms定時器到底該喂誰這一節(jié)把時間片邏輯理清。協(xié)議棧內(nèi)部只有一條1ms節(jié)拍線它同時驅(qū)動TimerIntern的超時計數(shù)和心跳生產(chǎn)。三個常見時間參數(shù)心跳生產(chǎn)時間0x1017單位毫秒常見值是50ms到1000msPDO的傳輸類型0x1800到0x1B00的通信參數(shù)里同步周期用0x1005和0x1006配置0x1006是同步報文周期單位微秒。我的建議是調(diào)試期把心跳設(shè)成100msPDO傳輸類型設(shè)為“每第N個SYNC幀發(fā)送一次”N設(shè)為1。這樣主站能看到從站的實時數(shù)據(jù)和在線狀態(tài)邏輯最簡單。下面是心跳和通信參數(shù)的配置示例/* 通信參數(shù)區(qū)典型配置 */ #define OD_HB_PROD_TIME 0x1017 /* 心跳生產(chǎn)時間 */ #define OD_SYNC_PERIOD 0x1006 /* 同步周期單位us */ #define OD_TPDO1_TRANS_TYPE 0x1800 /* TPDO1傳輸類型 */ /* NMT狀態(tài)正常后心跳由協(xié)議棧自動按0x1017發(fā)送 */如果你用了同步傳輸主站必須周期性發(fā)SYNC幀從站才會在對應(yīng)的同步計數(shù)到達(dá)時觸發(fā)TPDO。主站沒發(fā)SYNCTPDO就永遠(yuǎn)不觸發(fā)這是新手最容易誤解的地方。遇到“PDO不動”的故障先看總線上有沒有SYNC幀再查傳輸類型配置。5. 移植Festival 3.0的常見問題排查從編譯報錯到總線靜默5.1 現(xiàn)象編譯通過但總線上抓不到任何報文原因CAN過濾器沒有正確配置或者根本沒有使能CAN接收中斷。很多初始化代碼只調(diào)了HAL_CAN_Init忘了設(shè)置過濾器導(dǎo)致所有報文都進(jìn)不了FIFO0協(xié)議棧自然收不到NMT命令。解決在初始化里加一段過濾器配置把過濾器掩碼設(shè)為全0接收所有標(biāo)準(zhǔn)幀。以bxCAN為例/* 接收所有標(biāo)準(zhǔn)幀的過濾器配置 */ CAN_FilterTypeDef filter; filter.FilterIdHigh 0x0000; filter.FilterIdLow 0x0000; filter.FilterMaskIdHigh 0x0000; filter.FilterMaskIdLow 0x0000; filter.FilterFIFOAssignment CAN_RX_FIFO0; filter.FilterBank 0; filter.FilterMode CAN_FILTERMODE_IDMASK; filter.FilterScale CAN_FILTERSCALE_32BIT; filter.FilterActivation ENABLE; HAL_CAN_ConfigFilter(hcan1, filter); HAL_CAN_Start(hcan1); HAL_CAN_ActivateNotification(hcan1, CAN_IT_RX_FIFO0_MSG_PENDING, ENABLE);檢查時用CAN分析儀掛在總線旁邊先確認(rèn)從站有沒有發(fā)心跳。如果完全靜默基本就是過濾器或中斷使能的問題。注意使能接收中斷后還要在主循環(huán)或初始化里保證HAL_CAN_Start被調(diào)用否則外設(shè)沒有啟動。5.2 現(xiàn)象心跳發(fā)出去了但主站幾秒后報節(jié)點超時原因波特率偏差超過協(xié)議要求的1%或者心跳周期的0x1017被設(shè)成了0。0x1017是0時從站不發(fā)送心跳主站側(cè)當(dāng)然會報超時。另一種情況是APB1時鐘源配置和初始化參數(shù)對不上實際波特率漂了百分之幾距離短的調(diào)試階段僥幸能通線一長就掉線。解決先用CAN分析儀自帶的波特率測試功能看實際波特率是499.8k還是512k。如果是512k說明Prescaler和BS1/BS2的組合算錯了。重新按公式計算CAN時鐘經(jīng)過預(yù)分頻后必須落在目標(biāo)波特率的1%誤差內(nèi)。用庫函數(shù)打印出初始化后的實際參數(shù)不要靠肉眼估計。另外把0x1017寫成100立刻從站側(cè)能看到心跳周期變化這招能快速驗證心跳通路。5.3 現(xiàn)象SDO讀正常、寫正常但PDO數(shù)據(jù)不刷新原因映射參數(shù)配錯了常見是子索引、位寬計算錯或者把TPDO映射在了RPDO的條目區(qū)。另一個高頻原因是傳輸類型設(shè)成同步但主站沒發(fā)SYNC。如果PDO傳輸類型為255事件觸發(fā)那從站數(shù)據(jù)變化時才發(fā)數(shù)據(jù)一直不變PDO就只發(fā)一次看起來就像“沒有刷新”。解決用分析儀看主站發(fā)不發(fā)SYNC幀。如果主站發(fā)那么檢查0x1B01的映射計數(shù)確認(rèn)映射條目數(shù)和實際映射的對象數(shù)一致。再檢查映射的位寬和變量類型是否匹配比如把32位浮點數(shù)映射成16位條目數(shù)據(jù)會截斷看起來就是亂碼。最粗暴的驗證方法在從站代碼里手動修改TPDO源變量的值看總線上有沒有新幀。沒有新幀問題在協(xié)議棧配置有新幀但值不對問題在映射表本身。5.4 現(xiàn)象運行一段時間后HardFault或者整個系統(tǒng)卡死原因在CAN接收中斷里直接調(diào)協(xié)議棧分發(fā)而協(xié)議棧內(nèi)部又觸發(fā)了SDO回調(diào)回調(diào)里做了耗時操作擠占了中斷時間。更常見的是臨界區(qū)沒有保護(hù)協(xié)議棧在訪問對象字典的同時主循環(huán)也在改同一個變量導(dǎo)致數(shù)據(jù)競爭。解決把canDispatch放到主循環(huán)的輪詢里中斷只做接收和置標(biāo)志位。如果一定要在中斷里分發(fā)就在調(diào)用協(xié)議棧接口的前后加上臨界區(qū)保護(hù)。還有一點容易被忽略的是堆棧大小協(xié)議棧遞歸調(diào)用的深度不算深但SDO回調(diào)里如果有printf或浮點運算每個嵌套層都會吃掉不少?？臻g建議調(diào)試期把主棧調(diào)到2KB以上。6. 用CAN分析儀抓完整報文從上線到閉環(huán)控制的驗證方法驗證一個CANopen從站是否合格不能只看上位機顯示“在線”。用CAN分析儀把原始報文抓出來按時間順序核對狀態(tài)機的每一拍。以節(jié)點號1為例上電后你看到的第一個報文應(yīng)該是心跳0x701數(shù)據(jù)字節(jié)是節(jié)點狀態(tài)值。如果心跳沒發(fā)說明協(xié)議棧還沒進(jìn)入正常狀態(tài)。接著手動給從站發(fā)NMT啟動命令CAN ID 0x000數(shù)據(jù)0x01 0x01。從站收到后狀態(tài)從Pre-operational切換到Operational此時SDO和PDO才允許正常工作。你要驗證的時序是NMT命令后從站在下一個心跳周期內(nèi)應(yīng)答狀態(tài)變化同時SYNC幀到來時觸發(fā)PDO。用分析儀的觸發(fā)功能抓一段10ms到100ms的窗口把NMT、心跳、SYNC、PDO四類幀的間隔量出來間隔符合配置值就算通過。我再提供一個排查技巧用分析儀統(tǒng)計總線負(fù)載率和錯誤幀數(shù)量。錯誤幀為0是基本要求負(fù)載率在20%以下時如果還頻繁重傳說明發(fā)送緩沖區(qū)的優(yōu)先級配置有問題。真遇到難纏的時序問題把分析儀的CAN報文導(dǎo)成CSV用腳本按時間戳排序檢查比盯著看快得多。常見的做法是寫一個十行左右的分析腳本把每個COB-ID出現(xiàn)的次數(shù)和間隔統(tǒng)計出來。最后聊一個讓我印象深刻的經(jīng)驗?zāi)炒雾椖坷飶恼拘奶蚉DO都正常但主站的軸控指令一執(zhí)行就超時。排查到最后發(fā)現(xiàn)是接收中斷里順手做了一位數(shù)碼管刷新刷新函數(shù)里關(guān)了中斷導(dǎo)致CAN接收在關(guān)鍵時刻被阻塞了好幾十微秒。從那以后我記住一條習(xí)慣中斷里的代碼越少越好CAN接收中斷只置標(biāo)志位協(xié)議棧分發(fā)全部挪到主循環(huán)。這個習(xí)慣后來幫我避掉了好幾次類似的坑也希望能幫到你。本文還有配套的精品資源點擊獲取