3、CANopen协议栈移植：从零搭建你的运动控制通信骨架

说实话，协议栈移植这件事，很多工程师一听就头大。我刚开始做的时候也一样，总觉得这是个大工程。但后来我发现，只要选对了开源协议栈，再配合STM32的HAL库，这事儿其实没那么玄乎。今天我就带你走一遍完整的移植流程，把那些坑都提前给你指出来。

3.1 开源协议栈怎么选？Lely还是CanOpenNode？

目前主流的开源CANopen协议栈就两个：Lely和CanOpenNode。我两个都用过，说说我的真实感受。

我个人习惯用CanOpenNode。为什么？说白了，它更「纯粹」。纯C实现，没有C++那些复杂的继承和多态，在STM32上编译出来也就十几KB的Flash占用。我在一个F103的项目里，整个协议栈跑起来只用了不到8KB的RAM，这你受得了吗？

3.2 STM32 HAL库适配：让协议栈和硬件「对上话」

协议栈移植的核心，说白了就是让协议栈知道怎么用你的硬件。CanOpenNode抽象了三个底层接口：CAN发送、CAN接收、定时器。我们只需要把HAL库的函数填进去就行。

先看CAN发送接口。CanOpenNode里有个函数叫canSend()，我们需要实现它：

// 在 CO_driver_target.h 中实现
static inline int8_t canSend(CAN_TypeDef *CANx, CO_CANtx_t *buffer) {
    CAN_TxHeaderTypeDef txHeader;
    uint32_t txMailbox;
    
    txHeader.StdId = buffer->ident;
    txHeader.IDE = CAN_ID_STD;
    txHeader.RTR = CAN_RTR_DATA;
    txHeader.DLC = buffer->DLC;
    txHeader.TransmitGlobalTime = DISABLE;
    
    // 这里要注意：HAL库的发送是阻塞的，但协议栈要求非阻塞
    // 我当初在这里卡了两天...
    if (HAL_CAN_AddTxMessage(CANx, &txHeader, buffer->data, &txMailbox) != HAL_OK) {
        return -1;
    }
    return 0;
}

嗯，这里要注意。HAL库的HAL_CAN_AddTxMessage其实是把报文放到硬件发送邮箱里，然后立即返回。所以它本质上是非阻塞的，符合协议栈的要求。但有个坑：如果三个发送邮箱都满了，这个函数会返回HAL_BUSY。我建议你在调用前检查一下邮箱状态，或者干脆用DMA方式。

再看CAN接收。协议栈会注册一个回调函数，当CAN报文到达时，我们需要把数据喂给协议栈：

// 在 CAN 接收中断中
void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) {
    CAN_RxHeaderTypeDef rxHeader;
    uint8_t rxData[8];
    
    if (HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &rxHeader, rxData) == HAL_OK) {
        CO_CANrxMsg_t msg;
        msg.ident = rxHeader.StdId;
        msg.DLC = rxHeader.DLC;
        memcpy(msg.data, rxData, 8);
        
        // 喂给协议栈
        CO_CANrxMsgProcess(&CO_OD, &msg);
    }
}

3.3 时钟与定时器配置：心跳的「节拍器」

CANopen协议栈依赖一个1ms的定时器中断。这个定时器用来驱动状态机、处理心跳报文、管理同步帧等。说白了，它就是整个协议栈的「心跳」。

用STM32的通用定时器来实现，我一般选TIM3或TIM4，因为它们不占用高级定时器资源：

// 定时器初始化，产生1ms中断
void TIM3_Init(void) {
    TIM_HandleTypeDef htim3;
    htim3.Instance = TIM3;
    htim3.Init.Prescaler = 72 - 1;      // 72MHz / 72 = 1MHz
    htim3.Init.Period = 1000 - 1;       // 1MHz / 1000 = 1kHz (1ms)
    htim3.Init.CounterMode = TIM_COUNTERMODE_UP;
    htim3.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
    HAL_TIM_Base_Init(&htim3);
    HAL_TIM_Base_Start_IT(&htim3);
}

// 定时器中断回调
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) {
    if (htim->Instance == TIM3) {
        // 喂给协议栈的定时器处理函数
        CO_TimerIRQHandler();
    }
}

你可能会问：为什么一定要1ms？其实CANopen规范里并没有强制要求，但几乎所有实现都默认1ms。为什么？因为心跳报文的精度要求是±1ms，如果你用10ms的定时器，心跳抖动会很大，主站可能会认为节点离线了。

3.4 心跳报文实现：让主站知道你还活着

心跳报文是CANopen里最基础也最重要的功能。它就像一个「保活」信号，告诉主站：「我还活着，一切正常。」

在CanOpenNode里，心跳报文的实现其实很简单。我们只需要在对象字典里配置好心跳生产者时间：

// 在对象字典中配置心跳生产者时间
// 索引 0x1017，子索引 0x00
// 单位：ms，0表示禁止心跳
#define HEARTBEAT_PRODUCER_TIME_MS  1000  // 1秒发送一次

// 协议栈会自动在定时器中断中处理心跳发送
// 我们只需要在初始化时设置好参数
void Heartbeat_Init(void) {
    // 设置心跳生产者时间
    CO_OD_setUint16(&CO_OD, 0x1017, 0, HEARTBEAT_PRODUCER_TIME_MS);
    
    // 启动心跳
    CO_NMT_StartHeartbeat(&CO_OD);
}

心跳报文的COB-ID是固定的：0x700 + 节点ID。比如节点ID是1，心跳报文的ID就是0x701。报文数据只有一个字节，表示节点的当前状态：

你想想看，如果主站连续3个心跳周期没收到报文，它就会认为节点离线了。所以心跳时间的设置要合理。我一般设1秒，既不会太频繁占用总线，也不会让主站等太久。

3.5 整体架构：一张图看懂

说了这么多，我们来画一张图，把整个协议栈的架构理清楚：

从这张图可以看得很清楚：我们只需要关注驱动层那三个接口的实现，剩下的协议栈逻辑都是现成的。说白了，移植工作就是「填空」——把HAL库的函数填到协议栈预留的接口里。

嗯，到这里，协议栈移植的核心内容就讲完了。你可能会觉得内容有点多，但实际操作起来，只要按部就班地配置好定时器、实现好CAN收发接口，整个移植过程其实用不了半天。我第一个项目移植的时候，从下载源码到跑通心跳报文，总共花了大概3个小时。当然，中间也踩了几个坑，但那些坑我都帮你填平了。

记住一句话：协议栈移植不是造轮子，而是把轮子装到你的车上。选对工具，理解接口，剩下的就是耐心调试了。