GD32VF103的CAN通信实战解析

基于GD32VF103的CAN总线通信测试技术解析

在工业控制和智能设备开发中，稳定可靠的通信往往是系统成败的关键。当多个电机、传感器或控制器需要协同工作时，传统的UART或SPI往往力不从心——要么距离受限，要么抗干扰能力弱。这时候，CAN总线的价值就凸显出来了。

作为一款诞生于汽车电子领域的串行协议，CAN凭借其多主架构、高鲁棒性和灵活的报文机制，在PLC、机器人、电动车电控等领域持续发挥着重要作用。而随着国产RISC-V芯片的崛起，如何在新兴平台上高效实现CAN通信，成为许多工程师关注的问题。

GD32VF103正是这样一个值得关注的平台。它由兆易创新推出，基于平头哥Bouffalo BL系列兼容的RISC-V内核，不仅主频高达108MHz，还集成了包括CAN、USB、ADC等在内的丰富外设资源。更重要的是，它的引脚与STM32F1系列高度兼容，使得原有项目迁移变得相对容易。

本文将围绕一个典型的测试工程 gd32vf_can_test0.zip 展开，深入剖析GD32VF103上CAN模块的实际配置逻辑、常见陷阱及调试技巧，帮助开发者快速构建可信赖的CAN通信链路。

---

我们先来看一个最基础但极易出错的问题： 为什么初始化后CAN无法收发数据？

答案往往藏在三个关键步骤里——时钟使能、GPIO复用配置和波特率参数设置。任何一个环节疏漏，都会导致整个通信链路“静默”。

以PB8（CAN_RX）和PB9（CAN_TX）为例，这两个引脚必须正确配置为复用功能。不同于某些MCU默认开启AF模式，GD32VF103需要显式地打开GPIO时钟，并分别设置TX为推挽输出、RX为上拉输入：

void can_gpio_config(void) {
    rcu_periph_clock_enable(RCU_GPIOB);

    gpio_init(GPIOB, GPIO_MODE_AF_PP,  GPIO_OSPEED_50MHZ, GPIO_PIN_9);  // TX
    gpio_init(GPIOB, GPIO_MODE_IPU,   GPIO_OSPEED_50MHZ, GPIO_PIN_8);   // RX
}

这里特别注意RX端使用了内部上拉（IPU），这是为了防止浮空输入造成误触发。虽然外部收发器通常也有偏置电阻，但在板级调试阶段加上这道保险是值得的。

接下来是CAN控制器本身的初始化。这个过程的核心在于位定时参数的计算。假设APB1总线运行在72MHz，我们要配置成500kbps的波特率，就需要合理分配预分频器（prescaler）、同步段（SJW）、时间段1（BS1）和时间段2（BS2）。

一个常见的组合如下：

can_init_params.can_prescaler = 9;
can_init_params.can_sjw = CAN_SJW_1TQ;
can_init_params.can_bs1 = CAN_BS1_6TQ;
can_init_params.can_bs2 = CAN_BS2_7TQ;

根据公式：

Bit Rate = F_APB1 / (prescaler × (1 + BS1 + BS2 + 1))
         = 72_000_000 / (9 × (1 + 6 + 7 + 1)) ≈ 500 kbps

这个计算看似简单，但在实际项目中，如果主频不是精确的72MHz（比如使用外部晶振且未校准PLL），或者分频系数选择不当，就可能导致节点间同步失败。建议在设计初期通过示波器测量实际波特率偏差，确保不超过±1%。

除了基本通信能力，GD32VF103的CAN模块还提供了不少实用特性。例如自动离线恢复（ABOM）功能，可以在检测到严重错误后尝试重新连接总线；又如自动唤醒（AWUM），允许设备在低功耗模式下监听总线活动并自行唤醒。这些特性在远程监控或电池供电场景中非常有用。

不过，真正让调试效率大幅提升的是 环回模式（Loopback Mode） 。只需将工作模式改为 CAN_LOOPBACK_MODE ：

can_init_params.can_mode = CAN_LOOPBACK_MODE;

