第3章 数据链路层

第3章 数据链路层

本章要回答的三个问题：一串比特凭什么被识别成一条完整报文，字段顺序是谁规定的？两个节点同时开口，总线凭什么不报废任何一帧？拿到一段 candump 输出的十六进制，如何还原出真实的转速与温度？本章是全书的枢纽章，帧结构与仲裁是后面诊断、负载率、故障分析全部技能的语法基础。

为什么会有这一章

物理层保证比特可靠传输，但比特本身没有含义。要让"制动请求"与"空调设置"在同一线路上互不干扰地传递，必须有帧格式划清边界、有标识符区分身份、有仲裁规则分配线路。这三件事共同构成CAN的介质访问控制，是它区别于其他总线的核心竞争力，也是所有车载工具链——DBC、诊断仪、总线分析软件——共同解释的那层"语法"。

这一章的内容在工程中出现频率极高。看懂帧结构，才能理解为什么经典CAN一次只能携带八字节数据、为什么诊断报文要拆包；理解仲裁，才能设计报文的标识符分配、估算最坏发送延迟；会用 candump 之类的工具把原始帧解析成物理量，则是总线开发与测试人员的日常。可以说，本章之前的知识是"知道"，本章之后才是"上手"。

值得强调的一个观点：CAN的帧格式是"以发送者为中心"的。报文不带源地址与目标地址，只有标识符；标识符既当身份也当优先级，还充当过滤依据。这一设计带来广播、多播几乎零成本的好处，也带来后面章节要面对的安全软肋。学帧结构时把每个字段往这个设计思想上挂，记忆就不会散。

还有一个务实建议：本章的三节请配着键盘读。帧结构对照 candump 输出看，仲裁对着两列标识符推演，读帧直接在虚拟总线上跑——CAN的语法规则在动手十分钟内建立的直觉，胜过通读数小时。如果暂时没有 Linux 环境，任何支持 CAN 的评估板或仿真工具都可以替代，关键是让自己成为总线上会说话的一个节点，而不只是旁观报文的看客。

读完能解决什么

读完本章，你应当能够：画出标准数据帧的完整字段序列，逐字段说出含义与位数；解释扩展帧与标准帧共存的机制以及为什么混用要谨慎；推演两个节点逐位仲裁的全过程，据此判断任意两个标识符谁赢；理解位填充对帧长与传输时间的影响，并用于负载率估算；在Linux或仿真环境里使用 candump、cansend 等工具收发报文，把十六进制数据场按DBC规则换算成转速、温度这类物理量。

各节怎么分工

三节的推进方式是从"静态语法"到"动态调度"再到"人工实践"：先认识帧的长相，再看帧与帧如何竞争线路，最后亲手解析一帧真实的报文收尾。

先决条件

需要第2章的显性与隐性概念——仲裁的裁决依据就是它们；需要十六进制与二进制互转的熟练度，本章的示例大量在两种进制间切换。工具方面，第3节会用到 SocketCAN 环境（Linux 原生支持，或虚拟机安装），Windows 用户也可以用商业总线工具的演示模式对照，操作逻辑是相通的。

往下走到哪

帧发出去了，出错怎么办？第4章接手：五类错误的检测、错误帧的发射、故障节点的分级隔离，全部建立在本章的字段结构之上——CRC覆盖哪一段、应答位在哪里、填充规则何时豁免，这些细节会在错误机制里逐一回收。学完本章，你也具备了读懂第5章CAN FD帧格式增补的能力：FD帧就是在经典帧骨架上插入几个新控制位、换掉校验算法而已。

读完本章还可以做一个跨章的自查：随手找一段真实报文日志，先拆帧、再讲仲裁、最后还原信号值，三个动作一气呵成，说明本章真正学进了手。做不到的部分，回到对应的小节补课即可——这套自查在后续每章末尾都值得重复，它比任何测验都诚实。