第2章：物理层详解——差分信号、电平逻辑与总线拓扑
物理层这东西，很多人觉得不就是两根线嘛，有啥好讲的？
但我在项目里见过太多次，明明协议栈写得没问题，硬件设计也照着参考电路来的，结果一上总线就是收不到数据，或者时不时冒个错误帧出来。最后查来查去，问题全出在物理层——终端电阻没配好、线缆太长、或者拓扑结构搞成了星型。
所以这一章，咱们把物理层掰开揉碎了讲清楚。
2.1 差分信号：CAN 能跑这么远的秘密
CAN 总线为什么能在工业现场跑几十米甚至上千米？核心就两个字：差分。
你想想看，传统的单端信号（比如 UART 的 TX/RX），靠的是对地电压高低来表示 0 和 1。如果地线有干扰，或者线缆长了有压降，信号就很容易被淹没。
差分信号不一样。它用两根线——CAN_H 和 CAN_L——来传输，逻辑值由两根线的电压差决定。
核心公式：
Vdiff = VCAN_H - VCAN_L
Vdiff > 0.9V → 显性（逻辑 0）
Vdiff < 0.5V → 隐性（逻辑 1）
干扰通常是共模的，同时作用在两根线上。差分接收器只关心差值，共模干扰就被抵消掉了。这就是 CAN 能在强电磁环境下稳定工作的根本原因。
我的一点经验：
曾经有个项目，电机一启动 CAN 就丢帧。查了半天，发现是 CAN_H 和 CAN_L 的走线长度差了 3 厘米。双绞线没绞紧，共模抑制比直接掉了 20dB。从那以后，我要求硬件工程师必须把差分对等长控制在 5mm 以内。
2.2 CAN_H 与 CAN_L 的电平逻辑
CAN 总线只有两种状态：显性（Dominant）和隐性（Recessive）。
隐性状态时，CAN_H 和 CAN_L 都维持在 2.5V 左右，差值为 0V。显性状态时，CAN_H 被拉到 3.5V，CAN_L 被拉到 1.5V，差值 2V。
| 状态 | CAN_H 电压 | CAN_L 电压 | 差分电压 | 逻辑值 |
|---|---|---|---|---|
| 隐性 | 2.5V | 2.5V | 0V | 1 |
| 显性 | 3.5V | 1.5V | 2V | 0 |
这里有个关键点：显性会覆盖隐性。也就是说，只要有一个节点拉出显性电平，整条总线就变成显性。这就是 CAN 总线仲裁的物理基础——谁先拉低，谁就赢。
注意：
如果 CAN_H 和 CAN_L 短路了，或者其中一根断了，总线就会一直处于隐性状态，谁都发不出数据。我在现场遇到过 CAN_H 被螺丝刀压到机壳上的情况，查了整整一个下午。
2.3 总线拓扑结构
CAN 标准推荐的是直线型（也叫总线型）拓扑。所有节点都挂在一根主干线上，每个节点用尽量短的支线接入。
2.3.1 直线型（推荐）
- 主干线两端各接一个 120Ω 终端电阻
- 支线长度尽量短，最好不超过 30cm
- 节点数最多 110 个（标准帧）
为什么必须是直线型？因为信号在线上传输时，遇到阻抗不连续的地方就会反射。直线型拓扑下，只要两端匹配了终端电阻，反射就能被吸收掉。
2.3.2 星型（不推荐）
星型拓扑就是把所有节点都接到一个中心点上。这种结构在 CAN 总线上问题很大——中心点会形成多个阻抗不连续点，信号反射严重，总线长度和速率都会大打折扣。
我踩过的坑：
有一次客户非要搞星型拓扑，说布线方便。我劝了三次没劝住，结果 500kbps 下总线长度连 10 米都跑不到。最后老老实实改回直线型，50 米稳如老狗。
2.4 终端电阻的作用与计算
终端电阻是 CAN 总线最容易被忽视但又最关键的部分。
2.4.1 为什么需要终端电阻？
两个作用：
- 消除信号反射——让阻抗匹配，信号到了线端被吸收而不是反弹回来
- 提供隐性电平偏置——没有终端电阻，总线在隐性状态时电压会漂移
2.4.2 为什么是 120Ω？
CAN 总线用的双绞线特性阻抗大约是 120Ω。为了阻抗匹配，终端电阻也要取 120Ω。两个 120Ω 并联后是 60Ω，这就是你在总线上测到的直流电阻。
快速判断方法：
用万用表量 CAN_H 和 CAN_L 之间的电阻：
- 60Ω → 正常，两个终端电阻都在
- 120Ω → 只有一个终端电阻
- 无穷大 → 两个终端电阻都没有
2.4.3 终端电阻的放置位置
必须放在总线的最远两端，不能放在中间，也不能放在节点内部（除非节点就在端点）。
我曾经犯过的错：
早期做的一个项目，把终端电阻放在了接线盒里，结果后来有人加长了总线，终端电阻就不在端点上了。信号反射导致总线速率从 500kbps 降到了 125kbps 才能稳定工作。
2.5 物理层知识体系总览
下面这张图把本章的核心知识点串起来了，你可以把它当作物理层的速查地图。
2.6 本章小结
物理层是 CAN 通信的基石。差分信号给了它抗干扰的能力，显性/隐性的电平逻辑决定了仲裁机制，直线型拓扑和 120Ω 终端电阻保证了信号完整性。
这些看起来都是基础概念，但我在实际项目中见过太多因为物理层没做好而导致整个系统瘫痪的案例。记住一句话：协议栈写得再好，物理层拉胯，一切都是白搭。