STM32移植Canard实现UVCAN

关注

原创最新推荐文章于 2026-10-19 10:57:00 发布 758 阅读 AI 写同款· GEO 优化 ›

STM32移植Canard实现UVCAN协议源码技术分析

在现代嵌入式系统中，随着无人机、机器人和工业自动化设备的复杂度不断提升，传统的CAN通信方式逐渐暴露出开发效率低、扩展性差、跨平台兼容困难等问题。尽管经典CAN以其高可靠性和实时性长期占据主导地位，但面对“即插即用”、“自动识别节点”、“统一数据模型”等新需求，开发者迫切需要一种更智能、更结构化的通信方案。

正是在这样的背景下，UVCAN（原UAVCAN）应运而生——它不是对CAN物理层的替代，而是对其上层协议的一次深度重构。通过引入标准化的数据描述语言（DSDL）、服务调用机制与动态节点管理能力，UVCAN让原本“哑巴式”的CAN总线具备了自我描述和语义理解的能力。而 Canard 作为其官方轻量级C库实现，成为将这一先进协议落地到资源受限MCU的关键桥梁。

本文聚焦于如何在STM32平台上成功移植Canard并运行UVCAN协议，不局限于理论讲解，而是深入剖析从内存管理、CAN帧处理到应用层消息构造的完整链路，并结合实际代码揭示工程实践中那些容易被忽视的设计细节。

Canard：不只是一个协议栈

很多人初识Canard时会误以为它是一个完整的网络协议栈，但实际上它的定位非常精准： 一个无操作系统的、可嵌入的UVCAN协议处理引擎 。它不负责初始化硬件，也不参与任务调度，只专注于核心逻辑——把应用数据打包成符合UVCAN规范的CAN帧，或者反过来，将收到的CAN帧还原为结构化信息。

这种“中间件”式的架构设计带来了极高的灵活性。无论你使用裸机循环还是FreeRTOS，只要能提供定时滴答和CAN收发接口，就能驱动Canard工作。更重要的是，Canard采用静态内存池管理，完全避免了 malloc/free 带来的不确定性，这对于实时性要求严苛的应用至关重要。

我们来看一段典型的初始化代码：

static uint8_t canard_memory_pool[1024 * 4];
static CanardPoolAllocator allocator;
CanardInstance canard_instance;

void canard_setup(void) {
    allocator.memory_blocks = canard_memory_pool;
    allocator.block_size = CANARD_POOL_BLOCK_SIZE;
    allocator.capacity = sizeof(canard_memory_pool) / CANARD_POOL_BLOCK_SIZE;

    canardInit(&canard_instance,
               &allocator,
               127,
               onTransferReception,
               shouldAcceptTransfer,
               NULL);
}

这里有几个关键点值得深挖：

内存池大小的选择 ：4KB看似充裕，但在频繁传输大块数据（如固件更新）时仍可能耗尽。建议根据最大并发传输数估算所需空间。每个传输会话至少占用一个内存块，若分段过多或并发请求多，需相应扩大池子。
节点ID设置为127 ：这是临时做法。真正的产品应支持PnP（Plug-and-Play），即通过 uavcan.protocol.GetNodeInfo 服务动态分配ID。初始设为0表示未配置状态更为合理。
回调函数的作用域 ： onTransferReception 是整个协议交互的核心入口，所有接收到的有效消息都会在此汇聚；而 shouldAcceptTransfer 则用于过滤非法或无关的传输，提前丢弃可减轻CPU负担。

STM32上的CAN集成：不只是HAL封装

STM32系列MCU普遍内置bxCAN控制器，功能强大且稳定。然而，在对接Canard时，很多开发者只是简单地把HAL库的接收中断直接喂给 canardHandleRxFrame() ，却忽略了几个潜在陷阱。

首先看中断处理函数：

void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) {
    CanardFrame frame;
    CAN_RxHeaderTypeDef rx_header;

    if (HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &rx_header, frame.data) != HAL_OK) {
        return;
    }

    frame.extended_can_id = rx_header.StdId;
    frame.payload_size = rx_header.DLC;
    canardHandleRxFrame(&canard_instance, &frame, HAL_GetTick());
}

这段代码表面上没问题，但存在两个隐患：

