CANfestival移植实战：STM32F1轻松实现CANopen从站节点

简介：基于CANfestival的CANopen协议在STM32F1系列单片机上的实现，是一份面向嵌入式开发者的完整工程资料，适合自动化、电子信息、通信工程等专业用于毕业设计、课程设计与项目初期开发。包内不仅包含协议栈移植的完整源码、详细配置文档，还提供了can_monitor、CANopen_Slave、Demo等多个可编译运行的示例工程，能够帮助读者快速理解CANopen对象字典、主从站通信、PDO/SDO等核心机制，并在此基础上进行功能修改与二次开发。压缩包共932个文件，以.h/.c源码、.uvprojx工程文件为主，同时包含.map/.axf等编译输出、.bat辅助脚本、.pdf/.doc说明文档等，整体约28.8MB，目录结构清晰，便于按模块查阅。目前已有140人学习下载，源码均经过测试运行成功，附带的数据资料可支撑从协议原理学习到整体项目落地，尤其适合有单片机基础、希望深入掌握CANopen协议栈应用的读者参考。

1. 为什么基于 CANfestival 实现 STM32F1 的 CANopen 节点

CANopen 是工业设备联网的应用层协议，CANfestival 是最常用的开源 CANopen 协议栈，STM32F1 是价格便宜、资料最全的单片机平台。三者合起来，就是让一个裸机 MCU 快速变成规范的 CANopen 从站。

拿到“源码+详细文档+全部数据资料”压缩包的人，第一反应往往是打开源码找 main.c，结果被 object dictionary 那一大坨结构体劝退。其实压缩包里最该先看的是 EDS 文件和移植文档，源码反而要放到最后。

下面按我实际移植的顺序讲：先看清协议骨架，再把 F1 的 bxCAN 和定时器接进去，最后用 candump 验证。想批量做标准从站的设备厂商，和要快速看懂 0x1800、0x1A00 索引的工程师，都能从中找到对应的那一段。

2. CANopen 协议详解：从 COB-ID 到 CANfestival 源码的层级结构

2.1 一张 COB-ID 表看懂 CANopen 的通信对象

CANopen 不重新定义物理层，它规定的是“标准帧的 11 位标识符该怎么用”。整条总线上只有 2048 个标准 COB-ID，CANopen 还要用 function code 和 node ID 再切一刀：高 4 位表示报文种类，低 7 位表示节点地址。这样一来，节点地址一旦确定，心跳帧号、SDO 帧号、PDO 帧号全部被算出来，不需要任何动态分配。这也是 CANopen 和 Modbus RTU 这类按地址轮询的协议之间最大的区别——抓一帧就知道是谁发的、干什么用的。

node ID 范围是 1 到 127，0 保留给广播。以节点 5 为例：心跳帧是 0x705，SDO 收发分别是 0x605 和 0x585，TPDO1 是 0x185。实际抓帧时，看到 0x585 开头的帧就知道是 5 号从站在回 SDO，看到 0x185 就是在发过程数据。这里有个容易被忽略的点：CAN 仲裁优先级就是 COB-ID 数值本身，所以 NMT 的 0x000 永远比 PDO 先发出去，紧急报文的 0x080 也比普通 PDO 优先级高。设计网络时不要把 COB-ID 和“数据重要程度”混为一谈。

注意：CANopen 的 COB-ID 是协议语义，不是用户随便分配的地址。改 PDO 的 COB-ID 要去 0x1800/0x1400 通信参数段里改，不是直接改帧号。

2.2 CANfestival 源码分层：协议核、对象字典、硬件驱动

CANfestival 整个源码工程可以切成三层。底层是驱动，也就是移植时要写的 canSend、canDispatch、setTimer、getElapsedTime 这几个函数，它们和芯片绑死。中间是对象字典，由 ObjDictEdit 工具为一个节点单独生成，通常叫 objdict.c 和 objdict.h，里面是 const 结构体数组和索引函数，记录每个索引号对应的变量地址、权限和数据类型。最上层是协议核心，nmtSlave.c、sdo.c、pdo.c、emcy.c、sync.c、timer.c 这一组文件共同工作，运行时按 COB-ID 把收到的帧分发到对应模块处理。

消息流是单向的：CAN 接收中断里把硬件寄存器内容填进 Message 结构体，然后调用 canDispatch 交给协议栈；协议栈分析出这是 SDO 请求还是 NMT 命令，再更新对象字典或回调用户函数。发送方向相反，业务代码调用 sendPDO、sendEMCY 这类接口，协议栈组好 Message，最后统一走 canSend 发出去。这样分层的结果是：换芯片只需要重写底层那四个函数，对象字典和协议核心一行都不用动。这也是判断一个移植工程质量的标准——如果移植者的 vendor 目录之外的文件被改得面目全非，说明硬件逻辑已经泄漏进协议栈了，后续升级会很痛苦。

