企业官网建设流程全解析

聊CAN技术之前，我想先抛一个问题：你手里有一个项目，要用总线把十几个节点串起来通信，你第一个想到的方案是什么？大概率是CAN，对吧？但真到了选型环节，很多人会卡壳——经典CAN、CAN FD、CANopen、J1939，甚至还有人在CAN和LIN、CAN和FlexRay之间反复横跳。我这些年折腾过车载ECU、机器人的伺服驱动、工控IO模块，可以说每一种CAN技术都在实际项目里踩过坑、填过土，也踩过不少“看着一样、用起来完全不是一回事”的坑。这篇东西就是把“不同CAN技术”拆开揉碎聊一遍，从帧格式的底层差异，到仲裁和错误处理的机制，再到不同场景下到底该选谁，最后附上我自己的排障实录和实测心得。不管你是刚接触CAN的新手，还是已经在用CAN但想转向CAN FD、或者正在纠结上层协议栈怎么选的工程师，这篇文章应该都能给你一个比较清晰的坐标系。

1. 先弄明白CAN家族都有谁：经典CAN、CAN FD和协议栈的关系

1.1 经典CAN 2.0A/2.0B：两种帧格式和它的20年

CAN总线从1986年由Bosch正式提出，到今天快四十年了，但它依然是汽车和工业领域应用最广的现场总线。经典CAN（Classic CAN）通常指CAN 2.0A和CAN 2.0B两个版本，它们之间的核心差异就在帧格式上：CAN 2.0A用11位标识符，也就是标准帧，最多能定义2048个不同报文ID（实际使用还要去掉一些保留位）；CAN 2.0B支持29位标识符，也就是扩展帧，可用的报文ID空间大得多，适合节点数量多、报文类型复杂的场合。

很多初学者会忽略一个问题：CAN 2.0B的控制器完全可以收发CAN 2.0A的帧，只要配置成“扩展帧兼容模式”就行，反过来却不行。比如你用STM32的bxCAN外设，如果只开了标准帧接收，那总线上的扩展帧就会被直接过滤掉，表现为“明明总线上有数据，我的节点却收不到”。这种问题特别隐蔽，我当年调试时就因为忽略了这一条，整整查了半天。

经典CAN的数据场最长是8字节，在波特率500kbps的场景下，一个满载的8字节数据帧大概占用130us左右的总线时间。这个“8字节上限”在很长一段时间里够用，因为早期ECU之间交换的无非是转速、温度、开关状态这类小数据。但随着汽车功能越来越复杂，比如OTA升级、ADAS传感器原始数据传输、多轴伺服的位置和力矩同步，8字节就显得非常局促了。于是就有了CAN FD。

1.2 CAN FD：数据段从8字节到64字节，速率还能飙到8Mbps

CAN FD（CAN with Flexible Data-rate）不是对经典CAN的彻底推翻，而是向后兼容的升级。它保留了两者相同的仲裁机制和帧起始结构，但做了两个关键改动：一是数据场长度从8字节扩展到最多64字节，这对大数据块传输是质的飞跃；二是引入了“位速率切换”机制，在仲裁段用标准速率（比如500kbps），进入数据段后自动切换成更高速度（最高可达8Mbps，实际常用2Mbps或5Mbps）。这样兼容性和传输效率就同时保住了。

这里有个很重要的概念叫“波特率切换点”。CAN FD帧里有一个BRS位（Bit Rate Switch），发送端置这个位为显性，接收端就知道“接下来数据段要用高速率采样”。这意味着你的收发器和控制器的时钟精度必须足够高，否则高速采样时采样点会飘，导致CRC校验失败。实测下来，CAN FD对晶振的要求比经典CAN苛刻不少，经典CAN用精度±0.5%的晶振就能跑，CAN FD在5Mbps数据段时最好用±0.1%甚至更高精度的时钟源。

另外，经典CAN的校验用15位CRC，CAN FD由于数据段长、速度快，改用了更强校验能力的17位或21位CRC（取决于数据长度）。这个设计细节经常被人忽略，但它恰恰是CAN FD能在高带宽下保持可靠性的关键。还有一点：ISO 11898-1:2015标准里定义了CAN FD的两种帧格式——CAN FD不带位速率切换（即整个帧统一用一种速率）和CAN FD带位速率切换。前者主要是给不支持和普通CAN共存的极端场景用的，实际项目中几乎都用后者。

