车载以太网驱动在AUTOSAR层级中所扮演的重要作用

正文

正如前文《车载以太网基础篇之EthIf》所述，Eth Driver将作为配置以太网的底层驱动，不仅能够被EthIf来进行调用，同时能够满足Eth收发器驱动的调用需求，因为有必要深入了解下车载以太网驱动(Eth Driver)在整个AUTOSAR层级中所扮演的重要作用。

如下图1所示，Ethernet If模块不仅会直接控制Ethernet Driver，如果存在Ethernet Switch驱动或者Ethernet Transiver驱动时，那么就会间接控制Ethernet Driver模块，总而言之，以太网驱动不仅能够完成以太网数据的正常收发，同时也能够实现针对以太网网关或者以太网收发器的直接配置。

图1 Ethernet Driver与其他以太网驱动关系

AUTOSAR层次关系

按照AUTOSAR标准文档规范，有关Eth Driver模块在整个AUTOSAR软件架构的具体位置描述如下图2所示：

图2 Eth Driver与以太网协议栈关系

如上图所示，可以得出如下几个基本结论：

一个以太网协议栈中可以存在多家供应商的以太网控制器，同时针对每家供应商的控制器进行单独控制，互不影响；

同一供应商的以太网控制器可以存在多个，但使用的以太网控制器驱动可以仅使用同一套；

上述三家不同供应商的以太网驱动作为标准AUTOSAR MCAL的一部分，能够完全实现与底层硬件的解耦；

模块主体功能

Eth Driver作为车载以太网协议栈最为重要的底层构件，小T将带领大家从以下几个层面初步了解认识以太网驱动：

以太网各个不同驱动内部的索引关系如何设定？

以太网驱动如何进行数据发送；

以太网驱动如何进行数据接收；

以太网驱动特性如QoS，硬件时间戳，Offloading都具备什么功能？

在以太网驱动常见的通信协议如MDIO，DMA如何在驱动中发挥作用？

驱动索引规则

如下图3所示，每个以太网驱动彼此都是独立的，同时其索引编号是从0开始，但是每个驱动内部的bufidx均可以从0开始，彼此之间互不干扰。

图3 Eth Driver索引关系

数据发送过程

上层应用如果需要通过Eth Driver将数据发送出去，那么就需要通过EthIf模块间接调用Eth Driver的发送函数Eth_Transmit来完成数据的发送。

其中EthIf模块的数据发送功能分为两者模式，一种是Polling模式，另外一种就是Interrupt模式，一般而言都优先采用中断模式来满足系统实时性要求。

如下图4为Polling模式，在Polling模式中可以看到在EthIf_MainfunctionTx函数中会去轮询是否发送成功的标志，这个也是Polling模式的典型特征。

Polling模式

图4 数据发送Polling模式

Interrupt模式

如下图5所示为以太网数据发送的中断模式，中断模式相比Polling模式可以看出并没有使用到EthIf_MainfunctionTx函数，而是使用Eth模块的中断函数来确认发送是否成功。

图5 数据发送中断模式

数据接收功能

同理相比数据发送功能，EthIf模块的数据接收功能也可以分为Polling模式与中断模式两种，如下图9所示为EthIf模块的数据接收Polling模式。

如下图6所示，如果EthIf模块数据接收采用Polling模式，那么就需要使用到EthIf_MainfunctionRx函数，在该函数中去调用EthIf_RxIndication来告知上层数据已成功被接收，使用该模式会大大降低数据接收效率，一般接收优先采用中断模式。

Polling模式

图6 数据接收Polling模式

Interrupt模式

如下图7所示为EthIf模块的数据接收中断功能，在该模式中可以看到通过Eth模块通过中断函数来进而告知上层数据已被接收。

图7 数据接收中断模式

驱动特性简介

以太网驱动相比其他驱动而言，存在很多诸多独有的特性，小T将会带领大家来了解这些特性，争取对这些特性有个基本的认识，以便我们对以太网驱动有个较为全面的了解，应用它时也会更加得心应手。

以下列举了以太网驱动(网卡)常见的三种特性：Offloading 特性，硬件TimeStamp特性，QoS特性。

Offloading特性

