1. CAN总线技术本质与工程定位

CAN（Controller Area Network）不是一种“用起来很方便”的外设，而是一套完整的、面向严苛工业场景的通信体系。它诞生于汽车电子领域，核心诉求是解决分布式ECU之间高可靠性、强实时性、抗干扰能力的通信问题。在哈工大深圳南工骁鹰机器人队的实际电控系统中，CAN常用于电机驱动器（如AS5048、BLDC控制器）、IMU模块、电池管理系统（BMS）等关键子系统之间的数据交互。理解CAN，绝不能停留在“复制粘贴一段初始化代码就能发数据”的层面——当电机指令丢失、编码器反馈跳变、多节点通信出现随机丢帧时，所有表象问题都必须回归到物理层信号完整性、数据链路层仲裁机制、应用层协议设计这三个维度进行根因分析。

CAN的复杂性不在于寄存器配置有多繁复，而在于其协议栈深度嵌入了硬件行为。一个HAL_CAN_Transmit()调用背后，是CAN控制器自动执行位填充、CRC校验、错误帧检测、重传仲裁的全过程；一次总线错误中断触发，可能关联着终端电阻缺失、线缆阻抗不匹配、节点时钟偏移超标等底层物理问题。因此，本节内容不提供“速成模板”，而是构建一条从电气特性→协议机理→寄存器映射→故障排查的完整技术链条，目标是让工程师在示波器上看到CAN_H/CAN_L差分波形时，能立即判断出显性/隐性电平是否正常，能通过逻辑分析仪捕获的报文ID推断出当前总线仲裁状态，能在CubeMX生成的初始化代码基础上，精准修改BSR（Bit Timing Register）中的SJW、TSeg1、TSeg2参数以适配不同波特率需求。

2. 物理层：差分信号与总线拓扑的硬约束

CAN物理层采用双绞线差分传输，这是其抗共模干扰能力的根本保障。标准定义两条信号线：CAN_H（CAN High）和CAN_L（CAN Low）。逻辑状态不由单线对地电压决定，而由两线间电压差（ΔV = V CAN_H - V CAN_L ）判定：

  • 显性电平（Dominant） ：ΔV ≥ 0.9V，对应逻辑‘0’。此时CAN_H被驱动至约3.5V，CAN_L被拉低至约1.5V，形成2V压差。
  • 隐性电平（Recessive） ：ΔV ≤ 0.5V，对应逻辑‘1’。此时两线均处于约2.5V（典型值），压差趋近于0。

这种设计带来两个关键工程特性：
第一， 显性优先的线与逻辑 。当多个节点同时驱动总线时，只要有一个节点输出显性电平，整条总线即被强制为显性。这与I²C的开漏结构类似，但实现机制不同——CAN依靠收发器内部的晶体管开关直接钳位电压，而非外部上拉电阻。这意味着总线无需主从角色预设，任何节点均可在任意时刻发起通信，天然支持多主架构。

第二， 严格的终端匹配要求 。高速CAN（ISO 11898-2）必须在总线两端各接入一个120Ω终端电阻，构成典型的双端接匹配结构。该电阻值并非随意指定，而是精确匹配双绞线的特征阻抗（Z₀ ≈ 120Ω）。若仅一端接电阻，信号在未匹配端发生全反射，导致边沿振铃；若完全不接，则反射波叠加在原始信号上，造成位宽失真。在机器人电控板PCB布局中，终端电阻必须紧邻CAN收发器（如TJA1050、SN65HVD230）的CAN_H/CAN_L引脚放置，走线长度严格控制在≤10mm，避免引入额外阻抗不连续点。

低速容错CAN（ISO 11898-3）采用单线+地线结构，每节点需在CAN_H和CAN_L线上各串联一个2.2kΩ电阻，形成开环总线。其优势在于单线断裂时仍可维持通信，但速率上限仅125kbps，且抗干扰能力弱于高速CAN。在实际机器人项目中，除非工作环境存在极端电磁干扰（如大功率电机启停瞬间），否则应优先选用高速CAN方案。