1.3 CANopen、J1939、DeviceNet：为什么协议栈比裸CAN更重要

裸CAN只是定义了“怎么把一段数据从A送到B”，它不关心数据本身代表什么含义。但真实项目里，你总得规定“报文ID 0x231的第2个字节代表目标转速”，这种约定就叫应用层协议。目前最常见的CAN高层协议有三个：CANopen、J1939和DeviceNet。

CANopen基于CAL协议，广泛应用于运动控制、医疗设备、工业自动化。它把每个节点抽象成“对象字典”，通过PDO（过程数据对象）和SDO（服务数据对象）两种机制通信。PDO用于周期性高优先级的数据交换，SDO用于偶发性的配置读写，比如启动时主站通过SDO把从站的PID参数写进去。它的最大优势是标准化程度高，不同厂家的CANopen设备基本能即插即用，这也是它能在工业领域活这么久的原因。

J1939则是面向重型车辆和工程机械的协议，比如卡车、拖拉机、柴油发电机。它在CAN 2.0B的29位扩展帧基础上定义了PGN（参数组编号）、SPN（可疑参数编号）和源地址/目的地址的概念。你去看一辆商用车的OBD诊断口，物理层就是CAN，上层大都是基于J1939的UDS或J1939诊断协议。这里有个记法：J1939的报文优先级占3位，所以优先级从0到7，0最高；PGN占18位，SPN是对具体参数的编号。比如发动机转速对应的SPN是190，车速对应SPN是84。

DeviceNet则是由Rockwell Automation主导的协议，主要在美国市场的工厂自动化里用得多，兼容电气层和CIP协议栈。说实话，在国内的工控项目里，DeviceNet的份额远不如CANopen和Modbus，但如果你做出口美国的OEM设备，绕不开它。它的物理层特色是支持24V供电和信号在同一对线缆上传输，这对现场布线是个不小的便利。

把这三个协议放在一起看，你就能明白一个大原则：底层的CAN收发器和控制器选型可能是通用的，但上层协议直接决定了你的软件架构、设备兼容性和调试工具链。选错协议栈，后面改软件的代价非常大。

2. 拆开CAN最硬核的三个机制：仲裁、错误处理与物理层

2.1 CAN总线仲裁到底怎么工作，为什么会出现仲裁失败

CAN能在一对双绞线上挂几十个节点且不需要主机轮询，靠的是分布式多主访问机制，具体实现叫CSMA/CA，也就是载波监听多路访问/冲突避免。很多人把CAN的仲裁和以太网的CSMA/CD搞混，以太网是“冲突检测”，发现冲突后随机退避重传；CAN是“冲突避免”，仲裁失败的节点自动转为接收模式，等总线空闲再重发。这就是为什么CAN不会像以太网那样随着负载升高出现“碰撞风暴”导致吞吐量骤降。

仲裁的底层原理是“线与”特性加上显性位优先。CAN总线上的电平分显性和隐性两种：显性位对应逻辑0，隐性位对应逻辑1。多个节点同时发送时，只要有一个节点发出显性位，总线电平就是显性。每个发送节点在发送仲裁段每一位的同时会回读总线电平，如果自己发的是隐性位却读到显性位，就说明有更高优先级的节点在竞争，自己立即退出仲裁，转为接收。

那么“总线仲裁失败”是在什么场景下出现的？我排查过几个项目，最常见的原因有两个：一是在不需要“多主”的场合里把多个节点都配成了发送者，且没有合理分配ID优先级，大家抢得不可开交；二是波特率不一致。如果总线上存在两个节点波特率差得比较多，它们的位时序采样点错位，仲裁逻辑就会乱，表现出来就是持续不断的仲裁失败和错误帧。

还有一类仲裁失败值得单独说：CAN FD帧和经典CAN帧混合的总线上，如果经典CAN节点不知道何时跳过CAN FD的数据段，它会在应该采样的地方读到“错误位”，从而触发错误帧，把整条总线拉崩。所以设计混合网络时，必须保证所有节点要么都支持CAN FD，要么用网关隔离，不能天真地把两者直接挂一条线上。

2.2 五种错误与三种状态：CAN的“自我修复”能力

