嵌入式通信【免費下載鏈接】CANopenNodeCANopen protocol stack項目地址https://gitcode.com/gh_mirrors/ca/CANopenNode點擊查看免費下載CANopenNode 是一套用 ANSI C 編寫、面向?qū)ο蠓绞綄崿F(xiàn)的 CANopen 協(xié)議棧CiA 301 / DS-301但它刻意將協(xié)議棧核心與具體硬件驅(qū)動徹底分離主倉庫不包含任何針對某款芯片的驅(qū)動代碼所有硬件相關(guān)文件都由外部獨立工程提供。本文以倉庫內(nèi)的 doc/deviceSupport.md 為主體結(jié)合 301/CO_driver.h 與 example 目錄下的空白驅(qū)動模板系統(tǒng)講解 CANopenNode 的設(shè)備接口規(guī)范、最小可編譯工程的用法、驅(qū)動開發(fā)者推薦的移植工作流程以及當(dāng)前社區(qū)已確認(rèn)支持的 Linux、STM32、PIC、Analog Devices、Zephyr 等各類平臺清單幫助讀者快速完成自有硬件的移植接入。一、設(shè)計理念協(xié)議棧與硬件驅(qū)動徹底分離CANopenNode 可以運行在數(shù)量眾多的設(shè)備上從簡單的 16 位微控制器到 PC 計算機存在大量不同硬件、不同開發(fā)工具、不同開發(fā)者維護的實現(xiàn)。正如 doc/deviceSupport.md 開頭所述單個項目維護者不可能持續(xù)跟進所有硬件接口的更新因此所有硬件相關(guān)文件都不屬于 CANopenNode 主項目。這種設(shè)計帶來的直接好處是協(xié)議棧核心與硬件無關(guān)301目錄下的 NMT、PDO、SDO、Emergency、SYNC、TIME、LSS 等協(xié)議模塊以及storage、303LED、304SRDO/GFC、305LSS、309ASCII gateway等擴展模塊都只依賴一個統(tǒng)一的驅(qū)動抽象層。從源碼結(jié)構(gòu)看每個設(shè)備移植工程只需要向 CANopenNode 提供三個接口文件見 301/CO_driver.h 的 Hardware interface of CANopenNode 一節(jié)文件職責(zé)是否屬于主倉庫CO_driver.h聲明通用驅(qū)動函數(shù)與類型被 CANopenNode 的每個 .c 文件包含是位于 301/CO_driver.hCO_driver_target.h定義微控制器特定的類型聲明與必要宏否由各設(shè)備工程提供本倉庫提供空模板CO_driver.c實現(xiàn)CO_driver.h中聲明的函數(shù)否由各設(shè)備工程提供本倉庫提供空模板本倉庫僅在example目錄中提供了兩個基本為空的模板文件保證CANopenNode/example能在任何系統(tǒng)上編譯通過但編譯出的程序沒有連接真實 CAN 硬件不可直接使用。完整的設(shè)備接口文檔集中在 301/CO_driver.h 中。二、設(shè)備接口規(guī)范驅(qū)動層到底要實現(xiàn)什么以 301/CO_driver.h 為權(quán)威依據(jù)一個完整的 CAN 驅(qū)動必須實現(xiàn)以下核心數(shù)據(jù)結(jié)構(gòu)與函數(shù)。2.1 三個核心數(shù)據(jù)結(jié)構(gòu)CO_CANrx_t接收幀配置對象包含標(biāo)準(zhǔn) CAN 標(biāo)識符identbit 0..10 為 IDbit 11 為 RTR、掩碼mask、綁定的 CANopen 對象指針object以及回調(diào)函數(shù)指針pCANrx_callback。CO_CANtx_t發(fā)送幀配置對象包含按 CAN 模塊對齊的標(biāo)識符ident、幀長度DLC、8 字節(jié)數(shù)據(jù)data[8]以及兩個關(guān)鍵標(biāo)志bufferFull上一幀是否仍在緩沖中與syncFlag同步 PDO 標(biāo)志防止同步幀在同步窗口外發(fā)出。CO_CANmodule_t完整 CAN 模塊對象聚合了rxArray/txArray及其大小、CANerrorStatus錯誤狀態(tài)位域、CANnormal運行模式標(biāo)志、useCANrxFilters硬件過濾器使用標(biāo)志、bufferInhibitFlag、firstCANtxMessage、CANtxCount等。2.2 必須實現(xiàn)的函數(shù)清單301/CO_driver.h 聲明了以下關(guān)鍵驅(qū)動函數(shù)空白實現(xiàn)可參考 example/CO_driver_blank.c函數(shù)作用與要點CO_CANsetConfigurationMode(CANptr)請求 CAN 進入配置停止模式并等待完成CO_CANsetNormalMode(CANmodule)請求 CAN 進入正常運行模式置CANnormal trueCO_CANmodule_init(...)初始化 CAN 模塊對象與硬件寄存器必須在通信復(fù)位階段、配置模式下調(diào)用。合法位速率kbps為 10、20、50、125、250、500、800、1000非法值默認(rèn)回落為 125CO_CANmodule_disable(CANmodule)程序退出時關(guān)閉 CAN 模塊CO_CANrxBufferInit(...)配置接收緩沖設(shè)置標(biāo)識符與掩碼并綁定對象與回調(diào)。同一標(biāo)識符下索引最小者優(yōu)先CO_CANtxBufferInit(...)配置發(fā)送緩沖設(shè)置標(biāo)識符、RTR、幀長與syncFlag返回待填充數(shù)據(jù)的緩沖指針CO_CANsend(CANmodule, buffer)發(fā)送 CAN 幀若硬件發(fā)送緩沖空閑則直接復(fù)制否則置bufferFull等待 TX 中斷發(fā)送CO_CANclearPendingSyncPDOs(...)同步窗口超時后清空所有掛起的同步 TPDOCO_CANmodule_process(CANmodule)周期性調(diào)用計算CANerrorStatus錯誤位域CO_CANinterrupt(CANmodule)中斷入口接收中斷做標(biāo)識符匹配并調(diào)用CANrx_callback快速預(yù)處理發(fā)送中斷按索引順序發(fā)送排隊幀接收側(cè)的回調(diào)機制尤其重要CAN 幀先由硬件或軟件過濾中斷/實時線程根據(jù) 11 位 CAN-ID 與掩碼判定歸屬的 CANopen 對象然后調(diào)用對應(yīng)的CANrx_callback()快速提取數(shù)據(jù)供普通線程稍后處理。CO_CANrxMsg_readIdent()、CO_CANrxMsg_readDLC()、CO_CANrxMsg_readData()是目標(biāo)平臺需以內(nèi)聯(lián)函數(shù)或宏方式提供的幀讀取輔助函數(shù)。2.3 錯誤狀態(tài)與返回值約定驅(qū)動層的CO_CANmodule_process()需要按 301/CO_driver.h 的位域約定上報錯誤收發(fā)錯誤計數(shù)器 ≥ 96 進入 warning 級≥ 128 進入 passive 級發(fā)送計數(shù)器 ≥ 256 進入 bus off。位域包括CO_CAN_ERRTX_WARNING、CO_CAN_ERRTX_PASSIVE、CO_CAN_ERRTX_BUS_OFF、CO_CAN_ERRTX_OVERFLOW、CO_CAN_ERRTX_PDO_LATE、CO_CAN_ERRRX_WARNING、CO_CAN_ERRRX_PASSIVE、CO_CAN_ERRRX_OVERFLOW等。函數(shù)統(tǒng)一返回CO_ReturnError_t枚舉定義見 301/CO_driver.h包括CO_ERROR_NO、CO_ERROR_ILLEGAL_ARGUMENT、CO_ERROR_ILLEGAL_BAUDRATE、CO_ERROR_TX_OVERFLOW、CO_ERROR_TX_PDO_WINDOW等 20 余種方便上層協(xié)議模塊與應(yīng)用程序統(tǒng)一處理。2.4 多線程與 RTOS 移植的關(guān)鍵宏CANopenNode 原生支持多線程裸機下表現(xiàn)為不同優(yōu)先級的中斷。驅(qū)動模板必須在CO_driver_target.h中定義以下同步宏CO_LOCK_CAN_SEND/CO_UNLOCK_CAN_SEND保護CO_CANsend()臨界區(qū)CO_LOCK_EMCY/CO_UNLOCK_EMCY保護CO_errorReport()/CO_errorReset()CO_LOCK_OD/CO_UNLOCK_OD保護對象字典OD讀寫防止實時線程與主線程并發(fā)訪問CO_FLAG_READ/CO_FLAG_SET/CO_FLAG_CLEAR接收新幀標(biāo)志的讀寫配合內(nèi)存屏障CO_MemoryBarrier()防止編譯器優(yōu)化亂序。example/CO_driver_target.h提供了全部為空實現(xiàn)的模板Zephyr、FreeRTOS、Mbed-os 等 RTOS 移植則需用互斥量、信號量或關(guān)調(diào)度實現(xiàn)這些宏這通常是移植工作量最大的部分之一。三、空白模板example 目錄——任何系統(tǒng)上都能編譯的最小工程example 目錄不包含任何特定設(shè)備接口它本身就是驅(qū)動模板與最小應(yīng)用示例的結(jié)合體可作為新移植工程的起點。目錄內(nèi)的文件職責(zé)如下文件職責(zé)example/CO_driver_blank.c空白驅(qū)動實現(xiàn)每個函數(shù)只有骨架與參數(shù)校驗寄存器操作留空example/CO_driver_target.h空白目標(biāo)定義CO_LITTLE_ENDIAN、基礎(chǔ)類型、三個數(shù)據(jù)結(jié)構(gòu)、空同步宏example/main_blank.c完整的主程序流程模板見下文example/OD.c / example/OD.h由 CANopenEditor 等外部工具生成的對象字典example/CO_storageBlank.c /.h非易失存儲的空白實現(xiàn)example/Makefile使用 gcc 編譯的 Makefile目標(biāo)產(chǎn)物canopennode_blankexample/DS301_profile.edsDS301 設(shè)備描述文件EDS供組態(tài)工具使用編譯驗證非常簡單需要 gcc 環(huán)境在倉庫根目錄執(zhí)行cd example makeexample/Makefile 將CO_driver_blank.c、CO_storageBlank.c與301、303、305、storage目錄下的協(xié)議模塊以及CANopen.c、OD.c、main_blank.c一并編譯鏈接-Wall開告警、-g開調(diào)試信息還預(yù)留了CO_USE_GLOBALS與CO_MULTIPLE_OD兩個可選宏的開關(guān)位。example/main_blank.c 演示了標(biāo)準(zhǔn)初始化與運行流程這是每個真實移植工程主程序的骨架CO_new()分配并創(chuàng)建 CANopen 對象也可用CO_USE_GLOBALS改用全局變量進入通信復(fù)位循環(huán)CO_CANsetConfigurationMode()→CO_CANmodule_disable()→CO_CANinit()CAN 與位速率→CO_LSSinit()LSS 從站地址與待定 node-ID/位速率→CO_CANopenInit()NMT、SDO server/client、Emergency 等→CO_CANopenInitPDO()PDO 映射→CO_CANsetNormalMode()普通線程循環(huán)調(diào)用CO_process()處理所有異步對象實時線程tmrTask_thread典型 1 ms 周期依次調(diào)用CO_process_SYNC()、CO_process_RPDO()、CO_process_TPDO()并在CO_LOCK_OD/CO_UNLOCK_OD保護下執(zhí)行CO_CAN1InterruptHandler()是 CAN 接收/發(fā)送中斷入口的占位。Node-ID 與位速率在模板中以pendingNodeId默認(rèn) 10與pendingBitRate默認(rèn) 125 kbps體現(xiàn)注釋明確說明真實設(shè)備應(yīng)從撥碼開關(guān)或非易失存儲讀取并可由 LSS 從站配置——這正是把 LSSCiA 305用于在線改節(jié)點地址與波特率的接入點相關(guān)實現(xiàn)見 305/CO_LSSslave.c。四、驅(qū)動開發(fā)者推薦工作流程官方七步法doc/deviceSupport.md 專門為希望共享與協(xié)作的驅(qū)動開發(fā)者給出了推薦流程這是社區(qū)長期實踐沉淀的移植方法論建立獨立的設(shè)備 demo 工程倉庫在 Git 托管平臺創(chuàng)建你自己的設(shè)備專用倉庫引入 CANopenNode 核心將 CANopenNode 作為 git 子模塊加入工程例如git submodule add https://gitcode.com/gh_mirrors/ca/CANopenNode原始文檔建議添加上游倉庫地址使用鏡像地址同樣可以完成子模塊引入引入后 CANopenNode 核心代碼保持不動便于后續(xù)升級。添加具體驅(qū)動與工程文件編寫CO_driver_target.h與CO_driver.c并加入應(yīng)用代碼、對象字典、構(gòu)建腳本撰寫良好的 README.md描述你的工程、所用 demo 板、開發(fā)工具與用法可選準(zhǔn)備 CANopenDemo 設(shè)備并運行測試在 CANopenDemo 倉庫中提供 demoDevice利用其教程與測試工具驗證移植正確性分享成果在 doc/deviceSupport.md 中新增設(shè)備條目并提交 Pull Request或在 CANopenNode 的 issues 中為新設(shè)備創(chuàng)建 issue申請成為項目開發(fā)者將你的工作貢獻(xiàn)并入 CANopenNode 項目成為其開發(fā)者共同提升代碼質(zhì)量與功能完整性。文檔同時指出目前最新、最完整的參考實現(xiàn)是 CANopenLinux 與 CANopenPIC面向 PIC32 裸機移植時可優(yōu)先參考這兩個工程example目錄則是最小化的通用模板。五、社區(qū)已確認(rèn)的設(shè)備支持清單以下是 doc/deviceSupport.md 記錄的設(shè)備/平臺支持現(xiàn)狀信息以文檔記錄為準(zhǔn)工程托管于各自獨立倉庫此處僅列出關(guān)鍵事實。5.1 主流活躍端口平臺說明CANopenNode 版本狀態(tài)特性工具 / 硬件LinuxsocketCAN與 Linux 內(nèi)核 socketCAN 集成帶主站命令接口文檔明確說明其接口屬于本項目體系v4.0活躍參考實現(xiàn)OD 存儲、錯誤計數(shù)器、主站功能SDO client、LSS master、NMT masterLinux PC、樹莓派等STM32STM32 微控制器集成v4.0———PIC32 / dsPIC30 / dsPIC33Microchip 16/32 位 PIC 系列最完整參考實現(xiàn)之一v4.0活躍參考實現(xiàn)PIC32 OD 存儲、PIC32 SDO client demo、錯誤計數(shù)器MPLAB XExplorer 16、Max32 板已知最小資源示例dsPIC30F401116 位RAM 不足 2KB4 TPDO 4 RPDOAnalog Devices MAX32662 / MAX32690ADI MAX32xx 系列集成v4.0看似穩(wěn)定LED 指示燈、錯誤計數(shù)器Maxim Micros SDKMAX32662-EVKIT、MAX32690-EVKIT信息更新于 2023-02-17Zephyr RTOSZephyr 官方模塊級集成含示例工程v1.3穩(wěn)定OD 存儲、LED 指示燈、Program Download、Zephyr SDO server demoZephyr SDK任意帶 CAN 接口且支持 Zephyr 的開發(fā)板信息更新于 2025-11-13Mbed-os RTOS STM32F091RC、L496ZGMbed-os 集成—穩(wěn)定OD 存儲、LED 指示燈、GPIOMbed CLIgcc 7STM32 Nucleo F091RC 等帶 CAN 的開發(fā)板信息更新于 2020-01-215.2 社區(qū)貢獻(xiàn)端口平臺說明CANopenNode 版本狀態(tài)特性Kinetis K20NXP ArmTeensy3面向 Teensy3 的驅(qū)動配套 readme 文檔v1.02017-08-01看似穩(wěn)定錯誤計數(shù)器信息更新于 2020-03-02S32DSNXP S32 Design StudioArm / PowerPC支持 S32K144EVB-Q100、DEVKIT-MPC5748G 等評估板文檔隨驅(qū)動附送v1.02017-08-01看似穩(wěn)定錯誤計數(shù)器信息更新于 2020-03-02ESP32社區(qū)多次討論2023-03、2020-07CANopenNode_ESP32作為 ESP-IDF 組件為便于維護直接使用未修改的 CANopenNode 核心另有配套示例工程—社區(qū)維護基于 ESP-IDF 框架FreeRTOSNeuberger 版基于 v1.3-master 分支的 FreeRTOS 移植2020-06-23v1.3社區(qū)維護多線程移植參考STM32CubeMX HALAtollic Studio 的 demo 工程在 Nucleo STM32L452xx 板上測試通過2019-05-03—社區(qū)維護基于 STM32CubeMX HAL 庫K64F FreeRTOSKinetis SDKKinetis SDK 平臺的 FreeRTOS 移植2018-02-13—社區(qū)維護—LPC1768MBED2016 年發(fā)布的 CANopenNode v1.0 時代示例v1.0歷史最早一批 MBED 移植5.3 歷史端口v1.0 時代文檔還記錄了已不再活躍的歷史實現(xiàn)供參考與追溯RTOS eCos2013、Atmel SAM3X、ST STM32、NXP LPC177x_8x、Freescale MCF5282均為 CANopenNode v1.0 時代、BECK IPC Embedded Web-Controller SC2432015 年最后一次發(fā)布、ADI ADSP-CM408 混合信號控制器2014 年貢獻(xiàn)、Microchip PIC18F2006 年最后一次發(fā)布以及最初屬于 CANopenNode 的舊版 Object Dictionary Editor依賴極老版本的 Firefox 運行。這些條目印證了 CANopenNode 自 2006 年以來在多代硬件上的持續(xù)演進。六、設(shè)備特性與倉庫源碼的對應(yīng)關(guān)系文檔中反復(fù)出現(xiàn)的設(shè)備特性都能在當(dāng)前倉庫中找到對應(yīng)的協(xié)議實現(xiàn)模塊這為移植后的功能驗收提供了明確抓手文檔提到的特性倉庫中的實現(xiàn)位置OD 存儲自動或由標(biāo)準(zhǔn) CANopen 命令觸發(fā)storage/CO_storage.c 與 example/CO_storageBlank.c通過 OD 對象 1010h/1011h 子索引配合 CRC 校驗實現(xiàn)非易失保存/恢復(fù)錯誤計數(shù)器 / Emergency301/CO_Emergency.c 配合驅(qū)動層CO_CANmodule_process()的CANerrorStatus位域主站功能SDO client、LSS master、NMT master301/CO_SDOclient.c、305/CO_LSSmaster.c、301/CO_NMT_Heartbeat.cLED 指示燈CiA 303-3303/CO_LEDs.cCANopen 狀態(tài)紅綠雙色指示節(jié)點地址/波特率在線配置305/CO_LSSslave.c 與 main_blank.c 中的pendingNodeId/pendingBitRate網(wǎng)關(guān) / 外部訪問309/CO_gateway_ascii.cCiA 309-3 ASCII 命令接口所有模塊的全局協(xié)調(diào)入口在 CANopen.hCO_new()、CO_CANinit()、CO_CANopenInit()、CO_CANopenInitPDO()、CO_process()等構(gòu)成了與平臺無關(guān)的初始化—運行契約而 301/CO_config.h 則負(fù)責(zé)各模塊的編譯期裁剪如是否啟用 SDO client、LSS、LED 等設(shè)備移植時可按需裁剪以節(jié)省資源——這也是 PIC 端能做到RAM 不足 2KB的重要原因。七、移植新設(shè)備的關(guān)鍵檢查點綜合 doc/deviceSupport.md、301/CO_driver.h 與 example 模板移植一個新平臺時建議按以下順序自檢類型與字節(jié)序在CO_driver_target.h中正確聲明CO_LITTLE_ENDIAN或CO_BIG_ENDIANCANopen 本身為小端定義bool_t、CO_CANrx_t、CO_CANtx_t、CO_CANmodule_tCAN 初始化與位速率實現(xiàn)CO_CANmodule_init()支持文檔規(guī)定的 8 種位速率非法值回落 125收發(fā)路徑實現(xiàn)CO_CANrxBufferInit()/CO_CANtxBufferInit()/CO_CANsend()接收側(cè)提供CO_CANrxMsg_readIdent/DLC/Data并實現(xiàn)CO_CANinterrupt()的匹配分發(fā)與發(fā)送隊列同步與臨界區(qū)按目標(biāo)平臺裸機中斷優(yōu)先級或 RTOS 互斥量落實CO_LOCK_*與CO_FLAG_*宏周期處理保證CO_CANmodule_process()、CO_process()及 1 ms 級實時線程SYNC/RPDO/TPDO按文檔要求的調(diào)用節(jié)奏運行工程閉環(huán)以example為起點編寫應(yīng)用與 OD先在任意系統(tǒng)上通過make編譯再移植驅(qū)動接入真實總線最后參照第五節(jié)特性清單逐項驗證。按照文檔的定位CANopenNode 是一個開放移植生態(tài)而非封閉實現(xiàn)官方維護 Linux 接口其他控制器接口由獨立工程承載并通過 doc/deviceSupport.md 持續(xù)登記新設(shè)備。對開發(fā)者而言最務(wù)實的路徑是——以 example 空白模板為本、以 CANopenLinux 與 CANopenPIC 為參照、按官方七步法提交自己的移植成果讓 CANopen 協(xié)議棧在你的硬件上穩(wěn)定運行并回饋到整個社區(qū)。贊分享嵌入式通信【免費下載鏈接】CANopenNodeCANopen protocol stack項目地址https://gitcode.com/gh_mirrors/ca/CANopenNode點擊查看免費下載相關(guān)推薦GsonFactory最佳實踐避免這些坑讓你的解析更高效GsonFactory最佳實踐避免這些坑讓你的解析更高效 在Android開發(fā)中Json解析是每個開發(fā)者都會遇到的基礎(chǔ)任務(wù)但你是否經(jīng)常遇到因為后臺數(shù)據(jù)格式移動開發(fā)序列化F′ 新平臺移植指南Toolchain、平臺文件、Fw::Types、硬件驅(qū)動與 OSAL 五步移植法F′ 新平臺移植指南Toolchain、平臺文件、Fw::Types、硬件驅(qū)動與 OSAL 五步移植法 F′F Prime是一個面向飛行軟件與嵌入式系統(tǒng)的嵌入式系統(tǒng)編程Dogecoin 內(nèi)嵌 LevelDB 的 port 平臺抽象層解析接口設(shè)計、默認(rèn)實現(xiàn)與跨平臺移植指南Dogecoin 內(nèi)嵌 LevelDB 的 port 平臺抽象層解析接口設(shè)計、默認(rèn)實現(xiàn)與跨平臺移植指南 本文圍繞 src/leveldb/port/READM區(qū)塊鏈上一篇Docker快速部署AntSK從容器配置到模型掛載完整教程下一篇如何自定義量化NVIDIA-Nemotron-3-Nano-30B-A3B-OptiQ-4bitmlx-optiq高級配置教程創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考