3. 数据链路层：报文结构与仲裁机制的硬件实现

CAN报文并非简单的“地址+数据”包，而是将通信意图深度编码在帧结构中。标准帧（11位ID）与扩展帧（29位ID）的核心差异在于标识符长度，但二者共享相同的仲裁逻辑。以标准数据帧为例，其结构分解如下：

字段 长度 功能说明
起始域（SOF） 1 bit 显性电平，标志帧开始，所有节点同步于此
仲裁域（Arbitration Field） 12-32 bits 包含11/29位标识符（Identifier）和RTR位（远程请求）
控制域（Control Field） 6 bits IDE（标识符扩展）、r0（保留位）、DLC（数据长度码，0-8字节）
数据域（Data Field） 0-64 bits 实际载荷，长度由DLC决定
CRC域（CRC Field） 15 bits + 1 bit delimiter 循环冗余校验，覆盖SOF至数据域末尾
应答域（ACK Field） 2 bits 发送节点输出隐性电平，接收节点正确接收后覆写为显性
帧结束（EOF） 7 bits 全隐性电平，标志帧终止

其中， 仲裁域是整个CAN协议的智能中枢 。当多个节点同时开始发送时，它们会边发送边监听总线电平。由于显性电平具有线与优先权，ID数值小的节点（二进制高位为0）在仲裁段首比特即输出显性，而ID大的节点（高位为1）检测到总线为显性，立即停止发送并转入接收模式。这一过程在硬件内完成，耗时仅数个位时间（bit time），无需CPU干预。例如，ID=0x100的节点与ID=0x101的节点竞争，当发送至第9位（从0计数）时，前者发送‘0’（显性），后者发送‘1’（隐性），后者立即感知冲突并退出——这就是“非破坏性逐位仲裁”。

在STM32F4系列MCU中，这一机制由bxCAN（Basic CAN）控制器固化实现。其关键寄存器包括：
- CAN_FMR （Filter Master Register）：全局滤波器使能控制
- CAN_FA1R （Filter Activation Register）：单个滤波器激活位
- CAN_FS1R （Filter Scale Register）：设定滤波器宽度（32位/16位）
- CAN_FiR （Filter Bank Register i）：存储滤波器ID及掩码

滤波器并非“白名单”，而是通过ID与掩码的按位与运算实现匹配。例如，设置滤波器ID=0x200，掩码=0x7F0，则接收ID范围为0x200~0x20F（低4位可变）。这种设计允许单个滤波器覆盖连续ID区间，大幅降低资源消耗。

4. STM32 HAL库下的CAN初始化全流程解析

在STM32F4平台使用HAL库配置CAN，需严格遵循时钟树依赖关系。CAN控制器挂载在APB1总线上，其时钟源为PCLK1（通常为42MHz）。波特率计算公式为：

Bit Rate = PCLK1 / [(BRP + 1) × (TSeg1 + TSeg2 + 3)]

其中：
- BRP ：波特率预分频器（CAN_BTR[9:0]）
- TSeg1 ：传播段+相位缓冲段1（CAN_BTR[15:12]）
- TSeg2 ：相位缓冲段2（CAN_BTR[20:18]）
- SJW ：再同步跳转宽度（CAN_BTR[23:22]）

以常用波特率1Mbps为例（PCLK1=42MHz）：
- 目标位时间 = 1μs → 总时间量子（TQ）数 = 42MHz × 1μs = 42
- 设定BRP=3 → TQ数 = 42/(3+1) = 10.5 → 取整为10或11
- 若取TQ=10，则TSeg1+TSeg2+3 = 10 → 设TSeg1=6, TSeg2=1, SJW=1（满足SJW ≤ min(TSeg1, TSeg2)）

