3、以太网基础重温：车载以太网（100BASE-T1 / 1000BASE-T1）物理层特点，TCP/IP协议栈在车内的裁剪与适配
好，咱们进入第三讲。说实话，很多做CAN的老工程师一听到以太网就头疼，觉得那是IT部门的事。但车载以太网跟咱们办公室里的以太网，其实差别挺大的。我当年第一次接触100BASE-T1时，也犯过嘀咕——这玩意儿跟家里网线长得不一样啊？
今天咱们就掰开揉碎了聊聊，车载以太网的物理层到底特殊在哪，以及那个庞大的TCP/IP协议栈，到了车里是怎么“瘦身”的。
3.1 车载以太网物理层：为什么不能用标准以太网？
先问个问题：为什么不能直接把办公室的RJ45网线怼到车上？
原因很简单——成本、重量、还有电磁兼容。标准以太网用的是四对差分线，也就是8根线。你想想看，一辆车里有几十个ECU，每个都拉8根线，那线束得多重？成本得多高？
更重要的是，车内的电磁环境极其恶劣。电机、点火线圈、各种开关，全是干扰源。标准以太网那种非屏蔽双绞线，在车里根本扛不住。
所以，车载以太网物理层做了两件事：减线和抗干扰。
3.1.1 100BASE-T1：单对线的“瘦子”
100BASE-T1，以前叫BroadR-Reach。它只用一对双绞线就能跑100Mbps。你没看错，就两根线。
我刚开始做项目时，供应商给我看这个方案，我第一反应是：“两根线？那供电怎么办？” 后来才明白，它只传数据，供电走另外的线。
它的核心特点：
- 单对非屏蔽双绞线：重量轻，成本低，布线方便。
- 全双工通信：同时收发，靠的是混合电路和回波抵消技术。嗯，这个技术挺巧妙的，有点像电话线。
- 传输距离：最长15米。够用了，车里最远的两个节点也就十来米。
- PAM3编码：用三电平脉冲幅度调制，不是简单的0和1。这么做是为了在有限的带宽里塞进更多数据。
关键点：100BASE-T1的物理层芯片（PHY）内部集成了回波抵消器。这玩意儿是核心，没有它，单对线全双工就是扯淡。
我在一个ADAS项目中用过100BASE-T1，连接摄像头和域控制器。当时最头疼的是线束的阻抗匹配。供应商说线束特性阻抗必须是100欧姆，结果我们采购的线束批次不合格，导致丢包率飙升。后来换了线束供应商，问题才解决。所以，线束质量是100BASE-T1的命门。
3.1.2 1000BASE-T1：千兆时代的“速度机器”
随着自动驾驶对带宽的需求暴涨，100Mbps不够用了。于是有了1000BASE-T1。
它同样只用一对双绞线，但速度飙到了1Gbps。怎么做到的？
- PAM4编码：用四个电平，每个符号携带2比特信息。比PAM3更高效。
- 更宽的频谱：工作频率更高，对线束和连接器的要求也更苛刻。
- 更强的纠错：使用了更复杂的RS-FEC（里德-所罗门前向纠错）。
说实话，1000BASE-T1的PHY芯片比100BASE-T1贵不少，功耗也高。目前主要用在激光雷达、高分辨率摄像头、以及骨干网连接上。
注意：1000BASE-T1对PCB布局要求极高。差分对必须等长，阻抗控制要精确到±10%。我曾经见过一个团队，因为PCB走线没处理好，导致千兆链路死活协商不上，最后发现是差分对长度差了5毫米。5毫米，在千兆频率下就是灾难。
3.2 TCP/IP协议栈在车内的裁剪与适配
物理层搞定了，接下来就是上层协议。标准的TCP/IP协议栈是为互联网设计的，庞大、灵活、但开销也大。车里资源有限，不能直接照搬。
你想想看，一个MCU可能只有几百KB的RAM，你让它跑一个完整的Linux TCP/IP栈？不现实。所以，必须裁剪。
3.2.1 裁剪的核心思路：轻量化
车内的协议栈裁剪，说白了就是做减法：
- 去掉不需要的功能：比如路由协议（RIP、OSPF）、复杂的组播管理（IGMP）、以及各种应用层协议（HTTP、FTP）。车里不需要这些。
- 简化头部：有些协议栈会使用压缩的IP/UDP头部，减少带宽占用。
- 零拷贝：数据从网卡到应用层，尽量减少内存拷贝次数。这在标准Linux里很难做到，但车内的轻量级栈可以。
我个人习惯用uC/TCP-IP或者LwIP。LwIP是开源的，轻量级，支持裁剪。我在一个基于Cortex-M4的网关项目里用过LwIP，RAM占用控制在50KB以内，跑Some/IP和DoIP完全没问题。
3.2.2 适配的关键：实时性与确定性
车内通信对实时性要求很高。标准TCP的拥塞控制、重传机制，在车里就是噩梦。你想想，一个刹车指令因为TCP重传而延迟了200毫秒，那还得了？
所以，车内通常的做法是：
- 优先使用UDP：无连接，无重传，延迟低。大部分车载以太网应用（如Some/IP、AVB）都跑在UDP上。
- TCP只用于非实时场景：比如OTA升级、诊断日志上传。这些场景允许延迟和重传。
- 引入时间敏感网络（TSN）：TSN是IEEE 802.1标准族，它在以太网MAC层增加了时间同步和流量调度机制。说白了，就是让以太网变得像CAN一样可预测。
我的建议：如果你刚开始做车载以太网，别急着上TCP。先从UDP+Some/IP开始，把通信链路调通。等对延迟和抖动有了感觉，再考虑引入TCP做文件传输。
3.2.3 一个典型的裁剪配置示例
下面是一个基于LwIP的裁剪配置，适用于车载网关：
// lwipopts.h 中的关键配置
#define NO_SYS 1 // 无操作系统，裸跑
#define LWIP_NETCONN 0 // 不使用Netconn API
#define LWIP_SOCKET 0 // 不使用Socket API
#define LWIP_UDP 1 // 开启UDP
#define LWIP_TCP 0 // 关闭TCP（节省RAM）
#define LWIP_IGMP 0 // 关闭IGMP
#define MEM_SIZE 4096 // 内存池大小，4KB
#define PBUF_POOL_SIZE 16 // pbuf池大小
#define TCP_MSS 0 // TCP段大小，关闭TCP后无效你看，关闭TCP后，RAM占用直接降了一大截。对于只跑Some/IP和DoIP的节点，这个配置足够了。
3.2.4 适配中的坑：MTU与分片
标准以太网的MTU是1500字节。但车内有些网络（比如CAN-FD转以太网）会涉及小包聚合。如果聚合后的包超过1500字节，就需要IP分片。
我曾经遇到过一个坑：某个供应商的协议栈，IP分片处理有bug，导致大包永远无法重组。最后定位发现是分片偏移量计算错误。从那以后，我要求所有项目必须做MTU发现，或者干脆把应用层报文控制在1400字节以内，避免分片。
经验之谈：在车内，尽量让应用层报文小于1400字节。别挑战MTU，别依赖IP分片。分片不仅增加延迟，还容易丢包。一旦丢了一个分片，整个包都得重传，效率极低。
3.3 小结
好了，这一章咱们把车载以太网的物理层和协议栈裁剪捋了一遍。总结一下：
- 100BASE-T1：单对线，100Mbps，适合摄像头、传感器等节点。
- 1000BASE-T1：单对线，1Gbps，适合激光雷达、骨干网。
- 协议栈裁剪：去冗余、用UDP、引入TSN，核心是实时性和轻量化。
下一章，咱们会深入Some/IP和SOME/IP-SD，看看应用层协议是怎么在车载以太网上跑起来的。到时候我会拿一个实际的ADAS项目案例来拆解，敬请期待。