CAN总线协议详解：从物理层差分信号到采样点配置与工程实践

1. 内容整体设计与思路拆解

CAN，全称Controller Area Network，控制器局域网络。做嵌入式或者汽车电子的人，对这三个字母再熟悉不过。不管是车身控制、电池管理、电机驱动，还是一些工业自动化设备，几乎所有需要多个节点可靠通信的场景，CAN总线都是绕不开的选择。我最早接触CAN是在一个电机控制项目里，当时对它的认识还停留在“两根线、差分信号”的层面，等到真正去调试多节点通信、处理总线错误、优化波特率采样点的时候，才发现这玩意儿远比想象中讲究。

这一篇算是【通信协议】系列的第二篇，不打算把事情讲得太玄乎，核心是解决三个问题：CAN到底怎么把数据送出去的、帧里面每个bit到底在干什么、以及实际做项目时容易踩哪些坑。内容范围涉及CAN 2.0协议（标准和扩展帧）、物理层差分信号、位定时和采样点配置、总线仲裁机制、常见的控制器选择与调试方法。适合正在学习嵌入式通信协议、第一次在项目里用CAN、或者用了一段时间但对底层细节还比较模糊的朋友参考。

CAN协议厉害的地方在于：它不是我发你收那种简单的一对一通信，而是真正的多主总线。总线上任何节点都可以随时发起发送，靠一套巧妙的设计解决“大家都想发”的冲突问题。不需要主机调度，不需要复杂的令牌机制，所有仲裁都在硬件层面完成，软件上你只管把数据填进发送结构体，剩下的交给控制器。这种设计让它的实时性和可靠性在工业环境里非常耐打，也是为什么从1991年Bosch正式发布CAN 2.0规范到现在，这么多年过去它依然活跃在各类项目里的根本原因。

2. 核心细节解析与实操要点

2.1 物理层：为什么是两条线

CAN总线的物理层，看起来就是两根线，CAN_H和CAN_L，终端各接一个120Ω电阻。很多人刚接触时会困惑：UART只有一根TX一根RX，SPI有SCLK、MOSI、MISO至少三根，CAN怎么就两根？答案在于差分信号。

差分信号的核心思想是：信息不在某一根线上高低电平的绝对值里，而在两根线的电压差里。发送1时，CAN_H和CAN_L都被驱动到2.5V左右，差分电压为0V，叫隐性位；发送0时，CAN_H被拉高到3.5V，CAN_L被拉到1.5V，差分电压约2V，叫显性位。网上很多资料把它形容成“两根线扭在一起，共同抵抗干扰”，实际就是这个意思——外部电磁干扰通常会同时作用在两根线上，差分电压不受影响，接收端用比较器只认差值。

那120Ω终端电阻是怎么回事呢？高速CAN总线的规范里，要求总线两端各接一个120Ω电阻，并联起来是60Ω左右，用于匹配总线特性阻抗，避免信号反射。还记得数字电路课上讲过的阻抗匹配吗？CAN总线在1Mbps速率下，信号边沿很陡，如果总线末端不匹配，反射信号会导致某个节点采到的电平出错，轻则偶尔出现错误帧，重则通信直接瘫痪。很多初学者只在收发器附近接了一个120Ω电阻，甚至没接，看似通信正常，实际上信号反射问题被波特率不高给掩盖了，一提到高速就容易翻车。

2.2 CAN帧结构：从SOF到ACK每一个bit都有说法

CAN 2.0规范里定义了四种帧：数据帧、远程帧、错误帧和过载帧。日常通信最常用的就是数据帧，可以分成标准帧和扩展帧两种形式。标准帧ID为11位，扩展帧ID为29位。很多人对这部分最头疼的就是位顺序和填充规则，其实抓住一条主线就好——CAN帧从SOF开始，每一个字段都是按bit顺序在总线上传输的。

标准数据帧结构，一个field一个field过一遍：

• SOF（Start of Frame）：1位显性，宣告总线从空闲变成忙碌状态
• ID（Identifier）：11位，用于标识消息的优先级，ID值越小优先级越高
• RTR（Remote Transmission Request）：1位，数据帧为显性，远程帧为隐性
• IDE（Identifier Extension）：1位，标准帧为显性
• DLC（Data Length Code）：4位，表示数据长度，0到8字节
• Data：0到8字节数据
• CRC（Cyclic Redundancy Check）：15位，再加上CRC分隔位的隐性电平，用于错误检测
• ACK：2位，发送节点在ACK槽位发送一个隐性位，任何收到正确帧的节点都可以在ACK槽位写显性位表示确认；ACK分隔位为隐性
• EOF（End of Frame）：7位隐性，表示帧结束

