简介CANopen是运行在控制器局域网络上的高层通信协议它以对象字典为核心通过过程数据对象、服务数据对象与网络管理对象等机制为不同制造商的CAN设备提供统一的数据交互与网络管理规范能够有效提升系统扩展性与设备互操作性。这份资源面向STM32F1系列单片机开发者基于开源CANfestival协议栈从CAN外设参数配置、协议库移植到应用层回调编写完整呈现一个CANopen从站节点的开发流程。压缩包共包含931个文件主体为C语言源文件与头文件覆盖对象字典定义、PDO与SDO处理、NMT状态机及CAN驱动等关键源码同时附有编译链接脚本、Keil工程配置、批处理工具及目标文件便于直接导入环境或分析内部细节整个包大小约28.8MB。从工程组织上看源码、配置与工具脚本分离对象字典、应用回调和驱动接口均独立成模块代码注释较为详细便于二次开发与功能裁剪。已有392人学习下载适合希望系统掌握CANopen协议实现或正在从事工业控制、设备组网与嵌入式软件开发的工程师参考使用。1. 直接上 STM32F1 跑 CANopen第一个坑往往是对象字典很多人第一次接触 CANopen会下意识把 CAN 总线当成一根“多主串口”自定义一帧数据带设备地址、命令字、校验位直接发出去。设备少时确实能跑但只要 PLC 或工控机上挂的伺服、变频器一多就会暴露帧格式不统一、优先级没法仲裁、在线状态没人管理这三个问题。CANopen 的价值在于它把“数据在总线上怎么排”变成了“对象字典里谁在哪”通信帧只管索引和子索引业务数据全部落在对象字典里。STM32F1 的 bxCAN 外设只负责收发帧CANopen 协议栈用 CANfestival 补齐后从站代码量可以控制在十几 KB 级别一块 F103 完全可以同时做采集、控制和协议处理。这篇整理的目标是把 CANfestival 在 STM32F1 上的移植路径、对象字典的配置方法以及调试手段讲完整适合准备把设备接入工业 CANopen 网络的嵌入式工程师。2. CANopen 协议详解对象字典、层级结构与 CANfestival 的选型理由2.1 对象字典是 CANopen 的层级结构核心CANopen 的层级结构可以从两层来看底层是 ISO 11898-1 标准的 CAN 帧上层是 CiA 301 定义的应用层。应用层全部围绕一个叫对象字典Object Dictionary简称 OD的表格展开。每个对象用 16 位索引加 8 位子索引定位例如 0x1000 是设备类型0x1005 是同步 COB-ID0x1017 是心跳时间。通信相关条目集中在 0x1000~0x1FFF制造商自定义区域在 0x2000~0x5FFF标准设备子协议如 CiA 402 驱动、CiA 404 传感器使用 0x6000 以上的索引。STM32F1 做从站时最常用的是 0x2000 区域放自定义的温度、状态、控制字再把它们映射到 PDO 里去传输。对象字典不只是一个数据结构它还是主站访问从站的统一视图。主站用 SDO 读 0x1000 就能判断总线上挂的是什么设备读 0x1017 能知道从站多久报一次心跳。CANfestival 把对象字典定义成一个CO_Data结构体里面挂着全部条目每次收到标准帧就按 COB-ID 查表处理。理解了这个层级结构后面配置对象映射、调 PDO 传输才不会乱。实际写应用代码时宁可多花半小时把字典里的条目设计清楚也不要边写业务边临时往里塞索引否则后面 SDO 调试时索引对不上最难受。2.2 NMT、PDO、SDO、心跳在工作时各管一摊CANopen 在同一根总线上同时存在四种主要的通信对象它们的分工是协议设计上最值得学习的地方NMT网络管理主站给从站发命令控制从站在初始化、预操作态、操作态、停止态之间切换。一个 CANopen 网络要求只能有一个 NMT 主站从站收到“进入操作态”命令后才允许发 PDO。PDO过程数据用于周期或事件触发的实时数据无应答、单帧最多传 8 字节适合温度、转速、状态字这类高频数据。SDO服务数据用于配置参数和读写对象字典有应答、支持分段传大于 8 字节的数据适合电机运行参数、校准表这类低频大块数据。心跳Heartbeat从站按 0x1017 规定的时间周期性发 0x700节点ID 的报文主站靠它判断从站是否掉线。通信对象方向COB-ID 范围特点典型用途NMT主站到从站0x000无应答广播状态切换PDO生产者到消费者0x180nodeId / 0x200nodeId无应答最多 8 字节实时过程数据SDO客户端/服务器0x600nodeId / 0x580nodeId有应答支持分段读写对象字典心跳从站到主站0x700nodeId周期发送在线监控从这四个对象的区别能得出一个使用原则跑数据用 PDO调参数用 SDO管状态用 NMT看节点活没活着用心跳。CANfestival 源码里的nmt.c、pdo.c、sdo.c、lifegrd.c就是按这个分工组织的移植时不需要改它们本身的逻辑只要保证底层驱动把帧送进canDispatch协议栈就会自动分发到对应模块。2.3 CANopen 节点上线与离开的时序要求从站上电后先进入初始化状态完成自检后自动切到预操作态。预操作态下允许 SDO 通信和心跳但不允许发 PDO。只有 NMT 主站发出“启动节点进入操作态”命令后PDO 才开始传输这个过程就是常说的节点上线。反过来节点下电或心跳超时主站应把该从站标记为离线驱动层对错误帧做清理避免总线上留下一堆没人接收的 PDO 数据。从站实现进入和离开逻辑时需要特别注意两点一是 NMT 命令是广播帧COB-ID 固定为 0x000从站必须检查命令字和节点 ID只有 0x01 或 0x81 两种命令字匹配自己时才执行状态切换二是从站在收到“停止节点”命令后要把自己维护的 PDO 发送定时器清掉。CANfestival 中这些动作分别在nmt.c的状态机里处理APP 层只需要在节点 ID 匹配时调setState不需要手动干预通信对象。2.4 STM32F1 选 CANfestival而不是自己写协议或换 CanOpenNode自研帧协议的问题不是难写而是难收尾帧格式、优先级分配、断线检测、多主站竞争能力这些都要重新设计而且和现成 PLC、伺服系统对接时对方根本不认你的私有帧。CanOpenNode 社区活跃度更高代码更新但它的工具链相对现代生成对象字典需要自己搭环境CANfestival 虽然看起来旧却有 Objdictgen 这个可视化的对象字典生成器拖拽就能定义索引和 PDO 映射对 STM32F1 这种小资源单片机的适配资料也足够多。唯一要忍耐的是它的工具链还停在 Python2 时代但只在生成字典时才用到生成出的.c/.h文件是标准 C复制进 Keil 或 GCC 工程就能编。综合从站资源占用、上手难度、资料丰富度F103 上选 CANfestival 是性价比最高的方案。3. STM32F1 上移植 CANfestival驱动接口、时基与最小工程3.1 先把源码按模块拆清楚再谈移植CANfestival 的源码可以大体分成三块协议核心、不同平台的驱动样例、以及生成对象字典的工具。移植时不需要把全部文件拖进工程只需要固定几只文件文件作用需要改动objdictdef.h定义 CO_Data、对象条目的数据结构否nmt.c从站状态机与 NMT 命令解析否pdo.cPDO 的发送与接收逻辑否sdo.cSDO 服务端处理否lifegrd.c心跳与节点保护否can.cCAN 驱动入口适配 STM32F1是timers.c协议栈的毫秒定时器是can.c里实际要实现的接口就两个canSend(Message *m)负责把协议栈构造好的帧发出去canDispatch(Message *m)是收到物理帧后交给协议栈的入口timers.c里要提供一个让TimeDispatch_Update()周期运行的时基。协议栈其余部分不需要动。把模块边界划清楚之后编译报错会少很多因为大部分错误都集中在数据结构定义不匹配或函数指针没接上。3.2 用 STM32F1 的 bxCAN 实现 canSend 发送接口STM32F1 的 bxCAN 支持 3 个发送邮箱发送前要检查邮箱状态。CANfestival 传给canSend的 Message 结构体里已经有cob_id、data、len、rtr四个字段直接映射到CanTxMsg即可。UNS8 canSend(Message *m) { CanTxMsg TxMsg; TxMsg.ExtId 0; TxMsg.IDE CAN_Id_Standard; // CANopen 默认标准帧 TxMsg.RTR m-rtr ? CAN_RTR_REMOTE : CAN_RTR_DATA; TxMsg.StdId m-cob_id; TxMsg.DLC m-len; memcpy(TxMsg.Data, m-data, m-len); if (CAN_Transmit(CAN1, TxMsg) CAN_TxStatus_Failed) { return 1; } return 0; }这个实现里有两个容易被忽略的点。第一CANopen 的这些通信对象地址都落在标准帧的 11 位 ID 范围内用标准帧就够了不要开扩展帧第二CAN_Transmit返回值只判断失败状态协议栈只看返回值是 0 还是非零零表示成功。实际工程里我会在返回失败前加一个错误计数发送失败次数持续增长时多半是总线被占满或没有终端电阻。3.3 接收中断与 canDispatch 入口从站收到 CAN 帧后应尽快把帧内容取走并解析否则 FIFO 溢出会丢帧导致 SDO 超时或者 PDO 数据跳变。典型写法如下void USB_LP_CAN1_RX0_IRQHandler(void) { CanRxMsg rx; CAN_Receive(CAN1, CAN_FIFO0, rx); Message m; m.cob_id rx.StdId; m.rtr (rx.RTR CAN_RTR_REMOTE) ? 1 : 0; m.len rx.DLC; memcpy(m.data, rx.Data, 8); canDispatch(m); }这里把CAN_Receive放在中断里直接执行是因为 bxCAN 接收 FIFO 只有 3 个槽位处理太慢必有丢帧。canDispatch内部会先按 COB-ID 判断帧类型NMT、SDO、PDO、心跳分别走不同处理函数因此中断函数里不要做任何业务判断把完整的 Message 交进去即可。需要注意memcpy虽然只拷 8 字节但如果应用里还开了其他高优先级中断要在 NVIC 里把 CAN 接收中断优先级安排合理。3.4 时基让协议栈的定时链表跑起来CANfestival 的 PDO 周期发送、心跳周期、SDO 超时都依赖一个非阻塞的毫秒时基。我一般用 TIM3 定时器配置成 1ms 或 10ms 中断每进一次中断调一次TimeDispatch_Update()。这个函数会遍历协议栈内部的定时链表把到期的定时器逐个执行。void TIM3_IRQHandler(void) { if (TIM_GetITStatus(TIM3, TIM_IT_Update) ! RESET) { TIM_ClearITPendingBit(TIM3, TIM_IT_Update); TimeDispatch_Update(); } }TimeDispatch_Update()的参数不绑定具体硬件定时器中断配成 1ms 就按 1ms 的时间基准驱动协议栈。不要在中断里做浮点运算或长耗时操作否则定时器抖动会让心跳周期不稳定主站可能误判从站离线。更不要用HAL_Delay去驱动它因为协议栈内部 SDO 分段传输的超时计算会被阻塞打断。3.5 上电初始化从 CAN 外设到 CANopen 协议栈初始化顺序影响节点上线后的行为我的常见做法是int main(void) { CAN_Init(500); // 波特率 500kbit/s Timer_Init(); initTimer(); canOpen(5, 0, 0, 0, objdict_Data); // 节点 ID 5 setNodeId(5); setState(Operational); // 调试阶段先强制进操作态 while (1) { // 主循环只做采集与业务逻辑 } }canOpen的第一个参数是节点 ID节点 ID 不能为 0也不能超过 127CANopen 的 COB-ID 计算都以它为基础比如节点 5 的生产 PDO 就是 0x185。调试时先setState(Operational)能立刻看到心跳和 PDO正式接入别人的主站网络时通常要等主站下发 NMT 启动命令此时不要自己去抢占主站职责。初始化里还要记得把 CAN_H、CAN_L 之间接 120 欧姆终端电阻总线两头各一个没有终端电阻时 SDO 访问经常时好时坏。4. 用 Objdictgen 配置对象字典在 STM32F1 上跑通 PDO 与 SDO4.1 Objdictgen 生成字典文件的工作流Objdictgen 是一个图形化工具操作流程是固定的先新建一个从站字典文件设置节点 ID、波特率然后在 0x2000 开始的制造商区域添加自定义对象类型可以选 uint8、int16、uint32 等再把需要周期传输的对象映射到一个或多个 TPDO 条目里保存为.dcf文件最后导出 C 文件。生成的objdict_xxx.c与objdict_xxx.h直接加入 STM32F1 工程替换默认字典文件即可。导出字典时有两点会直接影响后续调试。第一PDO 映射的默认传输类型如果要设成周期型要在对象 0x1800/0x1A00 里配置好生成后再手工改容易和 Objdictgen 对不上第二字典里定义的变量名例如objdict_Data要和工程 include 的一致换字典文件时最容易错的就是头文件里的宏定义不一致编译报错会指向结构体字段找不到。4.2 把 DHT11 温湿度采集结果写进对象字典前面说过应用层的数据最终都落在对象字典里。这里用一个常见的场景STM32F1 读取 DHT11 温湿度传感器把温度湿度写入 0x2000 和 0x2001然后通过 PDO 发出去。DHT11 是单总线器件读取时序由 STM32F1 的 GPIO 模拟读到的温度是整数湿度是整数百分比直接用 int16 存。#include objdict_xxx.h extern CO_Data objdict_Data; void dht_task(void) { if (dht11_read(temp, hum) 0) { INTEGER16 t temp; UNS8 h hum; setODentry(objdict_Data, 0x2000, 0x01, t, sizeof(t)); setODentry(objdict_Data, 0x2001, 0x01, h, sizeof(h)); } }setODentry是写字典的标准入口参数依次是协议栈数据指针、索引、子索引、值指针、值的长度。之所以要先取出来再写字典而不直接写objdict_Data的成员数组是因为对象字典内部可能存在字节序修正走setODentry可以保证 SDO 客户端读到的数据和写入时一致。反过来读取对象字典用getODentry拿到数据不要在业务线程里直接访问结构体成员否则换字典工具重新生成后这里很容易编译失败。4.3 PDO 发送周期上报温湿度对象字典写好了还需要让 PDO 周期地把数据送出去。CANfestival 的pdo.c会在TimeDispatch_Update()被调用时检查 PDO 定时器并在传输类型为周期型时自动发送。如果配置里没有自动发送也可以在应用代码里手动触发void send_temp_hum_pdo(void) { checkPDOEvent(objdict_Data); }checkPDOEvent会遍历所有 PDO 配置检查映射的对象是否有更新然后构造 CANopen 标准 PDO 帧并交给canSend发送。发送 COB-ID 由 0x1800 通信参数和节点 ID 计算而来例如节点 5 的 TPDO1 就是 0x185不需要在应用代码里拼 COB-ID。需要说明的是PDO 单帧最多 8 字节所以一个 PDO 最多映射 4 个 16 位数据如果要传 32 位转速值一个 PDO 就只能映射两个。4.4 PDO 接收电机控制字从总线到 PWM 输出如果说 PDO 发送是把设备状态推出去PDO 接收就是消费来自主站的控制数据。下面以控制一个直流电机为例主站通过 RPDO 下发目标转速和控制字STM32F1 的定时器 PWM 输出驱动 MOS 桥实现调速。接收到的 PDO 数据会自动写入对应的对象字典。UNS16 target_speed; UNS8 ctrl_word; void motor_control_task(void) { getODentry(objdict_Data, 0x2002, 0x01, target_speed, sizeof(target_speed)); getODentry(objdict_Data, 0x2003, 0x01, ctrl_word, sizeof(ctrl_word)); if (ctrl_word 0x01) { TIM_SetCompare1(TIM1, target_speed); } }CANfestival 的 PDO 接收解析在协议栈内部完成消费 PDO 数据自动写入对象字典应用层只需要用getODentry读取。这里要提醒的是RPDO 没有应答机制主站发完即不管因此从站单方面通信故障时不会立刻知道。需要可靠传输的启停类命令建议走 SDO功率类参数用 PDO 即可这和电机驱动场景是匹配的。4.5 用 SDO 读写从站参数配置心跳时间主站需要修改心跳时间或 PDO 映射时使用 SDO 写入对应对象。以修改从站心跳周期为 200ms 为例在 CAN 调试工具上发送发送 COB-ID 0x605数据 2B 17 10 00 C8 00 00 00这串数据的含义是0x605 是 SDO 客户端请求 COB-ID0x600节点 52B表示写 16 位长度的快速写入命令17 10是小端索引 0x101700是子索引 0C8 00是 200 的 little-endian 表示。从站回复 COB-ID 0x585数据60 17 10 00 00 00 00 00表示写入成功。理解这个字节布局对排查 SDO 问题非常关键很多线上故障其实是命令字或字节序写错了。5. 快速验证 CANopen 从站测试主站、SDO 探针与排错技巧5.1 用测试主站脚本快速验证协议栈是否通了CANfestival 源码里自带的测试主站脚本是一个现成的验证入口。常见做法是在 PC 上接一个 CAN 卡用 Python 脚本或通用 CAN 调试工具配合收发。把 STM32F1 从站的节点 ID 设为 5上电后先发一条 NMT 启动命令然后读从站对象字典 0x1000。能读到设备类型就说明协议栈核心链路是通的再读 0x2000 的数据就能确认对象字典映射是否配置错。整个验证过程不需要写应用层代码比对着示波器看波形更快。5.2 一个被踩得最多的坑主站没发启动从站 PDO 先飞了CANopen 从站在预操作态下是不允许发送 PDO 的但很多移植代码为了图验收方便把setState(Operational)写在初始化函数里这让从站上电就自动运行。坏处在多主站或者主站做安全控制时会直接破坏网络管理主站明明没有启动它它的 PDO 却一直在总线上占用带宽。正确做法是让从站停在预操作态等收到 0x000 的启动命令后再进入操作态例如在主循环里检查getState(objdict_Data) ! Operational时仅允许应用层处理心跳和 SDO。5.3 给对象字典加一个调试入口验证 PDO 链路如果从站在总线上能发心跳但 PDO 不刷新问题大概率不在协议栈而在 PDO 映射参数。可以临时在字典里加一个 0x2004 的调试计数器每发送一次 PDO 就通过setODentry累加然后用 SDO 实时读它。计数器不涨说明 PDO 压根没触发计数器涨而主站收不到才是 CAN 驱动发送侧的问题。把调试计数器映射到 0x2004用 SDO 循环读取主站读到的计数值会跟 PDO 发送次数严格一致不一致时再看 CAN 控制器 TEC/REC 错误寄存器链路问题基本能定位。本文还有配套的精品资源点击获取