CubeMX生成的初始化代码中， hcan.Init.Prescaler = 3; 对应BRP=3； hcan.Init.TimeSeg1 = CAN_BS1_6TQ; 即TSeg1=6； hcan.Init.TimeSeg2 = CAN_BS2_1TQ; 即TSeg2=1。这些参数必须与总线最长物理距离匹配：40米以内可稳定运行1Mbps；1000米则需降至125kbps，此时TSeg1需增大至13TQ以上以容纳信号传播延迟。

中断配置是可靠通信的关键。CAN控制器提供三类核心中断：
- CAN_IT_TME （Transmit Mailbox Empty）：发送邮箱空，可触发下帧发送
- CAN_IT_FMP0 （FIFO Message Pending）：FIFO0有新报文到达
- CAN_IT_EWG （Error Warning）：错误计数器超过96，预警总线健康度

在 HAL_CAN_Init() 之后，必须调用 HAL_CAN_ActivateNotification() 使能所需中断，并在 CAN1_RX0_IRQHandler() 中调用 HAL_CAN_RxCpltCallback() 处理接收。此处极易犯错：若未清除中断标志（ __HAL_CAN_CLEAR_FLAG(&hcan, CAN_FLAG_RQRF0) ），会导致中断持续触发，CPU陷入死循环。

5. 应用层协议设计：从裸CAN到可维护系统

直接使用裸CAN ID进行通信在小型系统中可行，但随节点增多必然陷入ID管理混乱。南工骁鹰机器人队采用分层ID编码策略，将29位扩展ID划分为功能域、设备域、命令域三部分：

| 28-24 | 23-16 | 15-8 | 7-0 |
|-------|--------|------|-----|
| 主机类型 | 设备地址 | 命令类型 | 数据索引 |

例如，电机控制器上报位置数据的ID为 0x18010001 ：
- 0x18 ：表示“运动控制”主类型
- 0x01 ：电机1号地址
- 0x00 ：位置反馈命令
- 0x01 ：数据序号（区分多周期采样）

此设计带来两大优势：
1. 硬件滤波可编程 ：在CAN初始化时，为每个外设配置专用滤波器。电机驱动器仅接收ID匹配 0x1801xxxx 的帧，忽略IMU、BMS等无关报文，降低CPU负载。
2. 协议可扩展 ：新增传感器只需分配新设备地址（如 0x02 ），无需修改现有节点代码，符合机器人系统模块化演进需求。

数据封装采用紧凑二进制格式，规避ASCII协议的带宽浪费。以电机电流采样为例：
- 原始ADC值：16位有符号整数（-32768 ~ +32767）
- 缩放因子：1A = 100单位（即0.01A/LSB）
- 封装为2字节： data[0] = (int16_t)current & 0xFF; data[1] = ((int16_t)current >> 8) & 0xFF;

接收端反向解析即可获得物理量。这种设计使8字节数据域可承载4组16位传感器数据，相比JSON等文本协议提升4倍有效带宽。

6. 故障诊断实战：示波器与逻辑分析仪协同分析法

当CAN通信异常时，必须建立“物理层→链路层→应用层”的三级排查路径。以下为南工骁鹰队实测有效的诊断流程：

6.1 物理层验证（示波器）

  • 测试点选择 ：在CAN收发器输出端（非MCU引脚）测量CAN_H与CAN_L波形
  • 显性电平 ：应观测到清晰方波，上升/下降时间≤200ns（1Mbps时）
  • 隐性电平 ：两线电压差应≤0.5V，且无明显振荡
  • 常见故障现象 ：
  • 无信号输出：检查MCU CAN_TX引脚是否配置为复用推挽输出，确认收发器供电（5V/3.3V）正常
  • 边沿严重过冲：终端电阻缺失或位置错误，双绞线未绞合导致阻抗突变
  • 隐性电平漂移至1.5V：某节点收发器损坏，内部上拉失效

6.2 链路层捕获（逻辑分析仪）