你有没有注意到一个细节：RTR位之后还有IDE位？标准帧和远程帧的区分方式，除了RTR之外，还有扩展帧里的SRR、IDE和RTR位之间的关系。扩展帧使用了29位ID，结构上多了SRR（替代远程请求位）和更长的ID字段。SRR位是隐性位，在标准帧中不存在这个位，它存在的意义是为了让标准帧和扩展帧在仲裁时保持兼容。

这里要重点聊一下位填充机制。CAN总线规定，在SOF到CRC段之间，如果出现了连续5个相同电平的位，就必须插入一个相反电平的填充位。为什么？因为接收节点需要靠电平跳变来同步时钟。如果长时间没有跳变，即使发送端和接收端用的是同一个标称波特率，实际晶振误差累计起来，就会导致采样点偏移，最终采样错误。位填充保证了总线上每隔最多5个bit必然有一次跳变。EOF之后的7个隐性位不算在位填充范围内，所以错误帧和过载帧不会被填充规则干扰。

2.3 帧ID、过滤器与掩码：并不是所有报文都得收

理解帧ID是理解CAN应用层的第一步。ID不是源地址也不是目的地址，而是消息的标识符，代表这条消息的内容和优先级。在一条总线上，发动机转速、电机扭矩、电池电压、车门状态这些信息各自都有独立的ID。节点发送时并不需要知道谁会接收，接收节点只需要通过验收过滤器决定要不要处理这条消息。

硬件过滤器的逻辑并不复杂，核心是两个寄存器：验收码寄存器和验收掩码寄存器。掩码位为1表示对应的ID位必须精确匹配，为0表示不需要匹配。举个例子，如果掩码是0xFF0，意味着ID的高11位里，高8位必须匹配，低3位不管。这样一条总线上的节点A只关心ID为0x101到0x107的报文，节点B只关心0x181到0x18E的报文，就可以通过掩码把无关中断全部滤掉，显著降低MCU的负载。我见过一些项目图省事，把过滤器置为接收所有帧，然后软件里再根据ID做判断，数据量小的时候感觉没问题，一旦总线繁忙，CPU频繁进中断，很容易拖垮实时性。

2.4 总线仲裁：凭什么是它先发

仲裁机制是CAN协议的精华，也是不少人理解上的难点。多节点同时发送时，总线如何决定谁先谁后？简单说：在ID段，每个发送节点在发送每一位的同时监听总线电平。如果自己发送的是隐性位（1），而总线上检测到显性位（0），说明有优先级更高的节点在发送，自己立刻退出仲裁，转为接收模式。这就意味着ID值越小，显性位出现得越早，优先级越高。

很多人会问：如果完全相同的ID同时发送怎么办？两个节点的RTR位和IDE位也相同时，数据场段的内容是逐字节比较的，如果数据内容也完全一致，从协议层面它们并不是“两个不同消息”，而是同一个消息在总线上被重复发送。真正需要区分的是在ID不相同的情况，仲裁规则是公平且确定的，整个过程中没有任何一个节点被“问询”或“调度”，硬件自己就协调好了。这种分布式仲裁方式，让CAN在恶劣环境下的实时表现优于很多需要主机轮询的总线协议。

3. 实操过程与核心环节实现

3.1 波特率与位定时：采样点到底落在哪

搞CAN项目，第一步通常是定波特率。常见的速率有125Kbps、250Kbps、500Kbps、1Mbps。但光有波特率不够，落地到具体芯片上，还需要把波特率折算成节拍，也就是Time Quantum（Tq）。一个bit的时间被拆分成若干个Tq，分配成同步段（Sync_Seg）、传播段（Prop_Seg）、相位缓冲段1（PS1）和相位缓冲段2（PS2）。

同步段固定为1 Tq，用于检测跳变沿。传播段用于补偿总线上物理延迟。PS1和PS2配合重同步跳转宽度（SJW），决定了采样点的位置。采样点就是接收节点真正读取总线电平的那个时间点，通常建议设置在75%到85%之间。如果是500Kbps，一个bit 2μs，采样点设在80%，意味着在1.6μs处采样。