2.3 SDO 读写一条数据的帧格式

SDO 用来按索引读写对象字典，适合配置参数、分量不大、频率不高的场合。以读写 0x2000 子索引 1 的一个字节为例，主站向 0x600+nodeID 发读请求：

读请求 0x600+nodeID: 40 00 20 01 00 00 00 00 读响应 0x580+nodeID: 4F 00 20 01 2A 00 00 00

第一字节 0x40 是“客户端发起读请求”，0x4F 表示“服务端响应，数据长度 1 字节”；第 2、3 字节是索引，小端序，0x2000 就是「00 20」；第 4 字节是子索引；后面 4 字节是数据。写请求的编码也规律：0x2F 是快速写 1 字节，0x2B 是写 2 字节，0x23 是写 4 字节；写入成功，从站回一帧 0x60 开头的确认。如果响应帧第一字节是 0x80，说明读写被否决，后面 4 字节是错误码：0x06020000 表示“对象不存在”，0x06090011 表示“子索引不存在”，0x05040000 表示“SDO 超时”。记住这几个码，抓帧排错基本不用翻文档。

3. STM32F1 移植 CANfestival：bxCAN 驱动、1ms 定时器与源码接线

3.1 移植要接的四个口

打开 CANfestival 的 include 目录和 canfestival.c 就能看到，协议栈对硬件只提出四个要求。canSend 把一个 Message 结构体发出去并返回是否成功；canDispatch 接收一个 Message 并处理，调用来源基本固定在 CAN 接收中断里；setTimer 和 getElapsedTime 是时间服务，心跳周期、事件型 PDO 的抑制时间、SDO 超时全依赖它们。此外还要一个毫秒级硬件节拍，通常用一个定时器中断维护。Message 结构体是标准帧的完整映射：

typedef struct { UNS16 cob_id; /* 11 位标准帧 COB-ID */ UNS8 rtr; /* 1 为远程帧 */ UNS8 len; /* DLC，0..8 */ UNS8 data[8]; /* 帧数据 */ } Message;

canSend 返回 0 表示发送失败，协议栈会据此做重传或错误记录。时间接口的语义是：setTimer 被协议栈调用时传入“还差多少毫秒到期”，getElapsedTime 返回自上次调用以来过去了几毫秒。裸机移植时我用一个 volatile 变量在 1ms 中断里累加，setTimer 记录到期时刻，到时由中断调用 TimeDispatch。这里有个常见误区：有人只在主循环里调 TimeDispatch，心跳会整体漂移，主站消费心跳的超时判断时好时坏。

3.2 bxCAN 收发驱动与滤波配置

F1 的 CAN 控制器是 bxCAN，标准外设库封得比较薄，收发基本就是配置结构体加两个函数。先初始化 GPIO，PA11 是 RX，PA12 是 TX；需要挪脚时可以重映射到 PB8/PB9。

void can_hw_init(void) { GPIO_InitTypeDef gpio; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_AFIO, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_CAN1, ENABLE); gpio.GPIO_Pin = GPIO_Pin_11; /* RX，空闲时为高电平 */ gpio.GPIO_Mode = GPIO_Mode_IPU; gpio.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &gpio); gpio.GPIO_Pin = GPIO_Pin_12; /* TX */ gpio.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_Init(GPIOA, &gpio); }

这里没有使能重映射，所以保持 PA11/PA12 默认脚位。RX 用上拉输入，和 CAN 隐性高电平一致；TX 用复用推挽。接着配置波特率、模式、滤波和接收中断：

void canopen_can_init(void) { CAN_InitTypeDef can; CAN_FilterInitTypeDef f; can.CAN_TTCM = DISABLE; can.CAN_ABOM = ENABLE; /* 总线关闭后自动恢复 */ can.CAN_AWUM = ENABLE; can.CAN_NART = DISABLE; /* 开启自动重发 */ can.CAN_RFLM = DISABLE; can.CAN_TXFP = DISABLE; can.CAN_Mode = CAN_Mode_Normal; can.CAN_SJW = CAN_SJW_1tq; can.CAN_BS1 = CAN_BS1_8tq; can.CAN_BS2 = CAN_BS2_3tq; can.CAN_Prescaler = 6; /* 500 kbit/s，参数见下方表格 */ CAN_Init(CAN1, &can); f.CAN_FilterMode = CAN_FilterMode_IdMask; /* 掩码模式 */ f.CAN_FilterScale = CAN_FilterScale_32bit; f.CAN_FilterIdHigh = 0x0000; f.CAN_FilterIdLow = 0x0000; /* 先不过滤 */ f.CAN_FilterMaskIdHigh = 0x0000; f.CAN_FilterMaskIdLow = 0x0000; /* 掩码全 0，接收所有标准帧 */ f.CAN_FilterFIFOAssignment = CAN_FIFO0; f.CAN_FilterActivation = ENABLE; CAN_FilterInit(&f); CAN_ITConfig(CAN1, CAN_IT_FMP0, ENABLE); NVIC_EnableIRQ(USB_LP_CAN1_RX0_IRQn); /* F103 的 CAN1 接收中断 */ }

