曾几何时，汽车这么一个夕阳产业突然病树前头万木春，一下子成了各大技术创新的母体和载体。 

近年来，随着车载以太网的强势登场，CAN总线也突然变得老土了起来。 

那么，CAN总线还有用武之地吗？还有学习的必要吗？ 

且不说工控、楼宇等其它领域里，CAN总线依然热火朝天。就是在不断追求高大上的汽车行业里，车载以太网跟CAN总线也是大路朝天，各走一边。 

在动力控制域、车身控制域里，并不涉及大量的数据传输，上车载以太网有大材小用之嫌，这些控制器之间的通信，CAN总线也能玩得转，性价比十分亮眼。 

成本才是王道！所以，猫有猫的道，狗有狗的道，说起CAN总线的寿命，它能陪你退休，伴你到老。 

打消了技术过时淘汰的顾虑，下面，洒家就书接上文，再唠一唠CAN总线那些不为人知的小门道。

报文ID分配的学问

上文说过，RS485为每个设备分配地址，属于“设备寻址”，CAN总线是基于ID进行“功能寻址”。 

CAN报文的ID除了内容寻址、功能寻址外，还有竞争总线的作用，机制也很简单，比大小。 

在这个丛林社会的现实世界，“尊严只在剑锋之上，真理只在大炮射程之内”，换句话说，谁大谁说了算！ 

但是在CAN总线的世界里，却是孔融让梨，互相谦虚，谁小谁说了算。 

谁小谁占先，这个规律摆在面前。那么，搞CAN总线开发的朋友们，如果让你们自己来定一个CAN网络的矩阵，这个网络里有几十条报文，有的是事件触发型，有的是周期轮转型，有的周期长，有的周期短，这里的ID分配，到底该怎么办？ 

绝大部分人，可能真的没有想到过这一点。 

在这里跟大家分享一个来自某车厂的网络矩阵表，有心的小伙伴，可以自行体会体会。

都说外行看热闹，内行看门道。这张让人有点眼花缭乱的图，到底藏着哪些道道？ 

先说事件帧和周期帧，发现没？事件帧报文的ID都小于周期帧报文。 

在时间无涯的荒野里，没有早一步，也没有晚一步，时间一到，周期帧就按时发报。那也没有别的话好说，它唯有轻轻地问一句：“哦？没有事件帧哈！” 

周期帧有着无垠的时间，不疾不徐，事件帧，紧急触发，风风火火，自然需要一个小ID，对着周期帧喊声“对不起，请让让”。 

那么，周期帧本身的ID呢？当然取决于它出自哪一个节点。 

条条大路通罗马，有人出生在罗马。人，生来不平等，才呐喊着、追求着“生而平等”，所以，报文ID的出身决定论，也是合理的了。 

再回到上面那张图。发动机管理单元EMS、变速器控制单元TCU，掌管汽车动力，生杀予夺，自带豪门属性，自然需要分配优先级最高的ID，空调AC、仪表IC实时性要求不高，车载Tbox可有可无，自然分配优先级最低的ID。 

虽说同是汽车电子零部件，但还是要分个三六九等。其实，这些电子单元，也没必要叫屈喊冤，还有个冤大头，在报文ID的分配里，更加没有发言权。 

这个冤大头，叫OBD，即诊断单元。 

做过诊断的朋友知道，诊断报文的ID介于0x700-0x7ff之间，细心的开发者还会发现，通信报文从来没有占用过这个区间，即信息控制类的报文优先级高于诊断报文。 

这说明了什么？ 

都说政府机关、事业单位是三分之一在干，三分之一在看，还有三分之一在捣蛋。在CAN总线的世界里，诊断单元属于在一旁看着的工种，怎能奢望优先级较高的ID，来给正常的通信服务捣蛋呢？

总线负载率

在CAN总线网络里，还有一个经常被大家提起的概念-总线负载率。 

负载率，顾名思义，就是指这段时间内总线上实际传输的信息量/理论上可传输的最大信息量。 

不知道大家平时怎么理解一个“概念”或“定义”，洒家的小窍门是“咬文爵字”和“抠字眼”。 

具体要抠哪些字眼，可以参考老罗的锤子手机原创、最近被微信抄了去的big bang大爆炸。这个概念里，有两个需要重点理解的点：“这段时间”、“理论最大信息量”。 

“这段时间”可长可短，也意味着负载率是可变的。需要特别关注的有两个：平均负载率和峰值负载率。根据洒家多年的小经验，平均负载率大多低于40-50%，峰值负载率也不超过70-80%。 

至于说，负载率超了会怎么样？ 