这个位置为什么这么讲究？总线上的信号从发送节点传播到接收节点需要时间，如果采样点太靠前，可能还没等到信号稳定就把上一个bit的残余电平当成有效数据；如果太靠后，离下个bit的跳变太近，又容易被边缘抖动干扰。可以根据项目中总线长度和节点数微调。简单场景，比如台式机上一个USB-CAN分析仪接一个节点，几十厘米的总线，采样点靠前影响不大。但如果是车载总线，线束好几米长，分布电容大，速率又高，采样点的位置基本决定了一个CAN方案的成败。

几个常用波特率下的参数配置（以常见MCU的CAN控制器为例，总线时钟假设为36MHz）：

实际配置时不能用我这几个数字直接抄。你需要根据自己的MCU外设时钟频率重新计算。核心思路是：先确定总线波特率，算出每bit需要的Tq数量，再按经验比例分配PS1和PS2。总Tq数建议至少8个以上，太少的话采样点可调范围很小，容错能力差。

3.2 收发器选型与外围电路

CAN控制器负责协议层的组帧、错误检测和仲裁，但它输出的不是差分信号，而是普通的TTL电平。真正和总线打交道的是收发器（Transceiver）。常见的收发器有TJA1050、TJA1051、PCA82C250等。选择收发器时主要看两个指标：支持的最高速率和待机功耗。普通的TJA1050支持到1Mbps，经典款，可靠性高，很多开发板上用的就是它。如果项目对低功耗有严苛要求，可以考虑带待机模式的型号，平时进入待机，需要通信时才唤醒。

外围电路也有讲究。CAN_H和CAN_L并不是直接连到总线端子就完事，还需要在靠近收发器的地方接共模扼流圈、滤波电容和ESD保护器件。很多电动工具、农机和车载项目要在电磁环境很差的条件下工作，ESD保护器件就像给收发器穿了一层铠甲，静电打进来先被泄放掉，避免收发器直接报废。

接终端电阻的位置是另一个高频坑点。很多参考原理图上直接把120Ω电阻画在收发器旁边，这在只有两个节点且距离很近的场合是可以的。但如果节点数量多、总线距离长，终端电阻应该接在总线物理拓扑的两端，而不是每一个节点都接。每个节点都接120Ω的话，并联阻抗远远低于标准值，总线差分电平会被拉低，接收端可能无法识别显性位。最简单实用的做法是：确定总线的两个末端节点，在这两个节点上启用终端电阻，中间节点不要启用。

3.3 用上位机工具做一次完整的收发过程演示

协议这东西，只看书容易犯迷糊，上手走一遍就通透多了。这里演示一个最基础的操作流程：用USB-CAN分析仪连接两个CAN节点，让其中一个节点周期发送数据，另一个节点接收并通过串口打印。

第一步，连接硬件。USB-CAN分析仪一端插电脑，一端接CAN总线。分析仪手动设置波特率，比如500Kbps。如果总线另外一端还接了某个开发板，确认开发板上的终端电阻配置，避免两端都有120Ω导致负载过重。

第二步，在电脑端工具里打开“报文发送”界面，填入帧ID、数据长度和数据内容。先发一帧标准帧，ID设为0x123，数据8个字节，内容从0x01到0x08。点击发送后，在接收区可以看到同样的帧被回显，ID、DLC、Data完全一致。这说明两个节点之间基本链路没有问题了，收发器、终端电阻、波特率配置都是对的。

第三步，给一个节点增加一点工作量，让它以10ms的周期循环发送多帧不同ID的数据，观察电脑端接收区的时间戳。正常情况下，每帧之间的时间间隔应该稳定在10ms左右。如果间隔忽大忽小，问题大概率出在发送节点的软件流程上，比如有其他高优先级中断在抢占时间。

第四步，引入一位干扰者——在总线上人为制造一次干扰，比如总线短路一瞬，或者高速通断电源。观察分析仪的错误统计窗口，你会看到错误帧计数增加、总线恢复的波形过程。这一步能让你真正理解CAN的“自愈”能力是怎么运作的，也能让你知道总线状态在出问题时是什么表现。

这个演示实际上已经把CAN通信闭环的每一步都串联起来了：数据从MCU进控制器，控制器打包成帧，收发器转成差分信号，总线传输，另一个节点的收发器把差分信号还原成TTL，控制器解帧，MCU读走数据。任何一个环节出了问题，总线通信都不会正常。