标准外设库写入 BRP 寄存器时会自动减一，所以 CAN_Prescaler 可以直接当分频系数用。位时间等于 1（同步段）加 BS1 加 BS2，采样点是 (1+BS1)/总 Tq 数，BS1 里已经包含了传播段。公式展开就是：

波特率 = APB1 / (CAN_Prescaler × (1 + BS1_Tq + BS2_Tq))

APB1 为 36MHz 时常见波特率的配置：

接收中断里把硬件帧转成 Message 后直接交给 canDispatch，不要攒批、不要在主循环里统一处理，否则 FMP0 标志还挂着你又进了一次中断，低负载下也能丢帧：

void USB_LP_CAN1_RX0_IRQHandler(void) { CanRxMsg rx; Message m; if (CAN_GetITStatus(CAN1, CAN_IT_FMP0) == SET) { CAN_Receive(CAN1, CAN_FIFO0, &rx); m.cob_id = rx.StdId; m.rtr = rx.RTR == CAN_RTR_Remote ? 1 : 0; m.len = rx.DLC; for (int i = 0; i < 8; i++) m.data[i] = rx.Data[i]; canDispatch(&m); /* 协议栈入口，只在中断里调用 */ } }

发送方向实现 canSend。注意返回值要和硬件状态一致：三个发送邮箱都满时 CAN_Transmit 返回 CAN_TxStatus_NoMailBox，这时返回 0，协议栈才知道没发出去。

UNS8 canSend(Message *m) { CanTxMsg tx; tx.StdId = m->cob_id; tx.IDE = CAN_Id_Standard; tx.RTR = m->rtr ? CAN_RTR_Remote : CAN_RTR_Data; tx.DLC = m->len; for (int i = 0; i < 8; i++) tx.Data[i] = m->data[i]; return CAN_Transmit(CAN1, &tx) == CAN_TxStatus_Ok ? 1 : 0; }

3.3 1ms 节拍怎么喂 TimeDispatch

时间服务直接决定心跳和事件型 PDO 是否准时。用 TIM3 做一个 1ms 中断，中断里累加 tick，并调用协议栈的 TimeDispatch 处理到期定时器：

void TIM3_IRQHandler(void) { if (TIM_GetITStatus(TIM3, TIM_IT_Update) != RESET) { TIM_ClearITPendingBit(TIM3, TIM_IT_Update); tick_count++; /* 供 getElapsedTime 计算差值 */ TimeDispatch(); /* 到期定时器回调 */ } }

setTimer 登记的是“距到期的毫秒数”，到期后由 TimeDispatch 触发回调。我的建议是 TimeDispatch 放中断里没问题，因为它是查表加回调，但回调里不要做打印、长延时这类重活。另一个容易踩的坑是 tick 溢出：getElapsedTime 用无符号减法算差值，只要两次调用的间隔小于 65535ms 就不会出错，SDO 段超时是毫秒级，这个约束够用。

3.4 工程组织：嵌入式协议栈源码怎么进编译

一个最小从站工程里，协议栈需要编译的只有 timer.c、sdo.c、pdo.c、nmtSlave.c、emcy.c、sync.c 这几个核心文件，节点自身的 objdict.c，加上你手写的 can_drv.c 和 time_drv.c。lss.c 在需要动态修改节点号时才编进来，从站出厂后节点 ID 固定就不编它，能省一部分代码空间。头文件路径要同时包含 include 目录和你的端口目录。对象字典是 const 大结构体，编译后进 .rodata，占几 KB，F103C8 的 64KB flash 完全够用；如果开了完整调试符号倒是更像内存不够，别把这两件事混在一起判断。

4. 对象字典与 EDS：把单片机变量配置成 CANopen 参数

4.1 ObjDictEdit 生成的产物与 EDS 的用途

对象字典就是每个 CANopen 节点的“通信参数加业务数据”总表，索引号从 0x1000 到 0x5FFF 各有分工。CANfestival 配套一个图形工具 ObjDictEdit，它读入 EDS 文件，输出 objdict.c、objdict.h 和一份配置文件。EDS 本身是文本文件，主站软件靠它知道这个从站有哪些对象、支持什么映射、默认波特率多少。所以 EDS 不只是文档，它是从站对外的“身份证”，量产前一定要和固件里实际烧进去的对象字典保持一致。拿到压缩包时，正常顺序是：先打开 EDS 看对象表，再打开文档看硬件接口说明，最后才碰源码——直接看源码反而最容易迷路。

