正文

正如前文《車載以太網基礎篇之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 以太網驅動常用函數接口

審核編輯：劉清