3.4 一个基于现有MCU平台的CAN外设初始化参考流程

很多MCU的CAN外设初始化流程是大同小异的，无非是走到不同芯片厂商的库函数里换名字而已。手动配置CAN，不用额外引入复杂的库依赖，反而更容易暴露问题的本质。一个标准的初始化流程应该包括：

第一步，打开CAN外设所在的时钟，配置复用引脚。这一步常见错误是把CAN的TX/RX引脚复用错了，导致数据根本出不去。务必对照原理图确认引脚编号和复用功能号。

第二步，初始化CAN控制器，配置工作模式，比如正常模式、环回模式（Loopback）或者静默模式。环回模式特别适合初期的软件自测：发送的帧不需要走外部总线，控制器内部自动回环，如果自己收到的数据和发出去的一致，说明控制器的收发通路没问题。注意环回模式下外部其他节点是收不到你的帧的，要和外部联调时记得切回正常模式。

第三步，设置波特率相关寄存器，计算位时序。这一步参考上一节说的方法，根据外设时钟频率和期望的波特率反推预分频值和各个段的Tq计数。

第四步，配置验收过滤器和掩码。可以先配置成接收所有帧，方便调试，跑通之后再做精细的过滤。

第五步，使能中断，注册中断服务函数，在中断里根据中断标志判断是接收到了新帧、发送完成，还是出现了错误状态。错误中断和接收中断要分清，不然很容易出现“我明明收到数据了为什么不进中断”的困惑——因为对应的接收FIFO的pending位没有清除。

// 伪代码示例，展示CAN初始化时位定时的计算思路 // 假设MCU外设时钟CAN_CLK = 36MHz，目标波特率500Kbps #define CAN_CLK_HZ 36000000UL #define TARGET_BAUDRATE 500000UL // 每个bit的Tq数，建议配置在8到25之间 #define TQ_PER_BIT 18 // 根据Tq数计算预分频值 #define BRP ((CAN_CLK_HZ / TARGET_BAUDRATE) / TQ_PER_BIT) - 1 // 采样点约78%，Sync_Seg=1, Prop_Seg=2, PS1=5, PS2=12

上代码只是为了展示参数推算的逻辑，具体到你手头的MCU，寄存器的位段名字各不相同，但思路是完全一致的。

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

4.1 总线无响应，先别怀疑控制器坏了

很多人的第一块CAN板子调试经历都是这样的：写好初始化代码，烧进去之后发现什么反应都没有，分析仪上收不到任何数据。第一反应通常是“是不是我的代码写错了”“是不是开发板的CAN芯片烧了”。实际上，通信完全无响应时，优先级最高的排查对象是物理链路本身。

第一步，用示波器量收发器TXD引脚和CAN_H/CAN_L之间的波形。如果TXD有数据翻转方波，而CAN_H和CAN_L之间没有差分信号，问题大概率出在收发器侧的供电或外围电路上。第二步，测一下总线两端终端电阻，正常应该测到60Ω左右（两个120Ω并联），如果测到120Ω说明只有一端接了终端电阻，如果接近0Ω说明总线被短路了。第三步，检查CAN_H和CAN_L是不是接反了。总线收发器通常都有内部极性保护，但接反之后差分信号为反向的，接收端只会看到连续的错误电平，效果和没接一样。

4.2 偶发错误帧，多半是采样点配置问题

比完全无响应更让人头疼的是那种“大部分时间正常，时不时冒一帧错误”的问题。格尔项目里遇到过某个节点在总线上每隔几分钟就报一次BUS_ERROR，用分析仪看波形又找不到明显干扰源，最后发现是这个节点的采样窗口恰好落在了信号边沿附近——也就是说该节点的采样点设置得太靠后了，在另一个节点的信号上升沿发生时正好去读取总线电平。CAN允许的振荡器容差在普通波特率下是足够的，但多个节点的晶振误差叠加后，如果重同步逻辑没有余量，就会在长时间无填充位的段上冒错。解决办法就是把采样点往前挪一点，比如从80%挪到75%再试。

4.3 为什么明明只有一个发送者，总线上还是错误风暴

