最近在调试一块GD32H759 RT-Thread的工控板主打一个高主频、多外设、还能跑实时系统。折腾了快一个月最让我花时间的不是主频600MHz的CPU也不是复杂的网络协议栈反而是看起来“老掉牙”的CAN总线。越往里钻越觉得CAN总线在工控现场的地位真不是以太网能随便替代的。这篇我把CAN相关的协议细节、收发方案选型、实际调试排障全部摊开写一遍给准备用GD32H759这类国产高端MCU跑RT-Thread做CAN通信的同学一个完整参考。这个系列的第一篇我重点聊CAN总线。内容包括GD32H759 RT-Thread这套组合为什么适合做工控CAN节点CAN协议里帧结构、仲裁、错误帧这些底层机制尽量用大白话讲清楚实际项目里中断接收还是DMA接收我最终怎么选的完整的初始化、发送、接收代码可以直接抄到你的项目里负载率怎么算、测试怎么做、现场排障有哪些坑。老规矩全部来自实际板级调试经验有代码、有数据、有踩坑记录。1. 项目整体思路为什么是 GD32H759 RT-Thread CAN1.1 GD32H759 这颗芯片强在哪GD32H759是兆易创新GD32H7系列里的旗舰型号ARM Cortex-M7内核主频最高可以跑到600MHz片上带了DSP指令集和单精度浮点单元算力在MCU里属于第一梯队。Flash和RAM的配置也大方项目里跑RT-Thread完整版、上文件系统、上网络协议栈资源都比较宽裕。我选这颗芯片的核心原因有三个。第一是外设丰富。GD32H759上有多路CAN-FD控制器官方叫做FDCAN向下完全兼容经典CAN 2.0A/2.0B协议。一台设备上需要同时挂好几路CAN总线比如一个负责伺服控制、一个负责传感器采集、一个备用调试这颗芯片能让你不用再加外部CAN扩展芯片。第二是实时性有保障。Cortex-M7主频高中断响应快RT-Thread在这种芯片上跑起来调度延迟可以压到很低这对CAN这种实时通信场景非常关键。第三是性价比和供应链。同等配置的国际大厂芯片价格和交期都不太好看国产芯片这两年在这块确实能打。另外提醒一句很多工控场合用RS485做设备互联但RS485本质是半双工的单主轮询总线利用率低、协议复杂、故障隔离能力弱。CAN总线天生多主、强实时、带错误检测和自动重发这是我在现场更愿意用CAN的原因。1.2 CAN 在工控场景的价值与选型考量CAN全称Controller Area Network最早是汽车行业为了减少线束提出的后来因为可靠性高逐步被工业控制、机器人、医疗器械等领域大规模采用。和以太网相比CAN有几个很明显的优点多主通信谁都能主动发数据不需要主机点名总线仲裁靠硬件完成优先级高的帧自然抢占总线实时性有保证强错误检测包括CRC校验、位填充检查、应答确认、错误帧通告节点发现自己错误还能自动断开物理层用差分信号抗共模干扰能力强线束少距离可以到几百米甚至上千米低速。CAN也不是万能的它定义了物理层和数据链路层再往上怎么办得靠CANopen、DeviceNet、J1939或者自己定一套协议。比如我做伺服联动CANopen是最常见的做传感器数据采集则可以直接自定义简单的ID加数据方案。所以在选型时除非必须用到复杂网络管理CAN总线作为底层传输是足够用的。从整体架构看GD32H759负责应用逻辑和协议解析RT-Thread负责任务调度和设备驱动抽象CAN总线负责和外部设备通信这个组合覆盖了绝大部分工控控制器需求。1.3 RT-Thread 的 CAN 驱动框架RT-Thread对CAN设备做了统一的设备框架抽象。不管底层是STM32的bxCAN还是GD32的FDCAN应用层拿到的都是标准的rt_device接口。这点我很喜欢因为意味着换芯片时应用层代码几乎不用动。使用CAN设备时流程一般是这样rt_device_find 找到CAN设备节点rt_device_open 以中断接收或轮询方式打开rt_device_control 设置波特率、过滤器等参数rt_device_set_rx_indicate 注册接收回调rt_device_write 发送CAN帧rt_device_read 读取CAN帧。接收可以走中断回调也可以阻塞等待读取。项目里我通常是先注册接收回调在回调里把数据丢到消息队列应用线程再从队列取帧做协议解析。这样把中断上下文和线程上下文隔离开不会在中断里做耗时操作跟RT-Thread推荐的编程风格一致。2. CAN 协议核心细节从帧结构到错误帧2.1 一文读懂 CAN 帧结构与仲裁先讲最基础的数据帧。CAN总线上一共有五种帧数据帧、遥控帧、错误帧、过载帧、间隔帧。日常打交道最多的是数据帧。CAN数据帧分标准帧和扩展帧两种格式。标准帧用11位标识符ID扩展帧用29位ID。经典CAN数据帧的数据长度最大是8字节CAN-FD出现以后扩展到64字节但现场很多老设备仍旧只跑8字节经典CAN调试时先搞清楚对方跑的是标准帧还是扩展帧、数据长度是多少能少走很多弯路。一个标准数据帧的大致结构是这样SOF起始帧1位显性电平仲裁场包含11位ID和1位RTR远程发送请求位控制场包含IDE、保留位和DLC数据长度代码数据场0到8字节数据CRC场15位CRC校验加1位CRC界定符ACK场发送方发送隐性位接收方拉低表示应答EOF7位隐性帧结束标志。为什么我说CAN的仲裁机制非常优雅因为在总线上显性电平逻辑0能覆盖隐性电平逻辑1发送节点在发送ID的同时一直在监听总线。如果两个节点同时发帧高位ID的节点发现总线和自己发送的电平不一致就立刻退出让低电平ID的节点继续发送。简单理解ID数字越小优先级越高。这样仲裁过程完全硬件自动完成不浪费总线时间。再提一句位填充机制CAN规定连续出现5个相同电平后必须插入一个相反电平。这是为了保证收发双方的时钟同步但也会导致实际帧长比理论值多出几到几十个位。后面计算负载率时这个填充位不容忽视。2.2 错误帧到底是怎么来的这才是CAN总线调试最让人头疼的部分。错误帧不是用户手动发的而是CAN控制器在检测到总线异常时自动发出的通告信号。一旦总线上有人发错误帧每个节点都会中断当前通信重新仲裁后果就是整个网络通信被破坏。CAN控制器会检测五类错误位错误节点发出电平后监听到的电平和预期不一致格式错误收到的帧不符合CAN格式比如界定符位置不对填充错误连续相同位超过5个仍没有填充位CRC错误CRC校验和与本地计算结果不一致应答错误发送节点在ACK场没有收到其他节点的显性应答。出现错误后节点会发送错误帧错误帧由6个显性位加8个隐性界定符组成。每个节点内部有发送错误计数器TEC和接收错误计数器REC检测到错误会加8或加16发送失败还会额外增加。如果一个节点错误太多状态会从主动错误态降级到被动错误态最后进入总线关闭态。总线关闭态的节点会主动切断与总线的通信相当于把自己踢出网络避免拖垮全场。现场调试如果发现总线上错误帧满天飞最高效的办法就是先看波特率、终端电阻、地线、隔离这些物理层选项因为绝大多数错误帧都是这几个原因引起的。关于具体排查我在第6章单独写。2.3 位时序与采样点决定一把抓得住总线很多人能配通CAN但一上现场就偶尔丢帧、重发问题很可能出在采样点配置上。CAN的一位时间由四段组成同步段固定1个时间量子传播段补偿传输延迟和节点间距离相位缓冲段1相位缓冲段2。一般会把传播段和相位缓冲段1合并成BS1相位缓冲段2叫BS2。一位时间等于同步段加BS1再加BS2。采样点就是节点真正读取总线电平的时刻位置一般在位时间的70%到85%之间。GD32H759的FDCAN外设配置波特率时需要提供预分频系数、BS1、BS2这些参数。以经典CAN 500Kbps为例如果外设时钟是100MHz时间量子为1/100MHz每位需要200个时钟周期。如果预分频设10则一个时间量子是10个时钟周期每位合20个时间量子。那么可以取同步段1个时间量子、BS1占13个时间量子、BS2占6个时间量子采样点就是(113)/2070%。如果现场总线距离远、干扰大可以适当把采样点往后挪比如BS114、BS25采样点75%。一个懒人的做法是板子稳定后用CAN分析仪或示波器抓一下实际波形对比位时间宽度和采样点是否和配置一致。高负载现场更要对采样点做微调否则在线缆长、节点多的网络中很容易出现随机错误。3. 收发方案选型中断接收还是 DMA 接收3.1 三种收发方式的对比经常有人问CAN总线是中断接收还是DMA接收好这个话题我也纠结过最后通过实测得出结论我推荐中断接收并且RT-Thread官方驱动框架也更适合这么用。先把三种方案的优缺点列出来。方案优点缺点适用场景中断接收帧粒度清晰、响应及时、能配合回调直接丢队列每帧都进中断高频时有CPU开销经典CAN小帧、RT-Thread驱动框架默认DMA接收批量搬运数据、降低CPU介入次数帧边界处理复杂、不定长帧需要额外逻辑、CAN外设DMA支持有限超高频收发、CAN-FD大数据块轮询接收代码简单、无中断上下文CPU忙等、实时性差调试用、低负载场景这里要强调一个概念CAN的数据帧不像UART那样是个纯字节流它有明确的帧头、仲裁场、数据长度和CRC。中断方式天然是“每来一帧就通知一次CPU”CPU在中断里去读FIFO或邮箱就能拿到一个完整帧。DMA方式适合大块连续数据搬运但CAN帧之间是有间隙的如果DMA配置不当很容易把下一帧的一部分也搬进来还得靠硬件过滤器、帧尾判断来切帧非常麻烦。3.2 为什么我选了中断接收在经典CAN 500Kbps下一帧最多8字节数据按满载估总线最多大约每秒能跑几千帧。对Cortex-M7这种600MHz内核来说每帧一个中断CPU占用率根本不高。我用Stress工具测过高负载接收每秒钟3000帧左右CPU占用也不会超过10%。这点代价换来的帧处理逻辑简单可靠非常划算。更重要的原因是RT-Thread的设备驱动框架本身就是围绕回调设计的。驱动在中断里收到数据调用应用层注册的接收回调应用层在回调里用消息队列或信号量通知线程去处理。如果非要用DMA还得自己实现一套半帧处理逻辑和框架打架。除非你的应用是CAN-FD 64字节超大数据块、且每帧间隔极短否则普通工控项目老老实实走中断接收省心又稳定。发送侧我也推荐中断发送确切的说是“发送完成中断”。先写一帧到控制器发送完成后进入中断再写下一帧保证不会溢出。当然也可以用轮询等待空闲再发这个看具体代码习惯。3.3 实操RT-Thread 下初始化 CAN 设备以GD32H759的FDCAN0为例在RT-Thread的FinSH控制台里能先确认设备注册。然后初始化代码如下#include rtthread.h #include rtdevice.h #include drv_can.h #define CAN_DEV_NAME can0 static rt_device_t can_dev RT_NULL; static struct rt_semaphore tx_sem; /* 发送完成回调发送完成时释放信号量 */ static rt_err_t can_tx_done(rt_device_t dev, void *buffer) { rt_sem_release(tx_sem); return RT_EOK; } void can_init(void) { rt_err_t res; struct rt_can_filter_config filter_cfg; struct rt_can_filter_item filter_item; can_dev rt_device_find(CAN_DEV_NAME); if (can_dev RT_NULL) { rt_kprintf(can0 not found\n); return; } /* 以中断收发模式打开设备 */ res rt_device_open(can_dev, RT_DEVICE_FLAG_INT_TX | RT_DEVICE_FLAG_INT_RX); if (res ! RT_EOK) { rt_kprintf(can0 open failed\n); return; } /* 设置波特率500Kbps */ res rt_device_control(can_dev, RT_DEVICE_CTRL_CAN_BAUDRATE, (void *)500000); if (res ! RT_EOK) { rt_kprintf(set baudrate failed\n); return; } /* 配置过滤器接收所有帧 */ filter_item.mode RT_CAN_FILTER_MODE_MASK; filter_item.mask 0xFFFFFFFF; filter_item.val 0; filter_item.ide RT_CAN_FILTER_EXT; filter_cfg.count 1; filter_cfg.actived 1; filter_cfg.filter[0] filter_item; res rt_device_control(can_dev, RT_DEVICE_CTRL_CAN_FILTER, (void *)filter_cfg); if (res ! RT_EOK) { rt_kprintf(set filter failed\n); return; } /* 注册发送完成回调并初始化信号量 */ rt_device_set_tx_complete(can_dev, can_tx_done); rt_sem_init(tx_sem, tx_sem, 0, RT_IPC_FLAG_FIFO); }这里有几个容易踩的细节。第一过滤器通过掩码模式把全部帧放进来适合前期调试如果只想接收特定ID就把mask和val设置成对应值。第二RT_DEVICE_CTRL_CAN_BAUDRATE的入参是波特率数值不是分频配置。底层驱动会自己换算位时序参数但如果你需要精细设置采样点还是要到驱动源码里把预分频和BS1/BS2手动调一下。4. 实操写一个 CAN 收发测试程序4.1 硬件连接与电气注意软件之前先说硬件。CAN电路看着简单其实电气上最容易出问题。接线方面CAN需要两根线CAN_H和CAN_L另外节点之间必须共地不能只接两根信号线就跑。CAN收发器芯片负责把MCU的CAN控制器电平转换成差分信号常用芯片有TJA1050、TJA1042、MCP2551等。GD32H759内部集成的是CAN协议控制器不集成收发器所以板上需要外接一颗收发器芯片收发器和MCU之间一般会加隔离或共模电感抗干扰更好。终端电阻是很多新手容易漏掉的总线两端必须各接一个120欧姆电阻。如果只有两个节点那么一端在设备的CAN_H和CAN_L之间跨接一个120欧姆电阻就行另一端也在跨接一个。算一下阻抗匹配总线端到端总电阻是60欧姆这是标准匹配值。没有匹配电阻或只接一个高速通信时反射严重错误帧必然出现。现场如果距离超过几十米我建议总线上加共模电感并且把屏蔽层单端接地。另外CAN收发器的电源噪声影响也大开关电源和CAN供电尽量分开实测能明显减少偶发错误帧。4.2 初始化与发送代码初始化完成之后写一个发送函数。核心是构造struct rt_can_msg结构体然后调用rt_device_write。/* 发送一帧标准数据帧 */ int can_send(uint32_t id, uint8_t dlc, uint8_t *data) { struct rt_can_msg msg; msg.hdr 0; msg.id id; msg.ide 0; /* 0 表示标准帧1 表示扩展帧 */ msg.rtr 0; /* 0 表示数据帧1 表示遥控帧 */ msg.dlc dlc; /* 数据长度经典CAN最大8 */ if (dlc 8) { rt_kprintf(dlc too long\n); return -RT_EINVAL; } rt_memcpy(msg.data, data, dlc); /* 调用设备发送等待发送完成信号量 */ rt_device_write(can_dev, 0, msg, sizeof(msg)); rt_sem_take(tx_sem, RT_WAITING_FOREVER); return RT_EOK; }发送函数中我用了信号量等待发送完成这样能保证上一帧没有被覆盖。如果调用rt_device_write后不等待连续写帧时驱动内部的发送缓冲区可能被覆盖导致丢帧。这是我在高频率发送时踩过的坑。/* 简单测试周期性发送一帧0x100内容为计数器 */ void can_test_thread(void *param) { uint8_t data[8] {0}; uint32_t count 0; while (1) { data[0] (count 0) 0xFF; data[1] (count 8) 0xFF; can_send(0x100, 2, data); count; rt_thread_mdelay(10); } }这里注意滤波器的配置发送完成后对端如果设置了过滤器只会接收满足条件的ID。测试阶段我习惯把过滤器全部放行看到数据再逐步收窄。4.3 接收回调与数据处理接收端我采用“中断回调消息队列”的方式这也是RT-Thread项目里常见做法。static struct rt_mq rx_mq; struct can_rx_item { rt_uint32_t id; rt_uint8_t ide; rt_uint8_t rtr; rt_uint8_t dlc; rt_uint8_t data[8]; }; /* 接收回调运行在中断上下文只做消息投递 */ static rt_err_t can_rx_ind(rt_device_t dev, rt_size_t size) { struct rt_can_msg msg; struct can_rx_item item; if (rt_device_read(dev, 0, msg, sizeof(msg)) sizeof(msg)) { item.id msg.id; item.ide msg.ide; item.rtr msg.rtr; item.dlc msg.dlc; rt_memcpy(item.data, msg.data, msg.dlc); /* 这里用不等待的发送队列满了就丢弃 */ rt_mq_send(rx_mq, item, sizeof(item)); } return RT_EOK; } /* 应用线程处理接收到的CAN帧 */ void can_rx_thread(void *param) { struct can_rx_item item; rt_ssize_t len; while (1) { len rt_mq_recv(rx_mq, item, sizeof(item), RT_WAITING_FOREVER); if (len 0) { /* 在这里做协议解析 */ rt_kprintf(recv id%x dlc%d data[0]%02X\n, item.id, item.dlc, item.data[0]); } } }回调里不能调用长时间阻塞的函数rt_mq_send如果队列满了会立刻返回错误所以我在消息队列配置时把容量调大一些并且应用线程处理速度要跟上。实测在500Kbps、每帧8字节、每秒2000帧的情况下消息队列深度设置16就够了但为了稳定我一般设置32。5. CAN 总线测试与负载率计算5.1 必做的基础测试项CAN总线上线前我通常按下面的顺序做一轮测试这能覆盖90%的底层问题。第一步自回环测试。把GD32H759的CAN控制器配成回环模式自己发自己收验证MCU内部CAN外设和中断通路是否正常。回环测试通过只能说控制器没问题不代表物理链路OK。第二步双机互联测试。两台设备通过CAN线直连中间不接其他节点。一台发、一台收观察数据是否一致。这里我会故意用逻辑分析仪看波形确认CAN_H和CAN_L的差分电平正常。空闲时CAN_H和CAN_L都处于隐性电平即CAN_H约2.5VCAN_L约2.5V发送显性位时CAN_H升高到3.5V左右CAN_L降低到1.5V左右差分电压约2V。逻辑分析仪看CAN还能直接解析出帧ID和数据非常方便。第三步容错性测试。模拟现场可能出现的状况比如线缆中间断开、CAN_H和CAN_L互接、一条线接地等。正常情况下CAN网络应该能报错并恢复而不是死锁。如果板子进入bus-off没有恢复机制那就要在软件里加入恢复逻辑。第四步高负载可靠性测试。用CAN分析仪或直接写代码激发大量帧连续压测一小时以上观察是否有偶发错误帧、丢帧。这一步能暴露采样点配置问题。5.2 负载率到底怎么算很多人问我负载率怎么算我直接给一个可落地的公式和建议。总线负载率其实是在一个时间窗口内总线上实际传输的位数除以总线的可传输位数。CAN总线的波特率决定了每秒最多能传多少位。所以一条总线上所有节点每秒发送的帧位之和除以波特率就是负载率。经典CAN一帧标准数据帧的位长度并不固定因为位填充会改变帧长。粗略估算可以把填充位加进去标准帧一般按约110到135位估算扩展帧再多20位左右。如果纯理论计算标准帧在最坏情况下是130位左右。更稳妥的方法是用CAN分析仪直接看Busload但选型阶段靠估算就够了我给你个例子。假设波特率500Kbps也就是每秒500,000位。某个节点每10毫秒发一帧标准数据帧帧长按120位估算那么每秒发100帧总位数为12,000位负载率等于12000 / 500000 2.4%。如果有5个这样的节点负载率约12%。看起来很低对吧但如果每个节点每1毫秒发一帧每秒总帧数就到5000帧负载率瞬间冲上120%总线早就饱和了。所以我的经验是经典CAN总线负载率建议不要长期超过50%做设计时按30%预留余量因为还要考虑偶发重发帧、错误帧、管理帧。负载率超过70%后总线延迟和丢帧风险都急剧上升。5.3 实测经验台上算好现场翻车有次项目现场所有节点都按规划好的周期发帧理论负载率算下来不到30%但实际跑起来错误帧特别多。用CAN分析仪一看有个旧设备节点一直在发重复帧实际上它每次发送失败都会自动重发导致负载率冲到80%以上。所以计算负载率时不仅要算正常帧还要考虑节点自动重发和错误恢复机制。另一个教训是多个节点同时上电瞬间如果都不做发送延时抢总线会导致第一批帧大量重发。我后来的习惯是每个节点上电后延迟几毫秒到几十毫秒再开始发周期帧把上电瞬间的并发冲撞打散整体可靠性提升明显。6. 常见问题与排查技巧实录6.1 收发完全失败先查这几样遇到CAN完全不通我有一套固定的排查顺序。先用万用表量CAN_H和CAN_L之间的电阻。正常工作且两端有120欧终端电阻的差分阻值应该在60欧左右。测出来是120欧说明只接了一个终端电阻测出来接近0欧说明线缆短路了测出来接近无穷大说明线断了或者终端电阻没焊。接着确认波特率。两台设备波特率必须一致偏差大一点都会导致错误帧不断。最好用CAN分析仪主动发送让板子接收或者由板子发帧给分析仪看哪边能解析出来就知道谁配置不对。再查共地。CAN是差分信号但节点之间仍然需要参考地。如果两块板子各用各的独立电源又没有共地CAN_H和CAN_L之间的共模电压可能超出收发器容忍范围表现就是时通时不通。最后是初始化顺序问题。如果代码里先把CAN设备open了但过滤器或波特率还没配好就开始接收数据容易导致第一波帧丢失。我建议初始化全部配置完成后再开接收回调。6.2 错误帧不断刷屏的定位错误帧刷屏是CAN调试里最烦的问题。我先看错误计数器很多CAN控制器寄存器里能读取TEC和REC。如果REC一直增长说明本节点一直在收到坏帧如果TEC增长说明本节点发送失败。最常见的原因是采样点偏差。特别是在不同厂家设备混用、线缆长度不一致的现场A设备采样点75%B设备采样点80%看起来都正常组合在一起就随机出错。这时候统一各节点的采样点或者微调采样点到75%附近一般能解决。再有一个高发因素是终端电阻老化或者松动导致总线反射。现场机柜有振动螺丝端子容易松。我排查错误帧时也习惯带上CAN分析仪分析仪上通常会直接统计错误帧类型。如果大量CRC错误优先怀疑采样点或干扰如果是格式错误可能某个节点波特率配置完全不同。6.3 高负载下丢帧怎么办高负载下丢帧不能只怪硬件软件设计也要背锅。第一提高处理效率。把接收回调里的数据通过消息队列交给线程处理回调里尽量别做耗时的协议解析更别用printf。我在调试阶段用rt_kprintf打印每帧数据每秒几十帧还行每秒几千帧直接进中断嵌套和严重丢帧。实际项目里我都是接收线程把数据包成结构体攒批上报。第二优化总线利用率。如果负载率已经高于50%先尝试把周期帧错峰发送不要让所有节点在同一时刻集中爆发。再不行就提高波特率从250K提到500K很多老节点并不支持1M要向现场设备确认。第三定时器触发发送比在while循环里用delay更准。我这块板子用的是RT-Thread定时器把周期帧发送放到软件定时器回调里配合实际发送完成信号量节奏会稳定很多。关于错误恢复我还会加一层“站看门狗”如果CAN设备进入bus-off驱动会在底层自动请求协议控制器复位。应用层再定时检查是否有收帧连续几秒没收到对设备心跳就主动报警并重新初始化CAN控制器。最后再分享一个不算写文档时会写的细节整个排障过程里最有价值的工具不是示波器而是带CAN协议解析的USB分析仪。示波器只能看到波形分析仪直接帮你看懂帧ID、数据、错误类型。你要是打算长期做CAN相关开发买一台支持的协议分析仪投入产出比极高。
