3. CANopenNode源码结构解析：从目录到移植接口

好，咱们进入第三章。这一章我打算带你把CANopenNode的源码翻个底朝天。说实话，我第一次打开这个库的时候，也被它的目录结构吓了一跳——文件不少，命名也很有“欧洲风格”。但别怕，摸清楚规律之后，你会发现它其实非常工整。

咱们的目标很明确：搞清楚每个文件夹是干嘛的，每个核心头文件管什么，以及——最关键的是——移植接口长什么样。你想想看，如果连源码结构都不清楚，后面怎么改？怎么调？

3.1 源码目录结构：一张地图走天下

先看整体布局。CANopenNode的源码目录，我习惯把它分成三层：核心层、驱动层、应用层。下面这张SVG图能帮你快速建立全局印象。

从图上你能看到，核心层是CANopenNode的心脏，所有协议逻辑都在这里。而驱动层，说白了就是让你去填的“坑”——把CAN收发器、定时器、中断这些硬件操作塞进去。

3.2 核心文件功能：每个头文件都不是白给的

核心层里文件很多，但真正让你天天打交道的，就那么几个。我按重要程度排个序，咱们逐个过。

3.2.1 CO_driver.h — 移植的“命门”

这个文件，是整个库的硬件抽象层。它不实现任何协议，只定义了一堆宏和函数接口。比如：

• CAN收发：CO_CANsend()、CO_CANreceive()
• 定时器：CO_TIMER_GET() 获取当前时间戳
• 临界区保护：CO_LOCK_ENTER()、CO_LOCK_LEAVE()
• 内存操作：CO_memcpy()、CO_memset()

嗯，这里要注意：CO_driver.h 里很多宏是 弱定义 的，你可以直接在 CO_driver_target.h 里重新定义来覆盖。我曾经在一个项目里忘了重定义 CO_TIMER_GET，结果默认用了库里的空实现，整个NMT心跳都乱了。排查了整整一个下午……

3.2.2 CO_SDO.h / CO_SDO.c — 对象字典的“快递员”

SDO（Service Data Object）用于访问对象字典。它走的是“确认服务”——发一个请求，等一个应答。适合配置参数、下载固件这种需要可靠传输的场景。

核心函数就两个：

• CO_SDO_init() — 初始化SDO服务器
• CO_SDO_process() — 在主循环中轮询，处理接收到的SDO请求

你想想看，如果主循环里忘了调 CO_SDO_process()，那上位机发过来的配置指令就永远没人理。我见过有新手把SDO处理放在定时器中断里，结果数据错乱——因为SDO协议本身是有状态机的，中断里处理容易破坏状态一致性。

3.2.3 CO_PDO.h / CO_PDO.c — 实时数据的“高速公路”

PDO（Process Data Object）走的是“生产者-消费者”模式，不需要应答。一个节点发，其他节点收，效率极高。适合传输实时控制数据，比如电机转速、传感器值。

PDO的配置藏在对象字典里（索引0x1400-0x1B00），你不需要直接调用PDO的函数。库会在 CO_process() 里自动处理。但你要理解它的映射关系：

3.2.4 其他核心文件一览

剩下的文件，咱们快速过一遍，知道它们管什么就行：

• CO_NMT.h/c — 网络管理。处理启动、停止、预操作状态切换。每个从站必须实现。
• CO_EMCY.h/c — 紧急报文。发生故障时主动发送，比如过流、过热。
• CO_LSS.h/c — 层设置服务。用于动态修改节点ID和波特率，调试时很有用。
• CO_SYNC.h/c — 同步报文。主站发SYNC，所有从站同时采样或输出。
• CO_TIME.h/c — 时间戳协议。用于时钟同步，精度要求高的场合才用。

3.3 移植接口分析：把CANopenNode“粘”到你的MCU上

移植，说白了就是让CANopenNode知道：你的CAN控制器怎么初始化？怎么发数据？定时器怎么读？临界区怎么保护？

所有需要你实现的东西，都集中在 两个文件 里：

1. CO_driver_target.h — 宏定义和类型重定义
2. CO_driver.c（或你自己命名的驱动文件）— 函数实现

下面这张表，是我总结的“移植清单”，你照着做就行：

举个例子，STM32F4上 CO_CANsend() 的典型实现：

int8_t CO_CANsend(CO_CANmodule_t *CANmodule, CO_CANtx_t *buffer) {
    CAN_TypeDef *Instance = (CAN_TypeDef *)CANmodule->CANptr;
    uint32_t tx_mailbox;

    // 检查是否有空邮箱
    if ((Instance->TSR & CAN_TSR_TME0) == 0) {
        return -1;  // 没有空邮箱，返回错误
    }

    // 计算邮箱编号
    tx_mailbox = (Instance->TSR & CAN_TSR_CODE) >> 24;

    // 填充发送邮箱寄存器
    Instance->sTxMailBox[tx_mailbox].TIR = (buffer->ident << 21) | (buffer->IDE << 2);
    Instance->sTxMailBox[tx_mailbox].TDTR = buffer->DLC;
    Instance->sTxMailBox[tx_mailbox].TDLR = buffer->data[0] | (buffer->data[1] << 8) | (buffer->data[2] << 16) | (buffer->data[3] << 24);
    Instance->sTxMailBox[tx_mailbox].TDHR = buffer->data[4] | (buffer->data[5] << 8) | (buffer->data[6] << 16) | (buffer->data[7] << 24);

    // 请求发送
    Instance->sTxMailBox[tx_mailbox].TIR |= CAN_TI0R_TXRQ;

    return 0;
}

3.4 移植后的验证：怎么知道移植对了？

移植完别急着写应用。先跑一个“最小系统”验证：

1. 上电后，从站自动发送 Boot-up报文（COB-ID = 0x700 + NodeID，数据为0）。
2. 主站发NMT启动命令（COB-ID = 0x000，数据 = 0x01 0x05），从站进入操作状态。
3. 从站开始周期性发送 心跳报文（COB-ID = 0x700 + NodeID，数据为状态值）。

如果这三个报文都能在CAN总线上抓到，恭喜你，移植成功了！