Switch 的运行状态由已经完成的初始化和管理操作共同形成。XML 描述期望配置，C 代码表达软件动作，运行时寄存器与表项反映当前硬件状态。看见配置值、找到 API 名称和确认配置已经生效，是三件不同的事。 沿着配置消费、构建、执行、硬件访问和读回建立连续关系，才能解释它们之间的差异。

本文是车载以太网 Switch 专栏的第三篇，结合硬件连接与二层转发，说明配置生效、UMSD/MDIO 管理与 AUTOSAR 集成。所有代码均为自行构造的示意代码，不引用内部驱动、配置原件或专有寄存器序列。

车载以太网交换芯片连接传感器、计算节点和控制节点，完成端口间报文转发。理解它的硬件架构，需要同时看清三个对象：MAC 处理以太网帧，PHY 实现物理链路，Switch 连接多个端口并决定帧的出口。 RGMII、SGMII 和高速 SerDes 则处于不同的连接边界，不能仅根据接口名字判断网线怎样接。

本文是车载以太网 Switch 专栏的第一篇。这里先建立连接模型，第二篇讨论一帧报文的转发，第三篇讨论管理与配置生效。

通用测量核心与 ECU 工程之间的连接集中在平台适配层：它识别实际执行者，读取 STM 时间，形成串行事件，并把统计副本交给报告路径。

对于 TC397 与 AUTOSAR，可以按“Host 模型 → 时间源 → 调度和中断边界 → 周期采样 → 多核发布 → 目标验证”的顺序完成接入。各步骤分别建立一项明确的契约，组合后得到可解释的每核时间账本。

本文使用配套模块中的独立 Hook 模型讲解接口。C99 核心与 Mock 示例已通过 Host 验证；具体 MICROSAR/TASKING/TC397 接入处于 Experimental / Unverified，目标参数和实际 Hook 顺序由工程配置确定。

在嵌入式工程里，经常会遇到两种静态库场景：

• 作为 Producer：把自己的源码编译成 .a，交给其他团队或第三方集成；
• 作为 Consumer：拿到供应商提供的 .a，再链接进自己的 ECU 工程。

两种场景其实是同一条构建链的两端。

本文结合 TC397 + TASKING + AUTOSAR Classic 工程，完整梳理：

.c
 │
 │ Compile
 ▼
.o
 │
 │ Archive
 ▼
.a
 │
 │ Link
 ▼
ELF
 │
 ▼
HEX / ECU

本文关注 Compile、Archive、Link 三个阶段的职责，以及嵌入式静态库交付给第三方时需要满足的条件。