企业官网建设流程全解析

做工业控制这几年，通讯协议一直是项目里的重头戏。之前用 STM32 系列做过多机通讯，总感觉资源吃到七八成之后心里不踏实。这次新项目控制核心换了 GD32H759，主频跑到 600MHz，Cortex-M7 内核，外设也比上一代丰富不少，配套的 RT-Thread 实时操作系统把任务调度、设备管理理顺之后，开发节奏快了很多。项目定下来要打通的第一条通讯链路就是 CAN 总线，这也是工控现场用得最广泛的现场总线之一。这篇就把从零到跑通双机收发、再到用总线分析仪做实测的完整过程记录下来，给准备上手 GD32H759 + RT-Thread 做 CAN 通讯的朋友一个参考。

这篇文章适合两类人看：一类是刚从单片机和裸机编程切换过来，想在 RT-Thread 上正经做通讯功能的工程师；另一类是已经会 CAN 收发，但被波特率容差、负载率、错误帧这些概念困扰，想把底层逻辑吃透的开发者。文章会先从 CAN 协议的关键点说起，再讲 GD32H759 的硬件资源与电路设计，然后是 RT-Thread 驱动和应用层代码的完整写法，最后是实测数据和排障经验。整个过程按实际调试顺序来写，踩过的坑都会标注出来。

1. 项目背景与整体方案设计

1.1 为什么选 GD32H759 做主控

GD32H759 是兆易创新 GD32H7 系列里的旗舰型号，最大的卖点就是那颗 Arm Cortex-M7 内核。M7 和以前常用的 M4 相比，多了一条六段流水线，还内置了双精度浮点单元和 DSP 指令集，做算法类的任务明显轻松。对工控设备来说，600MHz 的主频保证了复杂的控制算法、HMI 刷新、协议栈处理可以同时跑而不互相拖累。

存储方面 GD32H759 给出了大容量的 Flash 和 SRAM，跑 RT-Thread 完整版加上文件系统、网络协议栈都绰绰有余。更重要的是它内置了多路 CAN-FD 控制器，这对要做多总线冗余或者需要扩展多路通讯的工控产品来说非常关键。芯片还带了硬件加解密、真随机数发生器等安全特性，为后续做设备认证、固件加密预留了位置。选型时我主要看三点：主频够不够、CAN 外设数量够不够、RT-Thread BSP 支持度好不好。三点都满足，这颗芯片就是合理选择。

1.2 RT-Thread 在工控场景中的优势

RT-Thread 是国内使用率很高的开源实时操作系统，和 FreeRTOS 相比，它不只是内核，还带了一套完整的中间件生态，比如设备驱动框架、FinSH 控制台、SAL 套接字抽象层、各种传感器驱动包。做实际产品的时候，这些中间件能省大量移植时间。

在 CAN 通讯这个需求上，RT-Thread 的设备驱动框架把底层硬件抽象成了标准设备接口。应用层想收发数据，只需要调用 rt_device_find、rt_device_open、rt_device_write、rt_device_read 这一组标准 API，不需要关心寄存器细节。模块化带来的直接好处是：代码可复用、可维护、可测试。以后换主控芯片，只要驱动层做好适配，上层业务逻辑几乎不用动。对做系列化产品的团队来说，这是很关键的长期价值。

1.3 项目通讯拓扑与场景定位

本项目的实际场景是一个小型现场控制单元，需要和另外两个从站设备交换状态数据。通讯拓扑用的是最经典的总线型结构，三个节点挂在同一对 CAN_H 和 CAN_L 双绞线上，波特率定为 500kbps，主站周期发送指令帧，从站收到后应答数据帧。这也是很多工控设备的基础通讯模型。

除了典型工控场景，CAN 总线在车载电子领域同样占据主流地位，整车 OBD 诊断、动力系统通讯、车身控制模块之间大量依靠 CAN 传输数据。所以做好 CAN 通讯不只是满足当前项目需求，更是为后续其他项目打下可复用的基础。文章里涉及的概念、代码、调试方法，放到车载场景一样适用，只是波特率、帧格式和协议层可能不同，底层逻辑完全相通。

2. CAN 总线核心原理，不懂这些后面一定踩坑

2.1 物理层与帧结构快读