CAN控制器内置了一整套错误检测和故障封禁机制，这也是它能做到“单点失效不影响总线”的根本原因。错误分五种：位错误、填充错误、CRC错误、格式错误、应答错误。位错误最直观——你发的位和回读到的位不一致就报错；填充错误是因为CAN规定连续5个相同电平后必须插入一个反向填充位，如果接收端发现填充规则被破坏就报错；CRC错误就是校验失败；格式错误和应答错误则分别涉及帧格式固定位和ACK时隙。

控制器根据错误计数器（TEC和REC）的数值把自己关进三种状态之一：主动错误、被动错误和总线关闭。错误计数小于127是主动错误，出错时还能主动发错误帧；计数在128到255之间是被动错误，出错时只能发被动错误标志，而且不能再主动发起发送；计数超过255就进入总线关闭，控制器完全脱离总线，不再参与任何通信。这个机制的设计很巧妙：它保证了偶发错误不会立即干掉一个节点，但持续的故障节点会逐渐被“隔离”出去，避免它拖垮整条总线。

调试时有个实用技巧：很多CAN分析仪或调试工具可以直接读TEC和REC计数。如果你看到某个节点持续处于被动错误状态，排查思路就是“这个节点的发送质量有问题”，优先检查它的终端电阻、接插件接触和CAN收发器的共模电压范围。如果多个节点同时出现大量错误帧，那大概率是总线缺少终端电阻或者物理层被干扰了。

2.3 物理层的门道：终端电阻、双绞线，以及“CAN线不够长”的解法

CAN的物理层标准主要是ISO 11898-2，也就是大家常说的“高速CAN”，波特率范围从125kbps到1Mbps（CAN FD可以更高），用两根线CANH和CANL差分传输。差分信号的好处是抗共模干扰能力强，所以CAN才能在汽车这种电磁环境极其恶劣的地方存活。但差分传输也对线缆阻抗有明确要求：标准规定线缆的特征阻抗是120Ω，所以总线两端各需要并联一个120Ω的终端电阻。没有正确端接时，信号会在总线末端反射，表现为波特率高时通信时好时坏，波特率低时看起来又正常。

关于“CAN线不够长”的问题，前阵子还有人问我，说大疆电调的CAN线不够长，能不能自己接一截延长线。我的建议是：能，但要注意几个点。第一，不要用普通跳线或长线直接绕接，CAN线要使用双绞线，而且绞距要尽量均匀，这样才能保证差分信号的质量；第二，延长后的总长度不能超过该波特率下的极限总线长度，经典CAN在500kbps下理论总长是130米左右，在250kbps下可以到250米左右，工程上建议留20%余量；第三，接头处要牢靠，最好用焊接或压接端子，不要用胶布缠。如果延长后出现偶发错误帧，优先在靠近线缆延长处补一个终端电阻调整反射，或者降一档波特率跑。

另外补充一个冷门但实用的知识点：高速CAN的低速容错版叫“容错CAN”，它允许单根线对地短路时继续通信，代价是最高速率只有125kbps。这种CAN在门窗、座椅等车身舒适域里用得多，主要就是看重它的容错能力和更低的线束成本。如果你只是做实验或者学习，用普通的USB-CAN分析仪加两个120Ω电阻和几根双绞线就能搭一套最基础的CAN网络，完全不需要依赖任何专用硬件。

3. 从选型到落地：不同CAN技术的实战选择与一条龙实操

3.1 场景决定技术：机器人、汽车、工控到底该选谁

选型这件事，我的经验是先问自己三个问题：网络上最多挂多少个节点？单个报文最大需要传多少字节？两个节点之间最远距离是多少？这三个答案基本能把技术方向定得八九不离十。

节点数少于32个、单包数据不超过8字节、速率要求不高，经典CAN足够了。很多小型伺服驱动器和PLCIO扩展就是这么做的，成本低、资料多、调起来快。如果你的节点数量到了30到50个，且网络里有数据量大的节点，比如64字节固件升级包、多轴联动的位置数据，那就要考虑CAN FD。CAN FD在2Mbps数据段下的有效吞吐量大约是经典CAN的3到5倍，而且向上的兼容路径很明确——所有的CAN FD控制器都能收发经典CAN帧。