使用Saleae Logic Pro 16等设备，以≥20MHz采样率捕获CAN_H信号：
- 解码报文 ：验证ID、DLC、数据字段是否符合预期
- 定位错误帧 ：观察是否有连续6个显性位（错误标志），其后紧跟8位错误界定符
- 分析仲裁失败 ：若某节点频繁发送失败，检查其ID是否为全1（0x7FF/0x1FFFFFFF），此类ID在仲裁中必然失败

6.3 应用层日志（串口调试）

在 HAL_CAN_RxCpltCallback() 中添加关键日志：

void HAL_CAN_RxCpltCallback(CAN_HandleTypeDef *hcan) {
    CAN_RxHeaderTypeDef rx_header;
    uint8_t rx_data[8];
    HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &rx_header, rx_data);

    // 记录ID与时间戳，用于分析时序
    printf("RX ID:0x%03X DLC:%d TS:%lu\r\n", 
           rx_header.StdId, rx_header.DLC, HAL_GetTick());
}

当发现特定ID报文周期性丢失时，结合逻辑分析仪时间轴，可判断是发送节点软件卡死，还是总线错误率过高导致接收节点进入Bus Off状态。

7. Bus Off状态恢复与鲁棒性增强策略

CAN控制器定义三种错误状态：Error Active（主动错误）、Error Passive（被动错误）、Bus Off（总线关闭）。当发送错误计数器（TEC）≥256时，节点进入Bus Off，自动切断总线驱动，防止故障节点拖垮整个网络。HAL库中 HAL_CAN_GetError() 可读取当前状态，但 自动恢复需手动触发 ：

if (__HAL_CAN_GET_FLAG(&hcan, CAN_FLAG_BOFF)) {
    HAL_CAN_Stop(&hcan);          // 停止CAN外设
    HAL_CAN_Start(&hcan);         // 重启，触发软复位
    __HAL_CAN_CLEAR_FLAG(&hcan, CAN_FLAG_BOFF); // 清除标志
}

更优方案是启用自动恢复模式（Auto-Wake-Up），在 hcan.Init.Mode = CAN_MODE_NORMAL; 后添加：

hcan.Init.AutoBusOff = CAN_AUTO_BUSOFF_DISABLE; // 默认禁用
// 启用后，硬件在检测到128个隐性位后自动退出Bus Off

为提升系统鲁棒性，南工骁鹰队在电机控制环路中实施双保险：
- 硬件看门狗 ：独立于CAN的外部WDT芯片（如MAX6375），监控MCU心跳信号
- 软件超时 ：在FreeRTOS任务中设置接收超时，若50ms未收到电机反馈，则强制停机并置位故障标志

这种设计确保即使CAN总线完全瘫痪，系统仍能安全停机，符合机器人功能安全基本要求。

8. 实战代码精要：电机CAN通信核心函数

以下代码基于STM32F407VG与TJA1050收发器，经南工骁鹰队2023赛季实测验证。重点在于 资源隔离 与 错误隔离 ：

// 电机发送函数：采用双缓冲机制，避免发送阻塞
typedef struct {
    uint32_t id;
    uint8_t data[8];
    uint8_t dlc;
} can_tx_msg_t;

static can_tx_msg_t tx_buffer[2] = {0}; // 双缓冲
static volatile uint8_t tx_head = 0, tx_tail = 0;

HAL_StatusTypeDef motor_can_send(uint32_t std_id, uint8_t *data, uint8_t len) {
    if (len > 8) return HAL_ERROR;

    uint8_t idx = tx_head;
    tx_buffer[idx].id = std_id;
    tx_buffer[idx].dlc = len;
    memcpy(tx_buffer[idx].data, data, len);

    tx_head = (tx_head + 1) % 2;

    // 触发发送（非阻塞）
    CAN_TxHeaderTypeDef tx_header;
    tx_header.StdId = std_id;
    tx_header.IDE = CAN_ID_STD;
    tx_header.RTR = CAN_RTR_DATA;
    tx_header.DLC = len;

    uint32_t tx_mailbox;
    return HAL_CAN_AddTxMessage(&hcan, &tx_header, data, &tx_mailbox);
}