CAN 总线的物理层用的是差分信号，两条线分别叫 CAN_H 和 CAN_L。显性电平对应逻辑 0，隐性电平对应逻辑 1。收发器就是负责把 MCU 侧的 TX/RX 逻辑电平转成差分信号的。这个差分设计带来了很强的抗干扰能力，线路上两条线受到的电磁干扰基本一致，接收端看的是两条线的差值，干扰就被抵消了。

数据帧的结构需要重点理解。一个标准数据帧从 SOF（帧起始）开始，接着是仲裁段（包含 ID 和 RTR 位）、控制段（DLC 数据长度）、数据段（最多 8 字节）、CRC 段、ACK 段和 EOF 帧结束。仲裁机制很有意思：多个节点同时发送时，ID 小的帧优先级更高，节点在发送过程中会持续监听总线，发现总线电平比自己发送的电平更占优势就自动退出，让高优先级帧先走。这就是 CAN 实时性好的一个关键原因。

CAN 2.0A 的标准帧 ID 是 11 位，CAN 2.0B 的扩展帧 ID 是 29 位。GD32H759 的控制器两者都支持。实际使用中，如果现场设备比较多，建议用扩展帧，ID 空间大，分组设计也更灵活；如果通讯要求简单、只想保持最小开销，标准帧就够用。后面实测时我两种都跑过，代码里切换也很方便。

2.2 波特率、采样点与负载率的计算方法

CAN 波特率不是随意设的，它由位时间决定。一个位时间分成四段：同步段 SYNC_SEG、传播段 PROP_SEG、相位缓冲段 1（PS1）和相位缓冲段 2（PS2）。整个位时间由若干个时间量子 Tq 组成。采样点出现在 PS1 结束的位置。

举个例子，目标波特率 500kbps，如果 APB1 外设时钟是 50MHz。一个位时间对应 1/500000 = 2000ns。如果每个位时间设置为 20 个 Tq，则每个 Tq 为 100ns，对应时钟频率 10MHz，预分频系数就是 50/10 = 5。采样点位置可以设计为 SYNC=1，PROP+PS1=15，PS2=4，这样采样点 =（1+15）/20 = 80%。这个采样点设置比较接近高速 CAN 常用的 75%~87.5% 区间，能容忍一定的线缆传播延迟和时钟偏差。

负载率的计算是很多人容易忽略的点。负载率定义是总线上实际传输的位速率占波特率的百分比。一帧完整报文在总线上占用的位长度大约是：SOF 1 位 + 仲裁段 12 位 + 控制段 6 位 + 数据段 8字节x8=64 位 + CRC 段 16 位 + ACK 段 2 位 + EOF 7 位 + 帧间间隔 3 位，标准帧 8 字节数据大约 111 位，再考虑位填充机制大概增加 10%~20%，工程估算可以取 128 位。

计算公式：负载率 =（每帧位长度 × 每秒帧数） / 波特率 × 100%。

以本项目为例：波特率 500kbps，主站每 10ms 发送一帧 8 字节数据帧，每秒 100 帧。负载率 =（128 × 100）/ 500000 = 2.56%。如果把发送周期缩短到 1ms，每秒 1000 帧，负载率就是 25.6%。工控现场建议负载率控制在 30% 以下，留足余量给错误帧重发和突发事件；车载诊断等场景可以到 50% 左右，再高总线时延会明显恶化。

2.3 错误帧与总线稳定性

CAN 总线的错误处理机制是它可靠性高的根本原因。总线上任何一个节点发现问题，都会主动发出错误帧，破坏正在传输的报文，让所有节点知道刚才那帧是无效的。错误分五种：位错误、填充错误、CRC 错误、格式错误和 ACK 错误。

控制器内部有错误计数器。发送错误计数值达到 16，节点进入错误被动状态，只能接收不能主动发送。达到 128 会进入总线关闭状态，完全脱离通讯，直到硬件复位或软件恢复。实际调试中最常见的错误帧来源是波特率不匹配、终端电阻缺失导致信号反射、线缆过长造成信号衰减。抓错误帧要借助 CAN 分析仪，它会统计错误帧类型和错误计数，按计数增长趋势反推原因。

有一个容易踩的坑：总线关闭之后，有些 MCU 并不会自动恢复。GD32H759 的 CAN 控制器需要软件主动清零复位请求位才能重新初始化。后面第 6 章的排查表里我会给出具体恢复流程。

3. GD32H759 CAN 控制器资源与最小硬件电路

3.1 片内外设资源与引脚分配