汽车行业目前处在一个过渡期：法规和诊断层面还是以经典CAN为主，比如UDS on CAN的请求和响应都是经典CAN帧，但很多ADAS域控制器内部和传感器之间已经用上了CAN FD甚至车载以太网。如果你是做汽车电子Tier 1供应商的软件开发，我的建议是直接把CAN FD支持做进底层驱动，成本增加很小，但后续扩展空间大得多。工控领域则相反，CANopen的地位暂时很难撼动，因为大量的驱动器、阀岛、传感器都已经在用它，你贸然换协议栈反而会增加设备对接成本。所以结论很简单：没有最好的CAN技术，只有和场景最匹配的CAN技术。

3.2 入门实操：用STM32F429/F103跑通一个CAN通信

STM32家族里的bxCAN外设是很多人学习CAN的第一站，F103用的是第一代bxCAN，F429用的是改进版，两者在寄存器层面有了些差别，但CubeMX里的配置思路是基本一致的。先说几个新手最容易掉进去的坑。

第一坑：波特率算错。bxCAN挂在APB1总线上，F103的APB1默认是36MHz，F429的APB1默认是42MHz（具体看时钟树配置）。CAN波特率的计算公式是：CAN波特率 = APB1时钟 / (BRP预分频值 × (SJW + BS1 + BS2 + 1))。想配500kbps，一个常见的组合是：36MHz / (7 × (1 + 8 + 7 + 1)) = 36MHz / (7 × 17) ≈ 302kbps，这就不对了，说明预分频或者时间段参数没匹配好。正确做法是先确定你想要的波特率，再反推BRP和BS段。我建议用CubeMX的图形配置界面，它会实时显示最终的CAN时钟频率，省去大量手工计算。

第二坑：过滤器配置。bxCAN有28个（F429）或14个（F103）硬件过滤器，可以按报文ID过滤，也可以按掩码过滤。掩码模式下，哪一位是1表示必须匹配，哪一位是0表示不关心。很多新手把所有过滤器都关掉了，导致收不到任何数据；还有人是过滤器配得太松，结果本不该接收的报文也进来了。一个实用的调试策略：初始阶段把过滤器设为“接收所有ID”，先确认物理链路通不通；跑通后再收紧掩码规则。

第三坑：回环模式。CubeMX里有Normal、Loopback、Silent等模式。Loopback模式是内部把TX回环到RX，不需要外部应答就能“自说自话”，专门用于验证软件逻辑；Silent模式是只收不发，常用于监听总线。如果调试时不接外部收发器或者总线上只有一个单独节点，Normal模式是发不出去的，因为CAN协议要求每个帧都要有接收方回ACK。这个机制会让很多新手误以为自己的代码有问题，其实只是总线上少了一个节点。实际跑通CAN的标准步骤是：至少两个节点（哪怕一个单片机一个CAN分析仪）互相对发，并各自通过串口打印收发结果。我在F429上跑通过CAN FD和经典CAN的混发，只要在CubeMX里把“Protocol Mode”选成FD-CAN，并把FD数据段速率设置为2Mbps，其余配置和经典CAN大同小异。

3.3 进阶实操：S32K312的CAN时钟树与CAN FD使能

S32K312是NXP针对汽车应用推出的MCU，它的FlexCAN模块比STM32的bxCAN复杂不少，但也更接近真实车载控制器的使用方式。要说最关键的配置，绝对是CAN时钟树。S32K312内部的FIRC（48MHz快速IRC）和SIRC（32kHz慢速IRC）是两个常用时钟源，但CAN外设通常需要时钟频率能被波特率整除。比如你想要500kbps经典CAN，又想让CAN FD的数据段到2Mbps，那就要求控制器时钟至少是2Mbps的整数倍，并尽量选用能被精确分频的频率。

我踩过的坑是：直接用默认的FIRC 48MHz去分频，结果经典CAN 500kbps能正常，一旦使能CAN FD并且把数据段切成2Mbps，总线就开始狂抱错误帧。后来查参考手册，发现FlexCAN的时钟需要走PLL或者FIRC再经过分频，而分频系数在某些组合下会产生很明显的采样点抖动。解决办法是：把CAN时钟源切换成PLL输出，配到80MHz，然后经典CAN段设20分频得到4MHz的CAN时钟，再除以8得到500kbps，数据段再在控制器内部用2分频切到2Mbps。这样采样点稳定在80%，跑几天压力测试都干净得很。