4.2 PDO 映射与通信参数段怎么改

PDO 是过程数据通道，一帧最多 8 字节，没有 SDO 那些协议开销。改 PDO 要同时动三段：通信参数段决定 COB-ID 和触发方式，映射参数段决定“这一帧里装哪几个对象”，被映射的对象本身还得存在。例如把 0x2000 子索引 1 的一个字节放进 TPDO1：

• 0x1800 子索引 1：COB-ID，默认 0x180 + nodeID，最高位置 1 表示禁用该 PDO
• 0x1800 子索引 2：传输类型，1 表示事件触发，2 到 240 表示每 N 个 SYNC 发一帧，255 表示同步非周期
• 0x1A00 子索引 1：第一个映射项，写入 0x20000108，高 16 位是索引，中间 8 位是子索引，低 8 位是位长度

映射项 0x20000108 的意思是“索引 0x2000、子索引 0x01、长度 8 位”。一个 PDO 可以连续映射 8 个对象，只要总位数不超过 64。修改映射必须在 Pre-operational 状态下进行，改完还要往 0x1010 子索引 1 写“save”关键字，配置才会存进非易失区，否则掉电全丢。

提示：事件触发型 PDO 的 0x1800 子索引 5 是事件时间，单位 1ms，设成 1 会让总线在数据频繁变化时被打满。

4.3 节点 ID、心跳与波特率：开局定死的三个参数

节点 ID 在 CANfestival 里通常是一个宏，也可以上电时从拨码开关或 EEPROM 读出来再传给协议栈初始化入口。上电第一帧必须是 boot-up，也就是 0x700+nodeID 上一个 0x00，主站没看到这帧，后面命令全是白搭。心跳周期在 0x1017，单位毫秒，从站建议 100ms 一跳；主站侧消费心跳配置在 0x1016。波特率要硬件初始化前固定，全网络一致，千万不要让从站启动时自动扫描波特率，那会让参数下发变得不可控。还有一个量产姿势：部分 F1 型号的片上 bootloader 支持 CAN 下载固件，把 0x1010/0x1011 的保存与恢复默认命令接到 CAN 升级入口，相当于给从站开了一条远程维护通道，前提是 boot 程序里也得带一个最小的 CANopen 协议栈。

4.4 把业务变量挂进对象字典

业务数据进对象字典，简单做法是定义在 0x2000～0x5FFF 厂商区，让生成的对象字典结构体把指针指过去。运行时尽量不直接访问结构体字段，因为后续可能加访问钩子。生成的 objdict 源码里提供了一对本地访问函数：

UNS8 v = OD_ReadLocalDict(0x2000, 1); /* 读回本节点 0x2000:01 */ UNS8 w = 0x2A; OD_WriteLocalDict(0x2000, 1, &w, sizeof(w)); /* 写入，SDO 立即可见 */

OD_ReadLocalDict 参数是索引和子索引，OD_WriteLocalDict 多一个数据指针和长度，这两条路径会绕过协议栈直接改对象字典，适合在裸机业务代码里用。数据改完还要不要通知协议栈？SDO 读的时候直接查对象字典，不用通知；如果这个对象被映射进了 PDO，并且是事件触发型，那你需要主动调用 sendPDO 推一帧，老数据挂在总线上会让主站以为数值一直没变。

5. 联调验证 CANopen 节点：candump 抓帧与三处容易翻车的细节

5.1 先抓 boot-up，再跑最小主站验证

从站上电后不会主动发数据，所以验证的第一步是抓 boot-up 帧。在 Linux 工控机上执行candump can0 -n 10，如果节点 ID 是 5，应该能看到705 [1] 00。这一帧说明节点已经进入 Pre-operational，SDO 通道就绪。接着用cansend can0 605#2F0020012A000000写一个字节到 0x2000:01，然后在 0x585 上等60 00 20 01开头的写确认。两条命令都通过，说明驱动、对象字典和 SDO 三个环节是通的。再往后就是加载 EDS 用 python-can 加 canopen 库把节点切进 Operational，心跳帧从 boot-up 开始每 100ms 出现一次，PDO 这时候才开始流动。

5.2 三处容易翻车的细节

第一处，波特率不一致的典型现象是“什么帧都没有”。此时看 F1 的 ESR 寄存器比猜有效：TEC 发送错误计数持续上涨，基本就是波特率错、线没接对或终端电阻缺失。第二处，验证环境的终端电阻只在总线两端各放一个 120Ω，别在中间每个节点都焊，那会把总线阻抗拉垮。第三处，canDispatch 和 TimeDispatch 都在中断上下文执行，回调里出现打印或长延时，SDO 分段传输就会超时，主站会看到 0x05040000。把 0x80 响应帧后 4 字节错误码映射成文本打出来，是后期排错最划算的一笔投入。

本文还有配套的精品资源，点击获取