GD32H759 内置 CAN-FD 控制器，支持 CAN 2.0B 和 CAN FD（灵活数据速率）模式。CAN FD 相比传统 CAN 2.0，数据段最长可以到 64 字节，而且数据段的波特率可以高于仲裁段的波特率，这对大数据量传输是很大的效率提升。如果现场设备全是传统 CAN 2.0，那就按标准模式用，兼容性优先。

CAN 控制器的发送和接收都带 FIFO 与过滤器机制。过滤器可以配置成掩码模式或列表模式，只放行感兴趣的报文，减少 CPU 被无关报文打扰的次数。项目里我配置了两个接收过滤器：一个放行主站和从站之间的业务报文，一个放行诊断报文。闲置报文直接硬件过滤掉，应用层处理压力小很多。引脚方面，CAN0_TX 和 CAN0_RX 需要根据芯片手册查到具体复用 GPIO，在 RT-Thread BSP 里配置 GPIO 复用即可。

3.2 CAN 收发器选型与终端电阻

MCU 的 CAN 控制器输出的是逻辑电平，真正上总线需要一颗 CAN 收发器。选择收发器要考虑供电电压、速率、待机电流和 ESD 防护能力。调试阶段我用的是 TJA1051，5V 供电，兼容 3.3V MCU 电平，最高速率达到 1Mbps，适合 500kbps 的应用。如果板子整体是 3.3V 系统，也可以选 TJA1044，它带 3.3V 和 5V 双模供电，更灵活。

终端电阻是 CAN 总线调试里最容易忽略的一点。CAN 规范要求总线两端各接一个 120Ω 终端电阻，作用是吸收信号到达线路末端时的反射波，保证信号完整性。注意是两端都接，不是每个节点都接。实际项目里，设备在产线上通常是链式连接，最两端的是真正的物理端点。我的做法是每个节点都加一个可选的 120Ω 电阻，用跳线帽控制接入，这样不管设备安装在哪个位置，都能通过跳线设置成终端节点。这个设计在产线部署时非常方便，省得再找独立终端电阻。

3.3 防护电路与 PCB 走线要点

工控现场和车载环境都有较强的电磁干扰，CAN 接口必须做防护。最基本的电路是在总线连接器处加一对 TVS 管，比如 PESD1CAN，把过压尖峰钳位到安全范围；再串一个共模电感，抑制共模干扰，同时为差分信号提供连续性。收发器后面最好还要加一个高频滤波电容到地，滤掉电源线上的噪声。

PCB 布局上有几条硬性经验。第一，CAN_TX 和 CAN_RX 尽量靠近收发器，走线要短，这些引线是单端信号，长了容易耦合噪声到差分对。第二，差分走线 CAN_H 和 CAN_L 要平行等长，保证两根线上的延迟一致，长度差控制在 5mil 以内。第三，收发器的电源引脚必须放 0.1μF 去耦电容，而且要贴近电源脚放置，位置不对等于没加。第四，TVS 管和共模电感要靠近连接器，这样防护器件才能在干扰进入主板前就把它钳住。我见过很多原理图画得很完整，但因为布局随意，实际 EMC 测试不过的案例，布局和原理图同样重要。

4. RT-Thread 下 CAN 驱动移植与配置

4.1 开发环境准备与工程创建

开发环境我用的是 RT-Thread Studio，这个 IDE 基于 Eclipse，集成了工程管理、编译、下载和调试，对 GD32 系列有比较完善的 BSP 支持。创建工程时选择芯片型号 GD32H759，Studio 会自动拉取对应的 SDK 和 BSP，并把 RT-Thread 内核源码一起生成好。

有个细节需要提醒：创建完工程之后，先在 RT-Thread Settings 中确认 CAN 设备驱动有没有包含进来。不同版本的 BSP 支持的芯片外设列表有差异，如果找不到 CAN 配置项，多半是 BSP 版本太老，需要在 SDK 管理器中更新。我一开始用的旧版本 BSP 只支持 USART，更新到新版之后 CAN0、CAN1、CAN FD 相关选项才出现。这一步虽然简单，但会卡掉不少人。

4.2 驱动框架与菜单配置

RT-Thread 的设备驱动框架把 CAN 驱动抽象成两层。底层是 drv_can.c，直接操作 GD32H759 的寄存器，完成波特率设置、FIFO 管理、中断处理；上层是设备驱动框架，把底层能力封装成标准设备接口。我们要做的就是确认底层驱动被编译进内核，再在应用层使用标准接口。