FlexCAN还有一组很实用的寄存器用于调试：ECR（错误计数器）、IMR（中断屏蔽）、IFLAG（中断标志）。当CAN FD帧报CRC错误，你可以在中断服务函数里打印IFLAG的对应位和ECR的REC值。如果REC持续上涨而TEC没变化，通常是接收端时钟精度不够或者物理层信号质量差；如果TEC涨得快，通常是发送端的数据段波特率和接收端不匹配。这两个方向一旦分清，排查范围就小很多。

3.4 上位机配合：周立功CAN卡与LabVIEW二次开发

做CAN项目基本离不开上位机，不管是观察数据、模拟节点还是发送诊断命令。我常用的方案是周立功的USBCAN系列加上LabVIEW。周立功的CAN卡在国产工具里占有率非常高，驱动稳定，资料也比较全。它的API分两层：底层是周立功自己的CAN接口函数库，上层可以导出为DLL供LabVIEW调用。如果你不想自己封装复杂的结构体，直接用他们提供的LabVIEW例子程序改一改能省不少时间。

有一个细节必须提醒：周立功CAN卡默认不启用CAN FD模式，你如果用CAN FD节点发数据，上位机解析出来全是错误帧。需要在初始化设备时单独调用CAN_FDInit接口，并设置数据段波特率。另一个坑是PCAN或者周立功的USB-CAN卡的发送时间戳精度，默认的发送流程如果不用“计划帧发送”模式，每次发帧的间隔在Windows下会有1ms级别的抖動，这对仿真某些严格周期报文来说是致命的。解决办法是用设备自带的硬件定时发送功能，把所有要发送的帧预先配置到硬件内部发送缓冲区，由CAN卡自己的时钟控制周期，这样抖动可以压缩到几十微秒以内。

LabVIEW程序的结构，我一般会设计成三块：初始化块（打开设备、配置波特率、配置过滤器）、循环读写块（用While循环里跑一个CAN_Receive轮询，数据队列化后用事件结构处理）、退出清理块（调用CAN_Close）。这种结构既简单又稳定，实时性也够大多数台架测试用。如果你想看波形或者对报文做触发记录，周立功的ZCANPro软件本身就带报文回放和触发存储功能，不用自己先从零造轮子。

4. 高频问题与排查技巧实录：这些坑我替你踩过了

4.1 正响应0x40和负响应：诊断帧里的“对”与“错”

只要做汽车CAN诊断，早晚会碰到“CAN里面40是正响应，负响应是什么”这类问题。这里的“40”指的是UDS（统一诊断服务）协议里的正响应SID（服务标识符），规则很简单：正响应SID = 请求SID + 0x40。举个例子，请求SID为0x10（诊断会话控制），正响应就是0x50；请求0x22（按标识符读取数据），正响应就是0x62。所以网络里看到0x40、0x50、0x62这些“奇怪”的高字节SID，基本就能判定这是某个诊断请求的正响应。

负响应则是另一种格式：报文的第一字节是0x7F，第二字节是被拒绝的请求SID，第三字节是NRC（负响应码）。NRC是诊断排查的重中之重，常见的NRC含义如下表：

排查负响应最关键的思路是“先确认NRC码属于哪一类”。0x10到0x1F都是软件层拒绝，检查ECU的应用逻辑和状态机；0x20到0x2F是条件不满足，检查安全访问和时序；0x30到0x3F是请求参数无效，检查你填的数据是否按规范编码。日常调试中0x22和0x31出现频率最高，特别是误以为请求的DID（数据标识符）存在，或者把十六进制数当成十进制数填了。

4.2 仲裁失败、丢帧、波特率不匹配的定位思路

当总线上出现大量错误帧或者仲裁失败，我的常规排查步骤是这样的：第一步，用CAN分析仪以“只听模式”挂在总线上，直接看错误帧的种类和来源。如果所有错误帧都指向同一个节点ID，那问题大概率出在那个节点本身，比如它的收发器损坏、供电异常、终端电阻脱落；如果错误帧分布在各处且速率均匀，则先怀疑物理层整体质量，比如总线长度超了、线缆阻抗不对、终端电阻缺失或数量不对。

第二步，检查波特率一致性。很多人说“我两个板子都配置成500kbps”，但查完发现一个用的是500kbps标准位时序，另一个用的是500kbps但采样点相差很多。CAN的位时序涉及BRP、BS1、BS2和SJW，不同的组合可能得到相同的波特率，却导致不同的采样点位置。标准建议采样点尽量靠近位时间的75%到80%，STM32的默认配置可能落在70%左右，而另一个芯片可能是65%，两者虽然都是500kbps，但配合边缘节点时稳定性就差。统一采样点的办法是：指定“采样点百分比”而不是只指定“波特率”。