时间戳精度不足 ： HAL_GetTick() 返回毫秒级时间，而UVCAN内部某些超时判断（如传输重传）依赖微秒级精度。如果系统滴答为1ms，则可能导致误判超时，进而引发不必要的重传或会话中断。解决方案是启用定时器配合 DWT CYCCNT 寄存器提供更高精度时间基准。
中断上下文执行开销过大 ： canardHandleRxFrame() 内部包含CRC校验、会话查找、内存分配等操作，耗时较长。若CAN负载较高，长时间占用中断可能导致其他外设响应延迟。理想做法是将接收到的帧放入环形缓冲区，由主循环或低优先级任务异步处理。

再来看发送环节：

int16_t canard_send_frame(const CanardFrame* frame, uint64_t timeout_usec) {
    CAN_TxHeaderTypeDef tx_header;
    uint32_t tx_mailbox;

    tx_header.StdId = frame->extended_can_id;
    tx_header.RTR = CAN_RTR_DATA;
    tx_header.IDE = CAN_ID_STD;
    tx_header.DLC = frame->payload_size;
    tx_header.TransmitGlobalTime = DISABLE;

    if (HAL_CAN_AddTxMessage(&hcan, &tx_header, (uint8_t*)frame->data, &tx_mailbox) != HAL_OK) {
        return -1;
    }

    while (HAL_CAN_IsTxMessagePending(&hcan, tx_mailbox)); // 等待发送完成

    return 0;
}

这个实现采用了 阻塞等待发送完成 的方式，虽然保证了帧顺序，但在高频率发送场景下会导致主线程卡顿。更优策略是采用非阻塞模式，利用TX中断通知机制，在 HAL_CAN_TxMailbox0CompleteCallback 中触发 canardSpin() 继续推送后续帧。

此外，关于CAN ID编码规则也需要特别注意：

CAN ID = (Message Type ID << 8) | Source Node ID

这决定了你在配置过滤器时不能只关注目标节点ID，还要覆盖所有可能用到的Port ID范围。例如，如果你要监听 NodeStatus （Port ID=0）和自定义传感器数据（Port ID=100），那么过滤器必须允许 StdId & 0xFF00 匹配这两个高位值。推荐使用 32位宽掩码模式 ，设置Filter Mask为 0xFE00 ，即可一次性捕获所有UVCAN标准帧。

数据建模的艺术：从位字段到语义表达

UVCAN最强大的地方在于其基于DSDL（Data Structure Description Language）的数据定义体系。每一个消息类型都有唯一的ID和清晰的字段语义，比如 uavcan.protocol.NodeStatus 不仅规定了5个字段的长度和顺序，还明确定义了每个枚举值的意义。

以下是一个典型的 NodeStatus 广播示例：

void broadcast_node_status(void) {
    static uint8_t transfer_id = 0;

    CanardTransfer transfer = {
        .timestamp_usec = 0,
        .priority = CanardPriorityNominal,
        .transfer_kind = CanardTransferKindBroadcast,
        .port_id = UAVCAN_PROTOCOL_NODESTATUS_PORT_ID,
        .remote_node_id = 0,
        .transfer_id = transfer_id++,
        .payload_size = 0,
        .payload = NULL
    };

    uint8_t payload[UAVCAN_PROTOCOL_NODESTATUS_MAX_SIZE] = {0};
    size_t offset = 0;

    canardEncodeScalar(payload, 32, &offset, &(uint32_t){1234});   // uptime_sec
    canardEncodeScalar(payload, 2,  &offset, &(uint8_t){0});       // health
    canardEncodeScalar(payload, 5,  &offset, &(uint8_t){5});       // mode
    canardEncodeScalar(payload, 7,  &offset, &(uint8_t){0});       // sub_mode
    canardEncodeScalar(payload, 48, &offset, &(uint64_t){123});    // vendor_specific

    transfer.payload_size = (offset + 7) / 8;
    transfer.payload = payload;

    canardBroadcast(&canard_instance, &transfer);
}

这段代码展示了UVCAN“紧凑编码”的精髓：按位写入，最小化带宽占用。但同时也带来调试难题——原始CAN报文无法直观解读。这时就需要借助开源工具链辅助开发。

比如使用 pyuavcan 可以通过Python脚本监听总线：

import pyuavcan
node = pyuavcan.make_node('socket://can0')
node.start()

status_sub = node.make_subscriber('uavcan.protocol.NodeStatus')
async def print_status():
    async for msg, info in status_sub:
        print(f"Node {info.transfer.source_node_id}: uptime={msg.uptime_sec}s, mode={msg.mode}")

import asyncio
asyncio.run(print_status())

一旦看到屏幕上清晰输出“Node 42: uptime=1234s, mode=Operational”，你就知道这套系统真的“活”起来了。