在 RT-Thread Settings 开启 CAN 的方式很直观，图形化界面勾选 Enable CAN Driver，配置波特率、中断优先级等信息。配置完成后会自动生成对应的宏，比如 BSP_USING_CAN0，驱动代码会根据宏决定是否参与编译。这里有一个实操建议：开发和调试阶段，建议把接收中断线程的优先级设得高一些（数字小），比如 10，确保数据到达时能尽快被处理。如果优先级太低，高负载下接收 FIFO 会溢出丢帧。

4.3 应用层完整收发代码

应用层的核心逻辑是：初始化设备、注册接收通知回调、创建两个线程分别处理发送和接收。接收线程阻塞在信号量上，有数据到达时回调释放信号量，线程被唤醒后读取数据。这种机制避免了轮询占 CPU，实时性也有保证。

下面是我调试通过的核心代码，做了简化和注释，可以直接移植：

#include <rtthread.h> #include <rtdevice.h> #include <string.h> #define CAN_DEV_NAME "can0" #define CAN_RX_THREAD_PRIO 10 #define CAN_RX_THREAD_STACK 1024 #define CAN_TX_THREAD_PRIO 12 #define CAN_TX_THREAD_STACK 1024 static rt_device_t can_dev; static struct rt_semaphore rx_sem; /* 接收通知回调：由驱动中断上下文调用，只释放信号量 */ static rt_err_t can_rx_ind(rt_device_t dev, rt_size_t size) { rt_sem_release(&rx_sem); return RT_EOK; } /* 接收线程：等待信号量，读取报文并打印 */ static void can_rx_thread_entry(void *parameter) { struct rt_can_msg rx_msg = {0}; while (1) { rt_sem_take(&rx_sem, RT_WAITING_FOREVER); while (rt_device_read(can_dev, 0, &rx_msg, 1) == 1) { rt_kprintf("rx id=0x%08x len=%d", rx_msg.id, rx_msg.len); for (int i = 0; i < rx_msg.len; i++) { rt_kprintf(" %02x", rx_msg.data[i]); } rt_kprintf("\n"); } } } /* 发送线程：周期发送一帧标准帧 */ static void can_tx_thread_entry(void *parameter) { struct rt_can_msg tx_msg = {0}; tx_msg.id = 0x123; tx_msg.ide = RT_CAN_STD; tx_msg.rtr = RT_CAN_DTR; tx_msg.len = 8; tx_msg.data[0] = 0xAA; tx_msg.data[1] = 0xBB; tx_msg.data[2] = 0xCC; tx_msg.data[3] = 0xDD; tx_msg.data[4] = 0x01; tx_msg.data[5] = 0x02; tx_msg.data[6] = 0x03; tx_msg.data[7] = 0x04; while (1) { rt_device_write(can_dev, 0, &tx_msg, sizeof(tx_msg)); rt_thread_mdelay(10); } } /* CAN 设备初始化和过滤配置 */ static int can_app_init(void) { struct rt_can_filter_item filter = { .id = 0x123, .ide = RT_CAN_STD, .rtr = RT_CAN_DTR }; can_dev = rt_device_find(CAN_DEV_NAME); if (can_dev == RT_NULL) { rt_kprintf("find %s failed\n", CAN_DEV_NAME); return -RT_ERROR; } rt_sem_init(&rx_sem, "rx_sem", 0, RT_IPC_FLAG_FIFO); /* 先注册回调再打开设备，防止丢第一条数据 */ rt_device_set_rx_indicate(can_dev, can_rx_ind); if (rt_device_open(can_dev, RT_DEVICE_OFLAG_RDWR) != RT_EOK) { rt_kprintf("open %s failed\n", CAN_DEV_NAME); return -RT_ERROR; } /* 设置波特率，单位是 bps */ rt_device_control(can_dev, RT_CAN_CMD_SET_BAUD, (void *)500000); /* 设置接收过滤器，只放行自己关心的报文 */ rt_device_control(can_dev, RT_CAN_CMD_SET_FILTER, &filter); rt_thread_create("can_rx", can_rx_thread_entry, RT_NULL, CAN_RX_THREAD_STACK, CAN_RX_THREAD_PRIO, 20); rt_thread_create("can_tx", can_tx_thread_entry, RT_NULL, CAN_TX_THREAD_STACK, CAN_TX_THREAD_PRIO, 20); return RT_EOK; } INIT_APP_EXPORT(can_app_init);