“Offload"顾名思义表示卸载的意思，那么给谁卸载以及卸载什么呢？其实该特性存在的目的就是为了给CPU卸载，卸载的方式如将CRC计算交给硬件来做，或者分包组包的动作也放在硬件中来处理，从而减小这部分在以太网协议栈中的占用时间，降低软件运行延迟造成的性能不足以及CPU loading过高等问题。

在AUTOSAR规范中针对以太网驱动(Eth Driver)发送或者接收报文的CRC进行了Offloading的特别说明如下：

对于IPV4帧，如果EthCtrlEnableOffloadChecksumIPv4设置成TRUE，那么就可以Offloading CRC；

对于ICMP帧，如果 EthCtrlEnableOffloadChecksumICMP设置成TRUE，那么就可以Offloading CRC；

对于TCP帧，如果 EthCtrlEnableOffloadChecksumTCP 设置成TRUE，那么就可以Offloading CRC；

对于UDP帧，如果 EthCtrlEnableOffloadChecksumUDP设置成TRUE，那么就可以Offloading CRC；

值得注意的是这些CRC计算都仅会在硬件中完成，对于接收方而言，CRC校验检测会通过硬件来完成，如果CRC校验不通过，那么就会丢弃该接收到的帧。

硬件TimeStamp特性

如之前文章《AUTOSAR基础篇之CanTsyn》与《AUTOSAR基础篇之StbM》所述，大家相比CAN时间同步有了一个基本的认识与了解，与CAN时间同步对比，以太网时间同步协议采用的IEEE1588或者IEEE802.1AS的PTP(Precise Time Protocal)协议，该协议需要确认使用的网卡(MAC)是否本身支持。

该协议使用到通过底层硬件MAC来打上对应的以太网报文收发的时间戳，能够最大限度地降低软件时间戳所带来的不确定性，将时间同步精度能够做到微秒甚至是纳微秒级别。

AUTOSAR规范中定义的EthTsync模块使用的是双步端延时PTP时间同步协议，如下为基于该协议的Time Master与Time Slave两者之间的交互关系，后期也会针对EthTsync模块进行单一讲解，敬请关注。

图8 双步以太网端延时机制PTP时间同步协议

如上图8所示，如果是基于单步模式下的以太网端延时机制的PTP时间同步，那么虚线标注的部分则不会有，如果是基于双步模式下的以太网端延时机制的PTP时间同步，那么虚线标注的部分必须要有。

值得注意的是在IEEE802.1AS存在一个GrandMaster概念，需要通过BMCA(Best Master Clock Algorithm)来实现，不过由于汽车内部属于静态网络，因此只会存在唯一的GrandMaster，无需使用到BMCA动态分配确认算法。

以太网硬件实现PTP协议有如下两种方式：

以太网MAC控制器支持PTP协议，常见双步模式；

有些TI的PHY层也可以支持PTP，不过一般是单步模式，如果使用AUTOSAR标准的EthTsync模块，要提前确认是否支持双步模式；

QoS特性

Qos是IEEE 802.1P协议，该协议运行在以太网第二层，用来保证在以太网数据转发拥堵时通过优先级方式来保证重要的数据包能够及时发送出去。

普通的以太网二层报文是不包含优先级字段的，IEEE802.1P是IEEE802.1Q(VLAN标签技术)标准的扩充技术，彼此之间协同工作。

802.1Q虽然定义了标签字段，但是并没有定义与使用优先级，而使用802.1P协议补充之后便可以正常使用优先级，正如IEEE 802.1P与IEEE802.1Q两者协同定义的标签字段如下图9所示：

图9 IEEE802.1Q标签头信息

以太网帧通过QoS特性来通过802.1Q标签中的802.1P用户优先级(COS)来进行标记，其优先级具备8级，从优先级0至优先级7，如下图10所示：

图10 COS优先级说明

通讯协议介绍

在使用车载以太网驱动的过程中，我们经常性会碰到如下三种常见的通讯协议，这三种通讯协议对于车载以太网正常工作，非常重要：

MII接口通讯协议，用于以太网MAC层与物理层收发器PHY之间的数据传输协议；

MDIO通讯协议，用于以太网MAC层控制PHY的状态设置与获取协议；

