簡介CANfestival是一款專注于CANopen協(xié)議棧的開源實(shí)現(xiàn)采用C語言編寫能夠在ARM、PIC、AVR等嵌入式微控制器上穩(wěn)定運(yùn)行主要解決CAN總線設(shè)備間網(wǎng)絡(luò)管理、參數(shù)配置與實(shí)時(shí)數(shù)據(jù)交換的開發(fā)問題對(duì)汽車電子、工業(yè)自動(dòng)化及教學(xué)科研場景中的開發(fā)者而言是理解并落地CANopen通信的實(shí)用工具。資源共50個(gè)文件由30個(gè)h頭文件與20個(gè)c源文件組成壓縮包約105KB結(jié)構(gòu)緊湊、模塊邊界清晰適合直接翻閱源碼來跟蹤協(xié)議流程。項(xiàng)目實(shí)現(xiàn)了CAN驅(qū)動(dòng)適配層、對(duì)象字典管理、NMT網(wǎng)絡(luò)管理、PDO實(shí)時(shí)數(shù)據(jù)傳輸與動(dòng)態(tài)映射、SDO非實(shí)時(shí)配置、LSS節(jié)點(diǎn)尋址、錯(cuò)誤處理與故障恢復(fù)等核心機(jī)制同時(shí)提供STM32示例程序可直觀演示從節(jié)點(diǎn)初始化到周期數(shù)據(jù)交換的完整工作過程。目前已有489人學(xué)習(xí)下載對(duì)于需要深入研究CANopen源碼細(xì)節(jié)或快速完成協(xié)議棧移植的工程師這份資源能有效縮短開發(fā)前的理解成本。 CANfestival這個(gè)開源CANopen協(xié)議棧第一次接觸它的人是帶著一點(diǎn)懷疑的——那文件結(jié)構(gòu)不像商業(yè)協(xié)議棧那么規(guī)整文檔也不算詳盡但真正在STM32單片機(jī)上把它跑起來之后我承認(rèn)它是目前開源CANopen方案里最順手的一套。這幾年我用它做過AGV驅(qū)動(dòng)控制器、醫(yī)療床控制系統(tǒng)和幾臺(tái)非標(biāo)設(shè)備的現(xiàn)場總線模塊積累了不少移植和排錯(cuò)的經(jīng)驗(yàn)。這篇文章不打算重復(fù)官方文檔里的AP列表而是把我從零開始移植、配置對(duì)象字典、調(diào)試主從站通信的完整過程捋一遍。適合正要給嵌入式設(shè)備加CANopen接口的工程師也適合在CANopenNode和CANfestival之間猶豫該選哪個(gè)的朋友。1. 為什么現(xiàn)場設(shè)備都在聊CANopen選型背景與CANfestival的定位1.1 CANopen解決了CAN總線應(yīng)用層的什么痛點(diǎn)CAN總線本身只解決物理層和數(shù)據(jù)鏈路層的收發(fā)問題也就是說它能保證一幀數(shù)據(jù)從一個(gè)節(jié)點(diǎn)送到另一個(gè)節(jié)點(diǎn)但這一幀數(shù)據(jù)到底代表什么含義、誰來發(fā)、什么時(shí)候發(fā)、發(fā)完怎么確認(rèn)CAN規(guī)范里完全沒有定義。早年很多設(shè)備拿CAN做自定義協(xié)議主站問一個(gè)地址從站回一串字節(jié)表面看能用但遇到多供應(yīng)商設(shè)備互聯(lián)、診斷需求、參數(shù)批量配置就非常痛苦。CANopen就是在CAN基礎(chǔ)之上補(bǔ)上了應(yīng)用層的那一套標(biāo)準(zhǔn)它定義了對(duì)象字典來統(tǒng)一描述設(shè)備參數(shù)定義了PDO來跑實(shí)時(shí)過程數(shù)據(jù)定義了SDO來做參數(shù)配置還定義了NMT網(wǎng)絡(luò)管理來統(tǒng)一控制節(jié)點(diǎn)狀態(tài)。這套標(biāo)準(zhǔn)由CiACAN in Automation維護(hù)在工業(yè)伺服、工程機(jī)械、醫(yī)療設(shè)備、AGV這些場景中幾乎成了默認(rèn)選項(xiàng)。比如一臺(tái)伺服驅(qū)動(dòng)器廠商A和廠商B都可以遵循CiA 402驅(qū)動(dòng)協(xié)議用戶只需要用同樣的對(duì)象字典索引去訪問控制字、狀態(tài)字、目標(biāo)速度主站軟件不需要為每個(gè)品牌單獨(dú)適配。1.2 CANfestival在開源協(xié)議棧里的真實(shí)地位開源CANopen協(xié)議棧其實(shí)不止CANfestival一個(gè)還有CANopenNode等方案。CANopenNode更偏向現(xiàn)代MCU支持異步API、多線程代碼量也更大CANfestival則是純C語言、結(jié)構(gòu)緊湊對(duì)RAM和Flash都非常友好非常適合裸機(jī)或者輕量RTOS環(huán)境。我做選型時(shí)對(duì)比過幾個(gè)方案實(shí)際用下來感受如下方案語言資源占用上手難度適合場景CANfestivalC低占幾KB Flash中等結(jié)構(gòu)老派但穩(wěn)定STM32裸機(jī)、小資源MCUCANopenNodeC/C較高中高抽象層多資源豐富的MCU、Linux環(huán)境商業(yè)協(xié)議棧emCAN等C視配置而定低支持完善產(chǎn)品量產(chǎn)、有授權(quán)預(yù)算自研CANopen子集C最低高要自己踩坑僅需極少量功能CANfestival還有一個(gè)明顯優(yōu)勢是它從從站節(jié)點(diǎn)到主站邏輯都有完整實(shí)現(xiàn)也就是說你不光能用它做從站設(shè)備還能做一個(gè)簡單的CANopen管理器這在做測試工裝或者小批量控制臺(tái)的時(shí)候特別方便。它的協(xié)議棧主體是基于BSD許可的用于商業(yè)產(chǎn)品沒有授權(quán)成本這也是很多中小設(shè)備廠商選它的原因。1.3 我為什么最終選它一次真實(shí)選型復(fù)盤當(dāng)時(shí)給AGV驅(qū)動(dòng)控制器加CANopen接口我第一個(gè)想法是買商業(yè)協(xié)議棧但報(bào)價(jià)讓老板猶豫。自研又不太現(xiàn)實(shí)CANopen雖然不復(fù)雜但要處理的對(duì)象字典、PDO映射、SDO分段傳輸、心跳和緊急報(bào)文一套完整實(shí)現(xiàn)下來不是一兩個(gè)星期能干完的。于是轉(zhuǎn)向開源方案。CANfestival最吸引我的一點(diǎn)是它能讓我看到每一行協(xié)議代碼是怎么實(shí)現(xiàn)的。出問題的時(shí)候直接翻開源碼看狀態(tài)機(jī)不用對(duì)著黑盒協(xié)議棧瞎猜。后來在一次排查中我通過單步追蹤發(fā)現(xiàn)看門狗清零報(bào)文的處理順序和主站預(yù)期不一致順著canDispatch的入口找到了對(duì)應(yīng)處理分支很快就定位了一個(gè)看起來像是硬件問題、實(shí)際是NMT狀態(tài)機(jī)時(shí)序?qū)е碌墓收稀＿@種可追溯性在工業(yè)現(xiàn)場調(diào)試中價(jià)值極大。2. 協(xié)議棧核心機(jī)制拆解對(duì)象字典、SDO/PDO與NMT狀態(tài)機(jī)2.1 對(duì)象字典整個(gè)協(xié)議棧的心臟理解CANfestival第一個(gè)要抓住的概念就是對(duì)象字典Object Dictionary簡稱OD?？梢园阉斫獬梢粡埓蟊砀癖砀衩恳恍惺且粋€(gè)“索引”索引下面還可以有子索引每個(gè)子索引對(duì)應(yīng)一個(gè)變量或數(shù)據(jù)結(jié)構(gòu)。CANopen的所有通信行為最終都是對(duì)這張表的讀或?qū)憽Ｋ饕秶?6位的從0x0000到0xFFFF。其中0x1000到0x1FFF屬于通信參數(shù)區(qū)域比如0x1000是設(shè)備類型0x1005是同步COB-ID0x1017是心跳生產(chǎn)周期0x2000到0x5FFF是廠商自定義區(qū)域你想暴露什么私有參數(shù)就放在這里0x6000到0x9FFF是標(biāo)準(zhǔn)設(shè)備Profile區(qū)域比如CiA 402就規(guī)定了0x6040控制字、0x6041狀態(tài)字等。CANfestival里每個(gè)OD條目都帶一個(gè)類型定義通常是UNS8、UNS16、UNS32或者更復(fù)雜的數(shù)組還有一個(gè)訪問屬性只讀、只寫、可讀寫寫操作時(shí)還可以掛鉤一個(gè)回調(diào)函數(shù)來做邊界檢查或關(guān)聯(lián)動(dòng)作。在CANfestival中OD最終會(huì)被生成一個(gè)C數(shù)組結(jié)構(gòu)每個(gè)條目通過宏定義與變量綁定。這就是為什么你經(jīng)?？吹絆D文件以od.h和od.c的形式存在——這兩個(gè)文件就是這張大表格的C語言實(shí)現(xiàn)協(xié)議棧的所有功能模塊PDO、SDO、NMT最終都是通過索引來訪問OD條目。你甚至可以手動(dòng)修改od.c來添加條目不過更推薦用工具生成后面會(huì)講。2.2 SDO和PDO一條慢車道一條快車道CANopen的通信報(bào)文按職責(zé)分了兩類。SDOService Data Object是配置用的類似“郵局掛號(hào)信”一問一答可靠但慢適合傳輸參數(shù)、配置信息。SDO報(bào)文的數(shù)據(jù)部分固定是8字節(jié)里面塞著索引2字節(jié)、子索引、命令碼和數(shù)據(jù)通過分段機(jī)制可以傳遠(yuǎn)大于8字節(jié)的數(shù)據(jù)塊。PDOProcess Data Object是實(shí)時(shí)過程數(shù)據(jù)用的類似“廣播大喇叭”生產(chǎn)者按需或者按周期直接甩一幀數(shù)據(jù)出來不需要應(yīng)答延遲低但可靠性靠總線本身保證。CANfestival里默認(rèn)配置了4個(gè)RPDO和4個(gè)TPDO每個(gè)PDO對(duì)應(yīng)OD中的一組映射參數(shù)0x1600到0x1603是RPDO映射0x1A00到0x1A03是TPDO映射對(duì)應(yīng)的通信參數(shù)在0x1400和0x1800區(qū)域。映射參數(shù)就是描述“這幀PDO數(shù)據(jù)里放哪幾個(gè)OD條目、各占幾位”的清單。默認(rèn)情況下一個(gè)PDO里最多能穿8個(gè)字節(jié)的數(shù)據(jù)通過映射可以把多個(gè)8位、16位、32位變量打包到一幀里。這里有一個(gè)值得注意的細(xì)節(jié)SDO和PDO使用不同的COB-ID范圍SDO命令使用0x580和0x600加上節(jié)點(diǎn)IDPDO默認(rèn)使用0x180到0x1F7區(qū)域。COB-ID沖突經(jīng)常導(dǎo)致“莫名其妙的通信故障”實(shí)際上就是兩個(gè)不同對(duì)象共用了同一條報(bào)文通道。2.3 NMT狀態(tài)機(jī)和心跳設(shè)備的“開機(jī)關(guān)機(jī)”每個(gè)CANopen節(jié)點(diǎn)都有一個(gè)網(wǎng)絡(luò)管理狀態(tài)機(jī)NMT四個(gè)狀態(tài)初始化Initialization、預(yù)操作Pre-operational、運(yùn)行Operational、停止Stopped。上電后節(jié)點(diǎn)先進(jìn)入初始化自動(dòng)完成內(nèi)部配置后進(jìn)入預(yù)操作此時(shí)只能走SDO配置參數(shù)不能發(fā)PDO收到主站的NMT啟動(dòng)命令后進(jìn)入運(yùn)行狀態(tài)才能正常收發(fā)PDO停止?fàn)顟B(tài)下節(jié)點(diǎn)除了NMT和心跳不響應(yīng)其他通信。這就像一個(gè)設(shè)備先待機(jī)、再開機(jī)運(yùn)行的邏輯防止參數(shù)沒配置完就把過程數(shù)據(jù)發(fā)出去導(dǎo)致誤動(dòng)作。心跳機(jī)制則是節(jié)點(diǎn)周期性向外發(fā)送一個(gè)字節(jié)的狀態(tài)報(bào)文COB-ID是0x700加節(jié)點(diǎn)ID。主站可以通過0x1016心跳消費(fèi)周期配置來監(jiān)控從站是否存活從站通過0x1017來配置心跳生產(chǎn)周期。如果從站死機(jī)或總線短路主站就能通過心跳超時(shí)及時(shí)發(fā)現(xiàn)。CANfestival里這兩個(gè)參數(shù)都是OD條目直接SDO寫入即可生效。2.4 CANfestival代碼里最核心的幾個(gè)文件名拿到源碼后你會(huì)在src目錄下看到一堆文件不要被嚇到。實(shí)際打交道的核心就那么幾個(gè)canfestival.c是協(xié)議棧主入口定義了節(jié)點(diǎn)初始化和報(bào)文分發(fā)邏輯sdo.c和pdo.c分別實(shí)現(xiàn)SDO和PDO處理nmt.c和lifegrd.c是NMT狀態(tài)機(jī)和心跳時(shí)間管理的實(shí)現(xiàn)sync.c處理同步報(bào)文objdict.c就是你的對(duì)象字典實(shí)例每個(gè)工程同名但內(nèi)容不同。另外還有timer.c有些版本叫timerscfg用來對(duì)接你的定時(shí)器硬件。CANfestival的報(bào)文處理機(jī)制是硬件接收中斷收到幀后會(huì)帶上總線號(hào)和時(shí)間戳調(diào)用協(xié)議棧的canDispatch由它根據(jù)COB-ID把幀路由到對(duì)應(yīng)的功能模塊。如果通信對(duì)象配置成了帶發(fā)送確認(rèn)的SDO那么發(fā)送函數(shù)會(huì)自動(dòng)處理sdoTimeout的回調(diào)。理解了這個(gè)分發(fā)流程后續(xù)排查“為什么幀收到了但節(jié)點(diǎn)沒反應(yīng)”就多了一條定位線索。3. 移植到STM32的全流程記錄從文件裁剪到跑通心跳3.1 移植前需要準(zhǔn)備的最小工程我用的環(huán)境是STM32F103系列加HAL庫開發(fā)環(huán)境是Keil其實(shí)無論用標(biāo)準(zhǔn)庫還是HAL甚至換成GD32、AT32流程都差別不大。需要準(zhǔn)備的硬件是開發(fā)板加一塊CAN收發(fā)器芯片常用的TJA1050或SN65HVD230以及一個(gè)USB轉(zhuǎn)CAN分析儀如果不準(zhǔn)備分析儀后面聯(lián)調(diào)會(huì)非常痛苦。在Keil工程里新增分組CanFestival把src下的canfestival.c、lss.c、dcf.c、nmt.c、pdo.c、sdo.c、sync.c、emcy.c、lifegrd.c、states.c加進(jìn)去再把drivers目錄下適配你MCU平臺(tái)的驅(qū)動(dòng)文件加進(jìn)來。如果你用的是STM32驅(qū)動(dòng)器接口代碼在drivers/unix、drivers/STM32等目錄下面。有些版本自帶的驅(qū)動(dòng)是用標(biāo)準(zhǔn)庫寫的直接搬到HAL工程會(huì)報(bào)錯(cuò)我建議只借用它的框架自己重新寫底層收發(fā)會(huì)更可控。另外要在編譯選項(xiàng)中添加宏定義USE_CANopen_NODE表示編譯為從站節(jié)點(diǎn)如果你要跑主站邏輯就定義CANOPEN_MASTER還有SDO_MAX_LENGTH_TRANSFER這個(gè)決定SDO單次傳輸允許的數(shù)據(jù)長度我用默認(rèn)的256字節(jié)覆蓋絕大多數(shù)配置場景。3.2 CAN底層收發(fā)接口對(duì)接canSend和接收中斷CANfestival對(duì)底層驅(qū)動(dòng)的抽象非常薄主要就是兩個(gè)函數(shù)canSend用來發(fā)一幀接收路徑靠你在中斷里調(diào)用canDispatch。Message這個(gè)結(jié)構(gòu)體對(duì)應(yīng)一幀CAN報(bào)文包含COB-ID、數(shù)據(jù)長度和數(shù)據(jù)字節(jié)數(shù)組你的canSend實(shí)現(xiàn)需要把這個(gè)結(jié)構(gòu)體映射到HAL庫的CAN_TxHeaderTypeDef然后調(diào)用HAL_CAN_AddTxMessage。接收側(cè)在HAL_CAN_RxFifo0MsgPendingCallback里讀取報(bào)文填入Message結(jié)構(gòu)體調(diào)用canDispatch。注意CANfestival的canDispatch在處理時(shí)會(huì)回查對(duì)象的當(dāng)前狀態(tài)如果你在中斷里直接調(diào)用且協(xié)議棧配置了較長的SDO分段處理可能導(dǎo)致中斷服務(wù)函數(shù)時(shí)間過長。我一般把canDispatch放在中斷里直接處理保持簡單但會(huì)把所有協(xié)議棧堆棧相關(guān)的數(shù)組定義局部加大。如果RTOS環(huán)境更推薦用隊(duì)列把CAN幀放到任務(wù)上下文處理。canSend的一個(gè)常見坑是發(fā)送失敗時(shí)返回類型和HAL庫的返回類型不匹配。CANfestival要求發(fā)送函數(shù)返回成功與否HAL_CAN_AddTxMessage返回HAL_OK表示入隊(duì)成功這里要注意如果郵箱滿了要重試有些代碼圖省事直接丟幀會(huì)導(dǎo)致SDO可靠傳輸?shù)恼Z義被破壞。我實(shí)現(xiàn)的canSend里對(duì)失敗嘗試重試三次仍然失敗才返回0這樣極大減少了偶發(fā)丟幀引起的通信超時(shí)。3.3 1ms定時(shí)器基準(zhǔn)setTimer/getElapsedTime的語義CANfestival要求外部提供一個(gè)1ms時(shí)基通過三個(gè)函數(shù)接入initTimer初始化定時(shí)器setTimer是設(shè)置一個(gè)目標(biāo)時(shí)間戳getElapsedTime返回從某個(gè)時(shí)間戳到當(dāng)前時(shí)間的差值。協(xié)議棧內(nèi)部靠這套接口實(shí)現(xiàn)心跳生產(chǎn)、PDO事件定時(shí)和SDO超時(shí)等時(shí)間管理。實(shí)現(xiàn)上我直接用STM32的SysTick維護(hù)一個(gè)32位遞增的毫秒計(jì)數(shù)。getElapsedTime的做法是當(dāng)前毫秒計(jì)數(shù)減去傳入的時(shí)間戳。這里有符號(hào)溢出的問題需要小心因?yàn)橛?jì)時(shí)值可能在某個(gè)時(shí)刻回繞。我自己用的寫法是把差值強(qiáng)制轉(zhuǎn)成UNS32再判斷是否超過協(xié)議棧的TIMER_MAX這樣即使回繞也能正確計(jì)算。協(xié)議棧主循環(huán)里會(huì)周期調(diào)用timerForCan()這個(gè)函數(shù)它會(huì)逐個(gè)檢查所有定時(shí)器是否到期并執(zhí)行對(duì)應(yīng)回調(diào)漏掉這個(gè)調(diào)用心跳和PDO事件模式都不會(huì)工作。3.4 初始化順序先OD后NMT順序錯(cuò)了節(jié)點(diǎn)就不上線移植完成后初始化順序直接決定節(jié)點(diǎn)是否能正常被主站發(fā)現(xiàn)。我的標(biāo)準(zhǔn)順序如下/* 1. 初始化硬件CAN、中斷、定時(shí)器 */ can_hw_init(); initTimer(); /* 2. CANopen協(xié)議棧初始化注冊(cè)O(shè)D、初始化通信模塊 */ canopen_init(TestNode, TestNode_OD); /* 3. 運(yùn)行協(xié)議棧調(diào)度之后配置參數(shù)也可通過SDO動(dòng)態(tài)下發(fā) */ canopen_start(TestNode); /* 4. 正常情況下將節(jié)點(diǎn)切換到Operational狀態(tài) */ TestNode.nmtState NMT_OPERATIONAL;這里有一個(gè)容易踩的坑如果你在主循環(huán)里直接設(shè)置nmtState為NMT_OPERATIONAL而協(xié)議棧內(nèi)部的NMT狀態(tài)機(jī)已經(jīng)通過0x0000COB-ID收到了主站發(fā)來的NMT命令狀態(tài)會(huì)被主站再次覆蓋。所以更穩(wěn)妥的做法是先保持在預(yù)操作狀態(tài)等主站發(fā)NMT啟動(dòng)命令后再進(jìn)入運(yùn)行狀態(tài)。有些主站軟件比如CANopen for Python連接后默認(rèn)會(huì)通過NMT啟動(dòng)所有節(jié)點(diǎn)如果你的從站自己在代碼里先切到了運(yùn)行狀態(tài)反而會(huì)讓主站的狀態(tài)追蹤出現(xiàn)混亂。我見過不少“從站能發(fā)數(shù)據(jù)但主站報(bào)異?！钡陌咐炊际沁@里。跑通到這一步用CAN分析儀應(yīng)該能看到從站周期性的心跳報(bào)文如果0x1017設(shè)了非零值這就是移植工作的里程碑。下面是配置示例UNS8 setup_heartbeat(void) { UNS32 prodTime 100; /* 100ms */ return setODentry(TestNode_OD, 0x1017, 0, prodTime, sizeof(prodTime)); }4. 對(duì)象字典配置與PDO動(dòng)態(tài)映射的實(shí)操技巧4.1 用工具生成OD文件而不是純手寫對(duì)象字典里面條目多純手寫od.c很容易在索引號(hào)、子索引數(shù)量上出低級(jí)錯(cuò)誤。官方工具鏈里有ObjDictEdit基于Python/Tkinter的編輯器可以在圖形界面里添加條目、設(shè)置類型、指定映射然后導(dǎo)出C代碼。另一種方式是用腳本直接生成適合批量維護(hù)多型號(hào)產(chǎn)品的OD。我自己習(xí)慣是用OBDictEditor把標(biāo)準(zhǔn)通信區(qū)域配置好再手動(dòng)往od.c里補(bǔ)廠商自定義條目兩邊對(duì)照著改效率高也不容易亂。用編輯器生成od.c/od.h后要確認(rèn)幾個(gè)關(guān)鍵默認(rèn)值是否符合你的期望0x1017心跳生產(chǎn)周期默認(rèn)是多少0x1018設(shè)備標(biāo)識(shí)的Vendor ID是否填了0x1000設(shè)備類型是否正確0x1800/0x1400這幾個(gè)PDO的COB-ID有沒有被改過。這些參數(shù)在聯(lián)調(diào)階段一旦出問題現(xiàn)象都比較隱蔽。4.2 添加自定義OD條目并在應(yīng)用層讀寫廠商自定義數(shù)據(jù)通常放在0x2000到0x5FFF。比如我要暴露一個(gè)16位的運(yùn)行模式給主站就在OD數(shù)組里加入0x2001條目。CANfestival的OD條目本質(zhì)上是一個(gè)結(jié)構(gòu)體數(shù)組包含初始值、子索引數(shù)量、類型和訪問權(quán)限等。類型定義在def.h里有UNS8、UNS16、UNS32、INTEGER16等還有對(duì)應(yīng)的回調(diào)字段。添加后應(yīng)用層代碼可以用getODentry和setODentry這兩個(gè)輔助函數(shù)來讀取或?qū)懭隣D值寫完后協(xié)議棧會(huì)自動(dòng)處理SDO請(qǐng)求的響應(yīng)。還有一個(gè)經(jīng)驗(yàn)OD條目值的字節(jié)序必須和協(xié)議棧目標(biāo)平臺(tái)一致。CANopen在總線上的多字節(jié)數(shù)值采用大端傳輸?shù)獵ANfestival在內(nèi)存中直接使用主機(jī)字節(jié)序應(yīng)用層在寫多字節(jié)OD值時(shí)不要自己翻轉(zhuǎn)字節(jié)序協(xié)議棧會(huì)在組報(bào)文時(shí)自動(dòng)處理好。如果你在應(yīng)用層手動(dòng)轉(zhuǎn)了一次反而會(huì)出現(xiàn)數(shù)值高低字節(jié)對(duì)調(diào)的問題。4.3 動(dòng)態(tài)修改PDO映射為什么不能只改TPDO參數(shù)PDO映射在實(shí)際項(xiàng)目中經(jīng)常需要?jiǎng)討B(tài)調(diào)整。比如設(shè)備上電后主站根據(jù)配置下發(fā)不同的映射表把電流、速度、位置組合進(jìn)一幀PDO。改PDO映射有兩種做法。一種是直接修改OD的0x1A00/0x1600映射參數(shù)用SDO寫入映射子索引表示映射對(duì)象數(shù)量和每個(gè)映射條目對(duì)象索引子索引位長很多支持動(dòng)態(tài)映射的主站會(huì)這樣操作。另一種是在編譯期就固定好映射靠重新編譯固件來改變。對(duì)量產(chǎn)設(shè)備來說動(dòng)態(tài)映射肯定更靈活。但動(dòng)態(tài)映射有一個(gè)必須注意的坑修改映射前要把節(jié)點(diǎn)從運(yùn)行狀態(tài)切到預(yù)操作狀態(tài)修改完成后再次啟動(dòng)節(jié)點(diǎn)。因?yàn)檫\(yùn)行狀態(tài)下PDO已經(jīng)在按舊映射組幀發(fā)送你改了OD里的映射參數(shù)發(fā)送引擎可能仍然沿用已緩存的舊配置導(dǎo)致數(shù)據(jù)其實(shí)是新的、但幀結(jié)構(gòu)還是舊的。這是CANopen標(biāo)準(zhǔn)里明文規(guī)定的流程很多工程師忽略掉后就會(huì)看到“改了映射但PDO數(shù)據(jù)沒變化”的怪現(xiàn)象。CANfestival里加一個(gè)自定義TPDO映射到一幀的代碼思路如下/* 假設(shè)要把0x2001子索引0、16位映射進(jìn)TPDO3 */ UNS32 mapEntry (0x2001UL 16) | 0x00000010UL; /* 對(duì)象索引 | 子索引 | 位長 */ setODentry(TestNode_OD, 0x1A02, 1, mapEntry, sizeof(mapEntry)); /* 然后禁止再發(fā)PDO重新進(jìn)入OP狀態(tài)讓映射生效 */4.4 事件型PDO和時(shí)間型PDO的取舍PDO的觸發(fā)方式有同步、事件、遠(yuǎn)程請(qǐng)求三種。同步模式下節(jié)點(diǎn)收到SYNC對(duì)象后發(fā)送PDO事件模式下某個(gè)變量變化時(shí)發(fā)送時(shí)間模式下按周期發(fā)送。CANfestival對(duì)TPDO的事件定時(shí)器配置在0x1800的通信參數(shù)里事件時(shí)間用毫米表示非零時(shí)協(xié)議棧會(huì)通過timerForCan周期檢查變化事件并觸發(fā)發(fā)送。實(shí)際調(diào)試中我發(fā)現(xiàn)“事件型”非常容易在地面總線通信里產(chǎn)生突發(fā)擁塞比如多個(gè)節(jié)點(diǎn)同時(shí)檢測到數(shù)據(jù)變化一下把總線占滿。所以AGV這種對(duì)實(shí)時(shí)性要求高的設(shè)備我更偏好同步模式用主站發(fā)SYNC統(tǒng)一節(jié)奏。同時(shí)在PDO中不要開啟事件定時(shí)器與同步計(jì)數(shù)同時(shí)生效的模式容易造成一幀數(shù)據(jù)反復(fù)發(fā)送消耗總線帶寬。這塊配置細(xì)節(jié)在CANfestival的文檔里描述不算清晰踩過一次后建議直接把事件定時(shí)器清零只用同步觸發(fā)。5. 聯(lián)調(diào)階段的高頻問題從站掉線、PDO無數(shù)據(jù)和心跳超時(shí)5.1 從站明明在線主站卻掃描不到接上CAN分析儀后最常遇到的第一個(gè)問題就是主站掃描不到從站。排查鏈路我從物理層起逐步往上推用示波器或CAN分析儀看總線波形確認(rèn)CAN_H和CAN_L差分電壓正常波特率是否和軟件配置一致。STM32的CAN波特率由預(yù)分頻器和位時(shí)序寄存器決定計(jì)算時(shí)要同時(shí)考慮APB1時(shí)鐘頻率和采樣點(diǎn)設(shè)置。一個(gè)常見的抄錯(cuò)數(shù)據(jù)是直接把例程里的波特率配置拿來用但例程是基于8MHz外部晶振算的你用12MHz或16MHz晶振就會(huì)不對(duì)。確認(rèn)終端電阻。CAN總線兩端要各接一個(gè)120Ω電阻調(diào)試單節(jié)點(diǎn)測試時(shí)只在收發(fā)器芯片到端子間接一個(gè)120Ω也勉強(qiáng)能跑但如果總線上掛了多個(gè)節(jié)點(diǎn)缺少終端電阻會(huì)導(dǎo)致信號(hào)反射輕則波特率稍偏就通信錯(cuò)誤重則完全不通。確認(rèn)0x1005同步COB-ID、節(jié)點(diǎn)ID是否被正確設(shè)置。如果多個(gè)從站在同一總線上節(jié)點(diǎn)ID沖突后上電的節(jié)點(diǎn)會(huì)把先上電的節(jié)點(diǎn)擠下線。CANfestival的節(jié)點(diǎn)ID在初始化代碼里通過setNodeId設(shè)置如果同時(shí)使用了撥碼開關(guān)讀取功能要確保上電后初始化順序是先讀撥碼再setNodeId。物理層和節(jié)點(diǎn)ID都正常還是掃不到就要用CAN分析儀抓SDO回答報(bào)文。從站收到一個(gè)索引請(qǐng)求如果OD里沒有這個(gè)索引會(huì)回復(fù)一個(gè)SDO中止報(bào)文錯(cuò)誤碼藏在數(shù)據(jù)場里。比如0x06090011表示對(duì)象不存在0x06010000表示訪問不支持。通過看分析儀解碼出來的錯(cuò)誤碼能直接定位是OD條目缺失還是訪問權(quán)限不對(duì)。5.2 主站能看到心跳但PDO數(shù)據(jù)一直不更新這個(gè)問題的常見原因有兩個(gè)一個(gè)是節(jié)點(diǎn)沒有進(jìn)入運(yùn)行狀態(tài)另一個(gè)是PDO映射或事件觸發(fā)沒配對(duì)。先說狀態(tài)。主站能看到心跳說明從站還在預(yù)操作狀態(tài)。預(yù)操作狀態(tài)下NMT允許心跳和SDO通信但不允許PDO通信。這時(shí)候如果應(yīng)用代碼里已經(jīng)把變量值寫到了OD映射地址但總線上一幀TPDO都沒有一定先檢查從站的nmtState。解決辦法很簡單通過CAN分析儀手動(dòng)發(fā)送NMT啟動(dòng)命令COB-ID 0x000數(shù)據(jù)為0x01 0x0A節(jié)點(diǎn)ID為0x0A看PDO是否立刻開始發(fā)。如果手動(dòng)NMT能觸發(fā)說明你的主站軟件連接流程里沒有自動(dòng)發(fā)送NMT啟動(dòng)命令需要在主站初始化序列里補(bǔ)上。另外注意PDO映射條目的位寬設(shè)置。比如OD里0x2001是UNS1616位映射條目配置成了0x000000088位CANfestival發(fā)送時(shí)只會(huì)取低8位如果你在應(yīng)用里寫入的是0x1234實(shí)際發(fā)出去的只是0x34。這類問題在分析儀解碼里不容易發(fā)現(xiàn)因?yàn)閹Y(jié)構(gòu)和長度都正常。我習(xí)慣在聯(lián)調(diào)初期先做一個(gè)純測試型PDO映射幾個(gè)已知值發(fā)出來和分析儀對(duì)比字段確認(rèn)映射正確后再換成真實(shí)數(shù)據(jù)。5.3 心跳超時(shí)不該把0x1017當(dāng)成唯一的排查點(diǎn)從站心跳超時(shí)是最常見也最好排查的一類問題。如果0x1017設(shè)置成0表示不做心跳生產(chǎn)主站當(dāng)然收不到。如果非零要確認(rèn)CANfestival的timerForCan在主循環(huán)里的調(diào)用頻率。心跳生產(chǎn)依賴這個(gè)函數(shù)推進(jìn)計(jì)時(shí)器鏈如果你的主循環(huán)被一個(gè)長阻塞操作卡住心跳就會(huì)偶爾晚點(diǎn)超過主站監(jiān)控窗口后報(bào)超時(shí)。解決方法是把心跳周期和主站消費(fèi)周期拉開差距我一般讓心跳100ms主站消費(fèi)超時(shí)窗口設(shè)600ms這樣即使主循環(huán)偶爾卡個(gè)兩百毫秒也不至于誤報(bào)。還有一個(gè)隱蔽問題多個(gè)從站在同一節(jié)點(diǎn)ID下發(fā)送心跳COB-ID 0x700加節(jié)點(diǎn)ID會(huì)沖突。如果有一個(gè)從站的節(jié)點(diǎn)ID被錯(cuò)誤設(shè)置成另一個(gè)節(jié)點(diǎn)的ID總線上會(huì)間歇性出現(xiàn)錯(cuò)誤幀主站會(huì)捕捉到異常心跳誤判定原節(jié)點(diǎn)掉線。這種情況下用CAN分析儀的報(bào)文列表按時(shí)間排序能看出同一個(gè)COB-ID同時(shí)有兩個(gè)節(jié)點(diǎn)在周期性發(fā)數(shù)據(jù)。曾經(jīng)我在現(xiàn)場排查一個(gè)“系統(tǒng)跑一段時(shí)間后總有從站掉線”的問題最后發(fā)現(xiàn)是生產(chǎn)裝配時(shí)某臺(tái)設(shè)備撥碼開關(guān)沒撥到位兩個(gè)驅(qū)動(dòng)器用了同一個(gè)節(jié)點(diǎn)ID。5.4 一個(gè)完整排查案例SDO能寫參數(shù)但保存后上電丟失最后分享一個(gè)讓我印象深刻的案例。某設(shè)備通過主站寫0x1010保存參數(shù)SDO返回成功但斷電重啟后參數(shù)變回默認(rèn)值。第一反應(yīng)是Flash存儲(chǔ)邏輯有bug檢查后應(yīng)用層確實(shí)調(diào)用了寫入函數(shù)。后來單步跟蹤C(jī)ANfestival的保存請(qǐng)求處理流程發(fā)現(xiàn)協(xié)議棧在處理0x1010時(shí)只是把從站數(shù)據(jù)保存到內(nèi)部緩沖區(qū)實(shí)際情況是需要應(yīng)用自己去處理Flash寫入。標(biāo)準(zhǔn)CANopen里0x1010簽名是“保存參數(shù)”協(xié)議棧只負(fù)責(zé)調(diào)用一個(gè)可重載的保存回調(diào)如果移植時(shí)沒有實(shí)現(xiàn)這個(gè)回調(diào)節(jié)點(diǎn)就會(huì)對(duì)主站報(bào)“保存成功”但實(shí)際什么都沒做。最終我在應(yīng)用層增加了Flash存儲(chǔ)任務(wù)在保存請(qǐng)求回調(diào)里把OD中的關(guān)鍵參數(shù)輪詢一遍寫入扇區(qū)再重啟加載問題就解決了。這類問題在文檔里很難發(fā)現(xiàn)只有動(dòng)手跟蹤源碼才能看到真正的處理流程。這也是我堅(jiān)持用開源協(xié)議棧的原因黑盒方案很可能在這類邊緣需求上卡住好幾天。寫在最后如果你正在一個(gè)資源不寬裕的MCU上做CANopen從站CANfestival是值得花時(shí)間投入的。它在代碼風(fēng)格上確實(shí)帶著老派工程師的脾氣但咬住對(duì)象字典這條主線再配合CAN分析儀一層層看報(bào)文很快就能建立起直覺?，F(xiàn)在我做CANopen相關(guān)項(xiàng)目時(shí)已經(jīng)養(yǎng)成了“先用分析儀抓標(biāo)準(zhǔn)報(bào)文、再打開協(xié)議棧源碼對(duì)照”的習(xí)慣很多疑難問題其實(shí)在源碼里都有答案只是等你去看。本文還有配套的精品資源點(diǎn)擊獲取