有几个地方要特别注意。rt_device_set_rx_indicate 必须在 rt_device_open 之前调用，原因是 open 之后设备立刻开始接收数据，如果回调注册晚了，中断来了没有通知机制，数据会滞留在 FIFO 里没人读。发送线程和接收线程之间如果访问同一个变量，需要加互斥锁，示例里发送内容是固定写死的，自然没有竞争。实际产品里发送数据往往来自业务线程，建议在发送函数外统一加互斥锁，避免多个线程同时写一条 CAN 总线。

过滤器配置这里，我只设置了一个过滤项。RT-Thread 的 CAN 驱动框架支持多组过滤表和掩码模式，具体数量与底层硬件相关。设置之前先看 BSP 里 drv_can.c 的注释，不然容易出现过滤器注册返回 -RT_EINVAL 的情况。优先级上，标准帧和扩展帧可以分别配置，代码里用 ide 字段区分。

4.4 中断接收还是 DMA 接收，怎么选

CAN 接收用中断还是 DMA，是很多人在论坛上反复问的问题。我的结论是：大多数场景直接用中断接收，只有极少情况值得上 DMA。

CAN 是报文型协议，一帧最多 64 字节，传统 CAN 2.0 是 8 字节。数据量天然很小，中断接收的开销完全可以接受。中断模式的好处是实时性高：FIFO 里有数据立即触发中断，系统马上通知应用线程处理，延迟只在微秒到几十微秒之间。DMA 接收适合什么场景？数据连续不断地到达、每帧数据量非常大、CPU 不想频繁被打断，这时让 DMA 把数据自动搬到内存，可以减轻 CPU 压力。但对 CAN 这种以帧为单位、帧间有较长空闲的通讯方式，DMA 优势不明显，反而引入了管理 DMA 描述符、处理半满中断的复杂度。

如果你真的打算用 DMA，优先级和缓冲区的设计一定要谨慎。DMA 搬数据虽然是硬件自动的，但搬完之后 CPU 还是要处理数据，这时候如果接收线程运行不及时，DMA 缓冲区满了同样丢帧。相比之下，把接收中断线程优先级调到 10 以内，处理函数尽量精简，属于性价比最高的做法。对于 GD32H759 这种带 M7 内核和大量 SRAM 的芯片，中断接收在 1Mbps 波特率下满载跑也没有任何压力。

那 FPGA 实现 CAN 是回事？在一些特殊场景，比如需要 TTCAN 时间触发通讯、多路 CAN 扩展、超低延迟硬件转发，FPGA 方案确实有优势，因为它可以把协议逻辑放到硬件里跑，时序确定性比任何 MCU 都强。但对绝大多数工控设备来说，MCU 内置 CAN 控制器加一颗收发器的方案在成本、开发效率、可维护性上有压倒性优势。除非产品定义里明确要求多路高速 CAN-FD 且 MCU 资源不够，否则不建议引入 FPGA。

5. 实测记录与总线性能评估

5.1 双机回环与 CAN 分析仪接入

调试的第一步我建议先做双机回环而不是直接上整个总线网络。找两块 GD32H759 开发板，一块配置成发送，一块配置成接收，先用短导线把两边的 CAN_H 和 CAN_L 对接，终端电阻各接一个 120Ω。然后在此基础上接入一台 USBCAN 分析仪，它可以同时监听总线上的所有报文并统计错误。

回环测试时先在发送端把报文 ID 设为 0x123，扩展帧或标准帧统一，发送周期 10ms。接收端通过串口打印收到的报文内容，逐字节比对。这个阶段最大价值是确认硬件电路、驱动配置、收发逻辑都没有问题。如果回环都跑不通，后面挂多节点排查起来难度会成倍增加。

实测结果与理论框架基本吻合。发送端周期 10ms 的前提下，分析仪统计到的总线负载率约 2.5%，和前面 2.2 节计算的结果一致。接收端打印的数据逐字节正确，没有发生 CRC 错误或填充错误。把发送周期改为 2ms 后，负载率升到 12.8%，通讯依然稳定；进一步改为 1ms 后负载率 25.6%，出现了轻微的发送等待延迟，原因是发送操作本身占用了总线时间，但总线上没有产生错误帧。

5.2 去掉终端电阻后的波形与错误帧