DMA通讯协议，用于以太网MAC层与CPU之间的数据搬运通讯协议，提高数据搬运效率，降低CPU负载；

MII接口通讯协议基础介绍

MII接口是IEEE802.3定义的以太网行业标准，该标准就是为了解决，以太网MAC层与PHY之间的兼容性，保证即使更换了不同类型的MAC，PHY始终能够正常工作。

MII接口随着技术的发展与进步，目前已经衍生出了多种增强型MII接口，常用的就有MII，RMII，SMII，SSMII，SSSMII，GMII，RGMII，SGMII ，其中对于车载以太网最为常用的还是RGMII接口。

具体的通讯协议介绍不在本文中进行展开，该接口的选择只要软件上MCAL配置使用对应的MII接口类型，其余都是硬件行为，硬件上保证接口正常连接即可，如下图11所示，介绍了MII接口在以太网硬件连接上的所处关系：

图11 以太网MAC与PHY之间的MII物理连接示意图

MDIO协议基础介绍

首先，MDIO是Management Data Input/Output的缩写，且该接口协议在IEEE802.3中也有所体现，是一种专门用于管理MAC与PHY之间的串口数据接口，基本功能如下：

读取PHY相关寄存器的值；

获取PHY的Link及其他工作状态等；

设置对应PHY的工作模式等；

除此之外，MDIO协议接口是一种实时，半双工，串行的数据接口，由两个线组成，一个被称为MDIO线，另外一根则是MDC线。

MDIO线负责数据的传输，MAC与PHY之间可以双向传输，写寄存器时由MAC驱动，读寄存器由PHY驱动，先传高位(MSB)，再传低位(LSB)，且该Pin脚需要上拉1.5kΩ-10kΩ范围内的电阻。

MDC线负责传递时钟同步信号，只能单向通过MAC驱动，且只能在MDC上升沿对MDIO线上的数据进行采样，该MDC允许最大的时间频率一般都通过PHY决定。

一个MDIO接口可支持32个PHY地址，该接口有32个寄存器地址，其中前16个寄存器已经在标准中定义，其余16个则有各个器件厂商自行定义。

根据IEEE802.3协议中将MDIO协议分为两种帧格式，分别为Clause 22与Clause 45，其中Clause 22主要用于千兆以下的以太网PHY，而Clause 45则用于千兆以上的以太网PHY。

接下来就针对Clause 22与Clause 45两者协议的基本使用与区别做个简要说明：

Clause 22读数据帧格式如下：

图12 Clause 22 读数据帧格式

Clause 22写数据帧格式如下：

图13 Clause 22 写数据帧格式

Clause 45 地址帧格式如下：

图14 Clause 45 地址帧格式

Clause 45 读数据帧格式如下：

图15 Clause 45 读数据帧格式

Clause 45 写数据帧格式如下：

图16 Clause 45 写数据帧格式

如下图17，小T根据上述Clause 22与Clause 45的帧格式定义，列举了两者之间的帧格式的定义说明以及区别联系，这样便于大家对两者格式的使用有个基本认识。

图17 Clause 22与Clause 45帧格式区别与联系

DMA协议基础介绍

DMA协议对于使用过它的朋友而言，特别是做底层驱动开发的朋友应该不会陌生，DMA就是为了在不需要CPU干预的前提下来实现外设与内存之间的搬运或者内存与内存之间的搬运，那么以太网DMA也是如此，就是为了实现以太网外设与内存之间的数据交换。

本文不会对DMA协议本身做过多的解释说明，旨在说明DMA在以太网数据收发过程中如何起作用，通过如下的两张图来了解认识DMA在以太网数据收发过程中的用途。

以太网DMA发送

如下图18所示，Tx ringbuffer作为DMA描述符，DMA在以太网发送过程中的作用表现：

图18 以太网DMA发送过程

以太网DMA接收

如下图19所示，Tx Ringbuffer作为DMA描述符，DMA在以太网接收过程中的作用表现：

图18 以太网DMA接收过程

常用函数总结

为了便于大家更好地使用Eth Driver这个模块，小T整理了关于车载以太网驱动这部分常用的函数接口与功能说明，如下图19所示：

图19 以太网驱动常用函数接口

审核编辑：刘清