第三步，丢帧问题要看“丢”的方式。是周期报文的某些周期没出现，还是少量数据帧的CRC错误率很高？如果CRC错误率高，优先怀疑电磁干扰和线缆质量；如果CRC错误正常但报文就是偶尔不上线，需要检查发送节点是否因为发送缓冲区满而丢弃——很多CAN控制器的硬件发送队列只有3到8个槽位，如果你在软件里一次性塞了太多帧，超出槽位的帧可能被静默丢弃。解决办法是引入发送排队机制，或者提高发送任务的优先级和缓冲深度。

4.3 长线传输与节点扩展：降速、加终端、换收发器怎么选

总线长度不够或者要扩展节点时，很多人的第一反应是“换个更强的收发器”，但我要说的是：先算物理层的极限和需求，再动手。经典CAN的总线长度限制和波特率强相关，计算公式是总线长度 = 最大传播延迟 × 信号速率。工程上有个近似经验值：1Mbps下最大总线长度约40米，500kbps约130米，250kbps约250米，125kbps约500米。如果你的场景是几个电调之间通信，距离却拉到几十米，首选方案是降波特率而不是加线缆粗度。

如果降波特率影响性能，再考虑换带信号增强的收发器或者加中继器。但要理解，CAN是“线与”仲裁机制，任何中继器都必须做到“转发的同时保持仲裁语义”，也就是说它不能简单地把收到的报文重新发一遍，因为它必须参与总线的瞬时仲裁。市场上大多数CAN中继器是“存储转发式”，会引入明显延迟，多个级联之后几乎无法做多主仲裁。真正可靠的做法是使用带CAN隔离和信号增强的网关，把一个长总线拆成两段，中间用不同CAN控制器芯片做桥接，但桥梁本身要具备缓存和转发逻辑。

对于节点扩展，我发现很多人会忽略总线上的等效负载。一个CAN收发器的差分输入阻抗在隐性状态下约为20kΩ，但收发器在显性状态下的负载会显著拉低总线阻抗。标准要求最多挂32个节点，实际上超过20个节点时就要考虑链路裕量，并在选型时选用低电流的CAN收发器或者带待机模式的型号。还有一个冷门技巧：如果总线上节点数比较多，可以用0.75倍波特率而不是1倍波特率，比如把500kbps跑成375kbps，给信号留出更多边沿斜率裕量——这在整车上很少用，但在自制长线协议栈时很管用。

5. 用了这么多年CAN，我的一些个人体会

写了这么多，最后说点实在的感受。我自己的项目经验告诉我，CAN技术本身的门槛不在协议层阅读，而在“边界判断”。你首先要能在不同CAN技术之间做判断：经典CAN够用的地方不要为了炫技上CAN FD，平白增加时钟和PCB布局上的难度；但也别因为习惯了经典CAN而不愿意升级，多花一点代码量换来3到5倍的吞吐量提升，在很多场合是完全值得的。

还有一点是关于工具的。好的CAN分析仪能帮你省下大半调试时间，但工具的价值取决于你会不会看它的统计数据。错误帧计数、总线负载率、TEC/REC数值、采样点分布，这些才是真正能定位问题的高价值信息，比盯着波形图“看半天”有效得多。如果条件允许，尽量给自己配一台支持CAN FD的分析仪，哪怕现在项目还用不到CAN FD，后续升级时就不用重复采购了。

最后分享一个小经验：每次搭建CAN网络时，把终端电阻做成可插拔的跳线，把每个节点ID和波特率做成显式可配置的参数，把上位机的过滤规则留成开放接口。做完这三件事，你的CAN调试体验会完全不同——从“出问题到处量波形”变成“看一眼配置表就知道哪里不对”。这就是CAN这个老而弥坚的总线技术最迷人之处：它的下限很低，几根线加两个电阻就能跑起来；但它的上限很高，深入进去之后有太多细节值得研究。

如果你正在做一个CAN相关的项目，欢迎在调试过程中多记录异常现象的细节，很多时候你排查到的“玄学问题”，本质上都是某个物理层参数或者时序参数没有压到规定范围，并不是协议本身的问题。先相信标准，再怀疑代码，最后才怀疑硬件，这条排查顺序我用了十年都没变过。