此时发出的报文不会进入物理总线，而是直接被送入接收FIFO。这意味着你可以在不连接其他节点的情况下验证发送流程是否正常，甚至模拟完整的“自问自答”交互。对于产线自检或脱离现场调试来说，这是一种极为高效的手段。

说到接收处理，很多初学者习惯用轮询方式不断检查FIFO状态，但这显然浪费CPU资源。更合理的做法是启用中断：

void can_receive_isr(void) {
    if (can_receive_message_length_get(CAN0, CAN_FIFO0) != 0) {
        can_receive_message_struct rx_msg;
        can_message_receive(CAN0, CAN_FIFO0, &rx_msg);
        process_can_data(rx_msg.can_data, rx_msg.can_receive_dlen);
    }
}

配合NVIC配置，一旦有新帧到达即可触发ISR，响应延迟低且系统负载小。当然，若数据量极大，还可进一步结合DMA搬运，减少中断频率。

过滤器配置则是另一个容易忽视的重点。GD32VF103支持多达28组32位或14组64位滤波器，可用于精准筛选目标ID。调试阶段常采用“宽通模式”，即掩码全零，接收所有报文：

filter_params.can_filter_list_low  = 0x0000;
filter_params.can_filter_mask_low  = 0x0000;

但正式部署时应严格限定ID范围，避免无关流量占用FIFO空间。值得注意的是，滤波器编号固定不可跳过，因此建议优先为关键报文（如心跳包、急停指令）分配靠前的滤波器组。

在真实系统中，CAN很少单独存在。更多时候它是嵌入在复杂任务调度中的一个通信组件。如果你使用FreeRTOS，可以考虑划分如下任务：

• CAN Tx Task ：周期性打包传感器数据发送
• CAN Rx Task ：监听命令帧并执行动作
• Error Monitor Task ：定期读取 CAN_STAT 寄存器，判断是否处于“错误被动”或“离线”状态

通过消息队列传递接收到的数据，既能解耦处理逻辑，又能保证实时性。例如，当某个节点连续发送错误帧导致自身进入总线关闭状态时，监控任务可及时重启CAN外设或上报故障。

硬件层面的设计同样不容忽视。尽管MCU内部做了大量优化，但外部电路仍需遵循经典规范：

• 总线两端必须各加120Ω终端电阻，否则信号反射会导致通信不稳定；
• 推荐使用SN65HVD230或TJA1050这类成熟收发器，并为其提供独立电源路径；
• 在恶劣电磁环境中，应增加TVS二极管进行ESD保护，必要时采用磁耦隔离方案（如ADM3053替代型号）；

此外，PCB布线也需讲究：CAN_H和CAN_L应走差分线，尽量等长、远离高频干扰源，避免锐角拐弯。

回头再看那个看似简单的测试工程 gd32vf_can_test0.zip ，其实涵盖了从底层寄存器操作到上层应用逻辑的完整链条。它不仅仅是一个demo，更像是一个“最小可行系统”的模板——包含了时钟配置、引脚定义、波特率计算、过滤器设置、中断处理等核心模块，稍作修改即可用于产品原型开发。

更重要的是，它验证了RISC-V平台在工业通信领域的可行性。过去我们常说“国产替代难”，其中一个瓶颈就是生态不完善、参考设计少。而现在，像GD32VF103这样的芯片配合开源固件库，已经能够支撑起标准CAN通信的稳定运行。无论是教学实验、小型自动化设备，还是作为更大系统的通信子模块，这套方案都具备很强的实用性。

展望未来，随着GD32V系列向更高性能演进（例如支持CAN FD、主频提升至144MHz以上），这类基础通信模块的能力还将进一步扩展。想象一下，在新能源充电桩、轨道交通信号系统甚至航天地面测控中，使用自主可控的RISC-V芯片完成高速可靠的数据交互——这不再是遥远的理想，而是正在发生的现实。

某种意义上，每一个成功的CAN通信测试，都是通往更大自主化图景的一小步。而我们所要做的，就是把每一步走得扎实。