// 接收回调：严格校验ID，丢弃非法报文
void HAL_CAN_RxCpltCallback(CAN_HandleTypeDef *hcan) {
    CAN_RxHeaderTypeDef rx_header;
    uint8_t rx_data[8];

    HAL_CAN_GetRxMessage(hcan, CAN_RX_FIFO0, &rx_header, rx_data);

    // ID合法性检查：仅处理0x1801xxxx范围
    if ((rx_header.StdId & 0xFFFF0000) != 0x18010000) {
        return; // 丢弃未知ID，避免污染状态机
    }

    // 解析电机状态（示例：字节0-1为电流，2-3为温度）
    int16_t current = (int16_t)(rx_data[0] | (rx_data[1] << 8));
    uint16_t temp = (uint16_t)(rx_data[2] | (rx_data[3] << 8));

    // 更新本地状态
    motor_state.current = current * 0.01f; // 转换为安培
    motor_state.temperature = temp * 0.1f;   // 转换为摄氏度
}

该实现规避了常见陷阱：
- 不在中断中执行浮点运算（ *0.01f 移至主循环）
- 不在回调中调用 HAL_Delay() 等阻塞函数
- 双缓冲设计确保高频率发送（如PID控制周期1ms）不丢失指令

9. 学习资源与工程实践建议

CAN协议文档（ISO 11898-1）晦涩难懂，建议按此路径渐进学习：
1. 入门 ：Bosch官方《CAN Specification 2.0》第1-3章，重点理解位定时、错误帧结构
2. 实践 ：ST官方应用笔记AN1091《CAN communication with STM32 microcontrollers》，含完整CubeMX配置截图
3. 深度 ：《Embedded Networking with CAN and CANopen》（Korenke著），详解对象字典与NMT状态机

在机器人项目中，务必遵守三条铁律：
- 绝不省略终端电阻 ：即使实验室测试仅用两块开发板，也必须安装120Ω电阻。曾有队员为“简化布线”拆除电阻，导致100kbps下误码率达10⁻³，调试耗时两天。
- ID规划前置 ：在电路设计阶段即确定所有节点ID，写入硬件BOM表，避免软件开发后期ID冲突。
- 总线负载率≤70% ：计算公式为 Σ(帧长×频率)/波特率 。例如，10个节点各以100Hz发送8字节帧（含开销共108位），在500kbps下负载率为 (108×100×10)/500000 = 21.6% ，留足余量应对突发流量。

CAN的本质是“用硬件逻辑替代软件协议”，它的优雅在于将复杂的冲突检测、错误恢复、消息路由全部固化在硅片中。当工程师能看着示波器上的差分波形，脑中自然浮现仲裁过程的比特流比对，那一刻，才真正握住了这个控制器局域网的灵魂。

Logo
openvela

openvela 操作系统专为 AIoT 领域量身定制，以轻量化、标准兼容、安全性和高度可扩展性为核心特点。openvela 以其卓越的技术优势，已成为众多物联网设备和 AI 硬件的技术首选，涵盖了智能手表、运动手环、智能音箱、耳机、智能家居设备以及机器人等多个领域。

更多推荐

cover

Arm Ethos‑U65：YOLOv8n 模型准备与 Vela 编译

avatar openvela
cover

开源新纪元：深度解析小米 MiMo Code 的技术架构与实战应用

avatar openvela

UniAD_v2 模型NPU适配

参考github网址：https://github.com/OpenDriveLab/UniAD/tree/v2.0参考readme：https://gitcode.com/Ascend/DrivingSDK/blob/master/model_examples/UniAD/README.md。

avatar openvela