第4章 EthIf（以太网接口）

第4章 EthIf（以太网接口）：接口抽象与多控制器支持

好，咱们今天聊聊 EthIf 模块。

说实话，在 AUTOSAR 以太网协议栈里，EthIf 是个容易被低估的角色。很多人觉得它就是个「传话筒」，把上层的数据往下扔，把下层的数据往上递。嗯，这么说也没错，但你要是真这么想，那集成的时候大概率会踩坑。

我个人习惯把 EthIf 比作「交换机管理员」。它不生产数据，也不消费数据，但它知道每个数据该走哪个端口，该找哪个控制器。说白了，它就是整个以太网协议栈的交通枢纽。

4.1 EthIf 模块的核心作用

EthIf 的全称是 Ethernet Interface。它的定位很明确：为上层协议（如 TCP/IP、SOME/IP、DoIP）提供统一的以太网访问接口，同时屏蔽底层 Eth 驱动和控制器的差异。

你想想看，一个 ECU 里可能有好几个以太网控制器。有的支持 100BASE-T1，有的支持 1000BASE-T1，甚至还有支持 TSN 的。每个控制器的寄存器配置、中断处理、DMA 方式都不一样。如果上层模块直接操作这些控制器，那代码得写成什么样？

EthIf 就是来解决这个问题的。它把底层差异全部封装起来，向上层暴露一套标准化的 API。比如：

EthIf_Transmit() — 发送数据
EthIf_Receive() — 接收数据
EthIf_GetControllerMode() — 获取控制器状态
EthIf_SetControllerMode() — 设置控制器模式

这些 API 看起来简单，但背后做的事情可不少。

核心要点：EthIf 是 AUTOSAR 以太网协议栈中唯一一个「知道所有控制器存在」的模块。上层模块不需要关心底层有几个控制器，它们只需要跟 EthIf 打交道。

4.2 接口抽象与多控制器支持

多控制器支持，这是 EthIf 最硬核的能力之一。

我记得有一次做项目，一个域控制器上挂了三个以太网控制器：一个用于和网关通信（100BASE-T1），一个用于和摄像头通信（1000BASE-T1），还有一个用于诊断（100BASE-TX）。三个控制器，三种不同的驱动，三种不同的中断处理方式。

如果没有 EthIf，上层模块得自己去管理这三个控制器的句柄、缓冲区、中断回调。那代码量，啧啧，想想都头疼。

EthIf 是怎么做的呢？它引入了一个概念叫 「控制器索引」。

/* EthIf 配置示例 */
const EthIf_ConfigType EthIfConfigData[] = {
    {
        .EthIfCtrlIdx = 0,          /* 控制器 0：100BASE-T1 */
        .EthDriverIndex = 0,        /* 对应的 Eth 驱动实例 */
        .EthIfRxBuffersNumber = 16,
        .EthIfTxBuffersNumber = 8
    },
    {
        .EthIfCtrlIdx = 1,          /* 控制器 1：1000BASE-T1 */
        .EthDriverIndex = 1,
        .EthIfRxBuffersNumber = 32,
        .EthIfTxBuffersNumber = 16
    },
    {
        .EthIfCtrlIdx = 2,          /* 控制器 2：100BASE-TX */
        .EthDriverIndex = 2,
        .EthIfRxBuffersNumber = 8,
        .EthIfTxBuffersNumber = 4
    }
};

你看，每个控制器都有一个唯一的索引。上层模块发送数据时，只需要告诉 EthIf：「我要通过控制器 0 发送这个包」。EthIf 会自动找到对应的驱动实例，完成实际的发送操作。

这里有个细节要注意：EthIf 不负责数据包的解析。它只做转发。数据包的内容是什么、该发给谁，那是上层协议栈的事。EthIf 只管「把数据从 A 点搬到 B 点」。

我的经验：配置多控制器时，一定要确认每个控制器的缓冲区数量是否合理。我曾经遇到过一个项目，摄像头数据流很大，但接收缓冲区只配了 4 个，结果频繁丢包。后来改成 32 个，问题就解决了。缓冲区数量不是越大越好，但太小肯定不行。

4.3 发送路径与接收路径

咱们分别看看发送和接收的完整路径。

4.3.1 发送路径

发送路径相对简单。上层模块（比如 TcpIp）调用 EthIf_Transmit()，传入控制器索引和数据指针。EthIf 会做以下几件事：

检查控制器状态 — 如果控制器不在 READY 状态，直接返回错误
检查缓冲区 — 确认发送缓冲区是否可用
调用底层驱动 — 通过 Eth_Transmit() 把数据交给 Eth 驱动
触发发送 — 驱动把数据写入控制器的发送 FIFO，启动发送
回调通知 — 发送完成后，Eth 驱动调用 EthIf 的回调，EthIf 再通知上层

嗯，这里有个坑。发送完成回调是异步的。也就是说，EthIf_Transmit() 返回时，数据可能还在缓冲区里，并没有真正发出去。上层模块不能假设「调用返回 = 发送完成」。