也许，针对某个具体的CAN网络，从技术上来说，把原本30%的平均负载率提高到50%也没啥。但是，从“行政”上来说，您这个提议提高负载率的技术人员需要写报告，说明白为啥要提，提到50%有没有什么风险，怎么证明没有风险，有没有理论分析，有没有实测报告，有没有。。。。 

好吧，30%最保险了~~ 

另一个，“理论上可以传输的最大信息量”取决于总线速率。具体来说，低速CAN为125kbps，高速CAN为500kbps，CAN-FD为2Mbps，再往上，Flexray站出来说了“此吾家事，汝不得预也！”。 

在制定负载率时，会牵涉到一个概念-报文时长。洒家不少同事说起报文时长来，经常不清不楚，模模糊糊。其实，真正找到关键，问题就很简单了。 

关键在哪？在计算公式： 

报文时长=位时长x报文位数。 

在这个公式里，位时长当然等于速率的倒数，比如125kbps的通信速率，位时长=8us。而报文位数，则取决于CAN报文的结构。报文结构如下图所示：

一个完整的CAN报文由七个不同的Field（场/域/段）组成：帧起始、仲裁场、控制场、数据场、CRC场、应答场、帧结尾。 

每个Field的位数相加，不就齐了？ 

下面就单独就每个场进行分析。 

SOF为帧起始，标志着数据帧和远程帧的起始，由一个单独的“显性”位组成。 

仲裁场包括识别符和远程发送请求位（RTR）。识别符的长度为11位。 

控制场由6个位组成，包括数据长度代码和两个将来作为扩展用的保留位。 

数据场由数据帧中的发送数据组成。它可以为0～8 个字节。 

CRC场包括CRC序列（CRC SEQUENCE），其后是CRC界定符（CRC DELIMITER）。CRC序列为15位，CRC界定符包含一个单独的“隐性”位 。 

应答场长度为2个位，包含应答间隙（ACK SLOT）和应答界定符（ACK DELIMITER）。 

帧结尾由一标志序列界定。这个标志序列由7 个“隐性”位组成。 

所以一个8字节的数据帧的位数为1（帧起始）+ 12（仲裁场）+ 6（控制场）+ 64（数据场）+ 16（CRC场）+ 2（应答场）+ 7（帧结尾）= 108位。 

报文之间存在帧间空间INTERFRAME SPACE。帧间包括间歇场、总线空闲的位场。间歇场包括3 个“隐性”的位。总线空闲的（时间）长度是任意的。

 所以，一个8字节的数据帧至少需要（108+3+1）* bitrate的时长，对于125kbps，需要0.896ms。

CAN总线的位定时

对一般的开发者来说，CAN总线的位定时概念并不常见。不过，如果给整车厂做过零部件，经受过他们的CAN通信测试考验，您可能就知道，这也是比较重要的一个知识点。 

前文说了，CAN报文由七个不同的场/段组成。那么，具体到单个bit位呢？上一张图，大家就有概念了。

一个位，由同步段+传播段+相位缓冲段1+相位缓冲段2组成。 

这四个段的时间均为基本时间单位“时间份额”的若干倍，时间份额Tq派生于振荡器周期，可以由振荡器进行分频。 

由这张图可以看出，在相位缓冲段1和相位缓冲段2的交接处，藏着一个“采样点”，或者说“采样时刻”，这也是CAN通信测试中比较重要的一个测试项。 

下面这张图，是一个CAN通信需求规范中的位定时要求。

在实际的编程开发工作中，需要根据这个位定时规范，对照MCU中CAN模块的寄存器特点，对寄存器进行针对性设置。 

比如飞思卡尔微控制器中的MSCAN模块，其位定时寄存器如下所示：

在这款CAN控制器中，把CAN的位分成了三段，同步段、段1和段2。跟CAN2.0协议中定义的“同步段+传播段+相位缓冲段1+相位缓冲段2”进行对比，便可以发现，MSCAN中的段1即CAN2.0协议中的“传播段+相位缓冲段1”。  

如何具体设置CAN控制器寄存器呢？ 

根据规范要求，一个8us的CAN比特位包含16个Tq，采样位置在该bit位75%的时刻，所以，可以将Time Segment1 设为 11，Time Segment2 设为 4，这样，既能保证包含16个Tq(1 + Time Segment1 + Time Segment2 = 16)，又可以保证采样时刻=(1 + Time Segment1)/16=75%。

写在最后

CAN总线有着广泛的应用，也有着长久的生命周期。深入思考并钻研CAN总线的一些小门道，可以帮助您在一些表层的知识之下加深对这门技术本质的认识，同时，在面对一些规范要求时，可以做到知其然并知其所以然，何乐而不为？

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。