还有一种很有意思的现象：总线上明明只有一个节点在周期发送数据，也没有其他干扰者，但总线上还是不停出现错误帧。排除波特率配错之后，就要想想这个节点的收发器是否被损坏了。收发器损坏后的典型表现是CAN_H或CAN_L引脚对地呈短路状态，总线差分电压被拉偏。这种故障用万用表量总线电压，正常时静态应在2.5V左右，故障时会发现一根线被拉到接近0V或5V。我遇到过几次收发器烧掉的场景，都是在带电插拔总线连接器时发生的。所以CAN节点之间如果要带电连接，要么先停机，要么在连接器上做好热插拔保护设计。

4.4 快速自查表

4.5 调试CAN时最好用的三板斧

这几条是我踩过很多坑之后体会最深的。

第一，波形大于一切。不要只看逻辑分析仪解码出来的数据，把示波器探头接到CAN_H上，触发设为下降沿，看看波形上有没有明显的台阶、过冲、反射。CAN报文从ID段到EOF，每一位的波形都应该是干净利落的，如果波形上出现台阶，说明阻抗不匹配；如果波形矮了一截，差分电压不足，说明电源或终端电阻有问题。

第二，用好环回模式。很多项目初期节点硬件还没准备好，但CAN外设已经可以单独工作。环回模式可以在不连接外部总线的情况下验证控制器配置是否正确。先通过环回模式把发送、接收、中断、过滤器的代码都调通，再接外部总线联调，把“控制器配置错误”和“物理链路问题”这两类故障分离开来。

第三，持续监控错误状态。CAN控制器都有错误状态寄存器，记录着错误计数器的数值。RXERR和TXERR超过127，控制器就会进入被动错误状态，虽然还能接收但不能主动发送；超过255就直接进入离线状态。调试时定期读取错误计数值，能帮你把问题定位到具体方向。

5. 项目中的选型思路与再进一步的扩展

在实际项目里选CAN方案，要考虑的不只是“能不能通信”，还包括网络管理、诊断、升级、多节点数量、成本和对开发效率的影响。很多项目里不止一块MCU，可能负责控制的、负责采样的、负责显示的各自都带CAN外设。这时候选型要预判一下总线上有多少节点、报文周期是多少、每个节点有多少数据要上报。

如果是入门学习或者快速验证想法，直接用最常见的开发板和USB-CAN分析仪就够了，不需要太复杂的工具。但如果涉及汽车诊断或标定，那就得考虑把通信协议栈跑起来，与传统UDS诊断、XCP标定等功能结合。具体选择取决于产品阶段和项目预算，我在这里不冒然推荐具体牌子。

协议层面的考虑也要兼顾。CAN 2.0只是一层传输手段，节点与节点之间消息怎么定义、心跳怎么发、错误后什么时候重试，这些应用层规则才是项目稳定性的分水岭。我看到过很多项目，选型时只关注“有没有CAN外设”，忽略了应用层的规划，最后总线一忙起来就乱成一团。反过来，有些项目硬件上用的芯片不算顶级，但应用层设计合理，比如分优先级ID、控制重试次数、合理设置报文周期，整体稳定性反而很好。

另外提一点个人经验：如果总线节点数量比较多，比如超过十个，建议把总线上的报文周期按“快周期、中周期、慢周期”分开规划。快周期（10ms级）给最关键的实时控制信号，中周期（50ms到100ms）给状态刷新，慢周期（1s及以上）给参数报告类报文。这样既保证了核心数据的实时性，又不至于让总线永远处于满负载状态。总线负载率保持30%到50%是健康水平，超过70%就要认真审查报文周期了。

说到扩展，CAN FD是CAN 2.0之后的一个重要方向。CAN FD把单帧数据长度从8字节扩展到64字节，数据段的波特率可以比仲裁段高很多，比如仲裁段500Kbps，数据段2Mbps甚至更高。如果项目里有大量批量数据传输的需求，CAN FD能明显降低总线负载。很多新出的MCU已经原生支持CAN FD，软件开发上和老CAN差别也不大，未来做新项目可以优先考虑。

这几年的实际感受是，CAN协议虽然“老”，但它在工业领域的地位非常稳。它的意义不在于传输速度多快，而在于在强干扰、长距离、多节点的恶劣条件下，还能保持可靠通信。理解了CAN的核心机制，再去学习CAN FD、CANopen、J1939这些上层协议会轻松很多，因为它们都是基于同样扎实的物理和链路基础之上生长出来的。