测试过程中我做了个对比实验，把其中一个 120Ω 终端电阻摘掉。刚开始感觉不太明显，因为线缆只有 1 米左右，信号反射时间极短。但是把线延长到 10 米之后，分析仪上开始出现零星的 CRC 错误帧，而且发送端错误计数逐步上升。用示波器挂在 CAN_H 和 CAN_L 之间看波形，能明显看到下降沿和上升沿有过冲和振铃，这就是阻抗不匹配的直接表现。

重新接上终端电阻后，错误帧立刻消失，波形变得干净。这个实验说明一个道理：终端电阻不是可有可无的东西，它对信号完整性影响巨大。10 米距离对应的信号传输延迟已经足够让反射波干扰到采样点附近的电平判断，哪怕发送端本身没有任何问题。实际现场如果碰到偶发错误帧，先检查总线两端的 120Ω 是否在位，永远比怀疑代码更高效。

5.3 高负载与多节点竞争测试

为了摸清系统在高负载下的表现，我挂上了第三块开发板，三块板同时作为发送节点向总线发报文，ID 分别设为 0x100、0x200、0x300，周期各不相同。这时候观察到一个现象：低 ID 的节点发送成功率高，高 ID 节点偶尔出现发送失败。原因就是 CAN 的非破坏性仲裁机制——每次总线空闲时多个节点同时竞争，ID 小的先赢。这是协议本身的特性，不是 bug。

合理安排 ID 分配可以显著提高系统稳定性。关键实时性要求高的报文用低 ID，比如 0x100 的控制指令；实时性要求低、数据量大的报文用高 ID，比如 0x300 的日志数据。如果两个功能同等重要，也可以考虑错开发送周期，降低碰撞概率。实际产品中的 ID 规划应该在协议设计阶段就完成，而不是等程序跑起来出了问题再改。

测试数据汇总如下：

6. 常见问题与排查技巧实录

6.1 高频故障速查表

调试过程中遇到的大部分问题都可以归纳到下面这张表里，建议收藏备用。

还有一个自由量是总线长度。CAN 总线的传输距离和波特率成反比，500kbps 常规极限在 100 米左右，超过这个距离即使终端电阻正确，信号质量也会下降。现场布线如果超过这个长度，要么降波特率，要么用中继器，没有第三种选择。

6.2 利用分析仪和示波器定位问题

CAN 分析仪是我觉得排查问题时效率最高的工具。它能够实时显示总线上每一帧的 ID、数据、CRC、错误标志，还能统计错误帧率。当怀疑总线上有节点行为异常时，只要把分析仪挂上去，看错误计数增长来自哪种错误类型，基本就能锁定方向。比如 CRC 错误大量增长，说明信号完整性有问题，优先检查物理层；格式错误大量增长，说明某个节点配置了不同的帧格式，优先检查软件配置。

示波器的用处则是在更深层次上验证信号。抓取 CAN_H 和 CAN_L 的差分波形，检查显性电平幅值是否在 1.5V~3.5V 的合理区间，隐性电平是否接近 2.5V，位时间是否稳定。对于偶发问题，用示波器的余辉模式长时间观察，能捕获到偶发的毛刺。两个工具配合使用，可以覆盖从协议层到物理层的完整排查。

6.3 我的调试习惯和建议

最后分享几个我自己固定使用的调试习惯。第一，任何新板子回来，先用回环模式验证 CAN 控制器本身是否工作，再切到正常模式对接外部设备。第二，所有固定参数，比如波特率、帧格式、过滤器、节点 ID，尽量用宏定义集中管理，避免代码里出现裸数字。第三，CAN 驱动的接收回调里永远不要做耗时操作，只做标记和信号量释放，具体处理逻辑放到线程里。第四，产品发布前一定要做满载压力测试，周期设置的比实际场景快两倍以上，连续跑 24 小时，确认错误计数保持为 0。

调试 CAN 总线这几年，最大的体会是：这个协议上游的容错设计非常强大，大部分问题根源都在物理层和配置层。先怀疑接口电路，再怀疑收发器配置，最后才怀疑芯片本身。按照这个顺序排查，基本很少走弯路。GD32H759 加 RT-Thread 这套组合，只要把驱动框架吃透，后面移植各种上层协议比如 CANopen、J1939，都只是在这个基础上加一层解析而已，基础打牢了，后面的路会顺很多。