注意：我曾经见过一个团队，他们在发送后立即释放了数据缓冲区，结果数据还没发出去就被覆盖了。正确的做法是：在发送完成回调中释放缓冲区，或者在发送前做一次数据拷贝。

4.3.2 接收路径

接收路径稍微复杂一些。因为接收是异步的，数据什么时候来，上层模块不知道。

典型的接收流程是这样的：

硬件中断 — 以太网控制器收到数据，触发中断
Eth 驱动处理中断 — 驱动从控制器 FIFO 中读取数据，存入接收缓冲区
调用 EthIf 回调 — 驱动调用 EthIf_RxIndication()，通知 EthIf 有新数据
EthIf 分发数据 — EthIf 根据数据包的类型（比如是 IPv4 还是 IPv6），找到对应的上层模块
通知上层 — 调用上层模块的接收回调，把数据交出去

这里的关键是第 4 步。EthIf 怎么知道该把数据交给谁？

答案是：通过配置。在 EthIf 的配置中，有一个路由表，定义了不同数据包类型对应的上层模块。比如：

/* EthIf 路由配置示例 */
const EthIf_RxRoutingType EthIfRxRouting[] = {
    {
        .EthIfCtrlIdx = 0,
        .EthIfFrameType = 0x0800,   /* IPv4 */
        .EthIfRxPduId = 1,          /* 交给 TcpIp 模块 */
        .EthIfRxBufferRef = 0
    },
    {
        .EthIfCtrlIdx = 0,
        .EthIfFrameType = 0x86DD,   /* IPv6 */
        .EthIfRxPduId = 2,          /* 交给 TcpIp 模块 */
        .EthIfRxBufferRef = 0
    },
    {
        .EthIfCtrlIdx = 1,
        .EthIfFrameType = 0x8100,   /* VLAN 标签 */
        .EthIfRxPduId = 3,          /* 交给 Vlan 模块 */
        .EthIfRxBufferRef = 0
    }
};

EthIf 根据帧类型（EtherType）来路由数据。如果是 0x0800（IPv4），就交给 TcpIp 模块；如果是 0x8100（VLAN），就交给 Vlan 模块。这个路由表是在配置阶段就定好的，运行时不会改变。

我的建议：路由表的配置一定要和上层模块的 PDU ID 对应好。我见过有人把 IPv4 和 IPv6 的路由配反了，结果 IPv4 数据包被当成 IPv6 处理，上层协议栈直接崩溃。这种错误很难排查，因为数据链路层看起来一切正常。

4.4 EthIf 与上层模块的交互

EthIf 和上层模块的交互，主要通过两种方式：

函数调用 — 上层模块主动调用 EthIf 的 API
回调函数 — EthIf 主动通知上层模块

这两种方式构成了一个完整的「请求-响应」和「通知-处理」机制。

举个例子。当 TcpIp 模块要发送一个 TCP 数据包时：

TcpIp 调用 EthIf_Transmit(ctrlIdx, pduInfo)
EthIf 检查参数，调用 Eth_Transmit()
发送完成后，Eth 驱动调用 EthIf_TxConfirmation()
EthIf 再调用 TcpIp 注册的发送完成回调 TcpIp_TxConfirmation()

接收方向也是类似的。Eth 驱动收到数据后，调用 EthIf_RxIndication()，EthIf 根据路由表找到 TcpIp，调用 TcpIp_RxIndication()。

这里有个重要的设计原则：EthIf 不缓存数据。它只是传递指针。数据缓冲区要么在 Eth 驱动里，要么在上层模块里。EthIf 只是一个「中间人」，不持有任何数据的所有权。

为什么要这样设计？因为 AUTOSAR 对实时性要求很高。如果 EthIf 在中间做一次数据拷贝，那延迟就上去了。对于 SOME/IP 这种对延迟敏感的应用，多一次拷贝可能就是灾难。

嗯，说到 SOME/IP，我再补充一点。EthIf 本身不关心数据包的内容是 SOME/IP 还是 DoIP。它只根据 EtherType 做路由。所以，如果你要支持 SOME/IP，只需要在路由表中配置对应的 EtherType（通常是 0x0800，因为 SOME/IP 跑在 UDP 上），然后让 TcpIp 模块去处理就行了。

最后，我总结一下 EthIf 的几个关键点：

接口抽象 — 向上层提供统一的 API，屏蔽底层差异
多控制器支持 — 通过控制器索引管理多个 Eth 驱动实例
数据路由 — 根据 EtherType 将接收到的数据分发给正确的上层模块
零拷贝设计 — 不缓存数据，只传递指针，保证实时性

说实话，EthIf 的代码量在整个协议栈里不算大，但它的设计思路非常值得学习。把复杂的事情简单化，把差异化的东西统一化，这就是接口抽象的精髓。

下一章，咱们聊聊 EthTrcv（以太网收发器）模块。这个模块虽然小，但坑不少。到时候我会分享一些我在实际项目中踩过的雷。

📚 课程目录