正文

正如前文《車載以太網(wǎng)基礎(chǔ)篇之EthIf》所述，Eth Driver將作為配置以太網(wǎng)的底層驅(qū)動，不僅能夠被EthIf來進行調(diào)用，同時能夠滿足Eth收發(fā)器驅(qū)動的調(diào)用需求，因為有必要深入了解下車載以太網(wǎng)驅(qū)動(Eth Driver)在整個AUTOSAR層級中所扮演的重要作用。

如下圖1所示，Ethernet If模塊不僅會直接控制Ethernet Driver，如果存在Ethernet Switch驅(qū)動或者Ethernet Transiver驅(qū)動時，那么就會間接控制Ethernet Driver模塊，總而言之，以太網(wǎng)驅(qū)動不僅能夠完成以太網(wǎng)數(shù)據(jù)的正常收發(fā)，同時也能夠?qū)崿F(xiàn)針對以太網(wǎng)網(wǎng)關(guān)或者以太網(wǎng)收發(fā)器的直接配置。

圖1 Ethernet Driver與其他以太網(wǎng)驅(qū)動關(guān)系

AUTOSAR層次關(guān)系

按照AUTOSAR標準文檔規(guī)范，有關(guān)Eth Driver模塊在整個AUTOSAR軟件架構(gòu)的具體位置描述如下圖2所示：

圖2 Eth Driver與以太網(wǎng)協(xié)議棧關(guān)系

如上圖所示，可以得出如下幾個基本結(jié)論：

一個以太網(wǎng)協(xié)議棧中可以存在多家供應商的以太網(wǎng)控制器，同時針對每家供應商的控制器進行單獨控制，互不影響；

同一供應商的以太網(wǎng)控制器可以存在多個，但使用的以太網(wǎng)控制器驅(qū)動可以僅使用同一套；

上述三家不同供應商的以太網(wǎng)驅(qū)動作為標準AUTOSAR MCAL的一部分，能夠完全實現(xiàn)與底層硬件的解耦；

模塊主體功能

Eth Driver作為車載以太網(wǎng)協(xié)議棧最為重要的底層構(gòu)件，小T將帶領(lǐng)大家從以下幾個層面初步了解認識以太網(wǎng)驅(qū)動：

以太網(wǎng)各個不同驅(qū)動內(nèi)部的索引關(guān)系如何設定？

以太網(wǎng)驅(qū)動如何進行數(shù)據(jù)發(fā)送；

以太網(wǎng)驅(qū)動如何進行數(shù)據(jù)接收；

以太網(wǎng)驅(qū)動特性如QoS，硬件時間戳，Offloading都具備什么功能？

在以太網(wǎng)驅(qū)動常見的通信協(xié)議如MDIO，DMA如何在驅(qū)動中發(fā)揮作用？

驅(qū)動索引規(guī)則

如下圖3所示，每個以太網(wǎng)驅(qū)動彼此都是獨立的，同時其索引編號是從0開始，但是每個驅(qū)動內(nèi)部的bufidx均可以從0開始，彼此之間互不干擾。

圖3 Eth Driver索引關(guān)系

數(shù)據(jù)發(fā)送過程

上層應用如果需要通過Eth Driver將數(shù)據(jù)發(fā)送出去，那么就需要通過EthIf模塊間接調(diào)用Eth Driver的發(fā)送函數(shù)Eth_Transmit來完成數(shù)據(jù)的發(fā)送。

其中EthIf模塊的數(shù)據(jù)發(fā)送功能分為兩者模式，一種是Polling模式，另外一種就是Interrupt模式，一般而言都優(yōu)先采用中斷模式來滿足系統(tǒng)實時性要求。

如下圖4為Polling模式，在Polling模式中可以看到在EthIf_MainfunctionTx函數(shù)中會去輪詢是否發(fā)送成功的標志，這個也是Polling模式的典型特征。

Polling模式

圖4 數(shù)據(jù)發(fā)送Polling模式

Interrupt模式

如下圖5所示為以太網(wǎng)數(shù)據(jù)發(fā)送的中斷模式，中斷模式相比Polling模式可以看出并沒有使用到EthIf_MainfunctionTx函數(shù)，而是使用Eth模塊的中斷函數(shù)來確認發(fā)送是否成功。

圖5 數(shù)據(jù)發(fā)送中斷模式

數(shù)據(jù)接收功能

同理相比數(shù)據(jù)發(fā)送功能，EthIf模塊的數(shù)據(jù)接收功能也可以分為Polling模式與中斷模式兩種，如下圖9所示為EthIf模塊的數(shù)據(jù)接收Polling模式。

如下圖6所示，如果EthIf模塊數(shù)據(jù)接收采用Polling模式，那么就需要使用到EthIf_MainfunctionRx函數(shù)，在該函數(shù)中去調(diào)用EthIf_RxIndication來告知上層數(shù)據(jù)已成功被接收，使用該模式會大大降低數(shù)據(jù)接收效率，一般接收優(yōu)先采用中斷模式。

Polling模式

圖6 數(shù)據(jù)接收Polling模式

Interrupt模式

如下圖7所示為EthIf模塊的數(shù)據(jù)接收中斷功能，在該模式中可以看到通過Eth模塊通過中斷函數(shù)來進而告知上層數(shù)據(jù)已被接收。

圖7 數(shù)據(jù)接收中斷模式

驅(qū)動特性簡介

以太網(wǎng)驅(qū)動相比其他驅(qū)動而言，存在很多諸多獨有的特性，小T將會帶領(lǐng)大家來了解這些特性，爭取對這些特性有個基本的認識，以便我們對以太網(wǎng)驅(qū)動有個較為全面的了解，應用它時也會更加得心應手。

以下列舉了以太網(wǎng)驅(qū)動(網(wǎng)卡)常見的三種特性：Offloading 特性，硬件TimeStamp特性，QoS特性。

Offloading特性

“Offload"顧名思義表示卸載的意思，那么給誰卸載以及卸載什么呢？其實該特性存在的目的就是為了給CPU卸載，卸載的方式如將CRC計算交給硬件來做，或者分包組包的動作也放在硬件中來處理，從而減小這部分在以太網(wǎng)協(xié)議棧中的占用時間，降低軟件運行延遲造成的性能不足以及CPU loading過高等問題。

在AUTOSAR規(guī)范中針對以太網(wǎng)驅(qū)動(Eth Driver)發(fā)送或者接收報文的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基礎(chǔ)篇之CanTsyn》與《AUTOSAR基礎(chǔ)篇之StbM》所述，大家相比CAN時間同步有了一個基本的認識與了解，與CAN時間同步對比，以太網(wǎng)時間同步協(xié)議采用的IEEE1588或者IEEE802.1AS的PTP(Precise Time Protocal)協(xié)議，該協(xié)議需要確認使用的網(wǎng)卡(MAC)是否本身支持。

該協(xié)議使用到通過底層硬件MAC來打上對應的以太網(wǎng)報文收發(fā)的時間戳，能夠最大限度地降低軟件時間戳所帶來的不確定性，將時間同步精度能夠做到微秒甚至是納微秒級別。

AUTOSAR規(guī)范中定義的EthTsync模塊使用的是雙步端延時PTP時間同步協(xié)議，如下為基于該協(xié)議的Time Master與Time Slave兩者之間的交互關(guān)系，后期也會針對EthTsync模塊進行單一講解，敬請關(guān)注。

圖8 雙步以太網(wǎng)端延時機制PTP時間同步協(xié)議

如上圖8所示，如果是基于單步模式下的以太網(wǎng)端延時機制的PTP時間同步，那么虛線標注的部分則不會有，如果是基于雙步模式下的以太網(wǎng)端延時機制的PTP時間同步，那么虛線標注的部分必須要有。

值得注意的是在IEEE802.1AS存在一個GrandMaster概念，需要通過BMCA(Best Master Clock Algorithm)來實現(xiàn)，不過由于汽車內(nèi)部屬于靜態(tài)網(wǎng)絡，因此只會存在唯一的GrandMaster，無需使用到BMCA動態(tài)分配確認算法。

以太網(wǎng)硬件實現(xiàn)PTP協(xié)議有如下兩種方式：

以太網(wǎng)MAC控制器支持PTP協(xié)議，常見雙步模式；

有些TI的PHY層也可以支持PTP，不過一般是單步模式，如果使用AUTOSAR標準的EthTsync模塊，要提前確認是否支持雙步模式；

QoS特性

Qos是IEEE 802.1P協(xié)議，該協(xié)議運行在以太網(wǎng)第二層，用來保證在以太網(wǎng)數(shù)據(jù)轉(zhuǎn)發(fā)擁堵時通過優(yōu)先級方式來保證重要的數(shù)據(jù)包能夠及時發(fā)送出去。

普通的以太網(wǎng)二層報文是不包含優(yōu)先級字段的，IEEE802.1P是IEEE802.1Q(VLAN標簽技術(shù))標準的擴充技術(shù)，彼此之間協(xié)同工作。

802.1Q雖然定義了標簽字段，但是并沒有定義與使用優(yōu)先級，而使用802.1P協(xié)議補充之后便可以正常使用優(yōu)先級，正如IEEE 802.1P與IEEE802.1Q兩者協(xié)同定義的標簽字段如下圖9所示：

圖9 IEEE802.1Q標簽頭信息

以太網(wǎng)幀通過QoS特性來通過802.1Q標簽中的802.1P用戶優(yōu)先級(COS)來進行標記，其優(yōu)先級具備8級，從優(yōu)先級0至優(yōu)先級7，如下圖10所示：

圖10 COS優(yōu)先級說明

通訊協(xié)議介紹

在使用車載以太網(wǎng)驅(qū)動的過程中，我們經(jīng)常性會碰到如下三種常見的通訊協(xié)議，這三種通訊協(xié)議對于車載以太網(wǎng)正常工作，非常重要：

MII接口通訊協(xié)議，用于以太網(wǎng)MAC層與物理層收發(fā)器PHY之間的數(shù)據(jù)傳輸協(xié)議；

MDIO通訊協(xié)議，用于以太網(wǎng)MAC層控制PHY的狀態(tài)設置與獲取協(xié)議；

DMA通訊協(xié)議，用于以太網(wǎng)MAC層與CPU之間的數(shù)據(jù)搬運通訊協(xié)議，提高數(shù)據(jù)搬運效率，降低CPU負載；

MII接口通訊協(xié)議基礎(chǔ)介紹

MII接口是IEEE802.3定義的以太網(wǎng)行業(yè)標準，該標準就是為了解決，以太網(wǎng)MAC層與PHY之間的兼容性，保證即使更換了不同類型的MAC，PHY始終能夠正常工作。

MII接口隨著技術(shù)的發(fā)展與進步，目前已經(jīng)衍生出了多種增強型MII接口，常用的就有MII，RMII，SMII，SSMII，SSSMII，GMII，RGMII，SGMII ，其中對于車載以太網(wǎng)最為常用的還是RGMII接口。

具體的通訊協(xié)議介紹不在本文中進行展開，該接口的選擇只要軟件上MCAL配置使用對應的MII接口類型，其余都是硬件行為，硬件上保證接口正常連接即可，如下圖11所示，介紹了MII接口在以太網(wǎng)硬件連接上的所處關(guān)系：

圖11 以太網(wǎng)MAC與PHY之間的MII物理連接示意圖

MDIO協(xié)議基礎(chǔ)介紹

首先，MDIO是Management Data Input/Output的縮寫，且該接口協(xié)議在IEEE802.3中也有所體現(xiàn)，是一種專門用于管理MAC與PHY之間的串口數(shù)據(jù)接口，基本功能如下：

讀取PHY相關(guān)寄存器的值；

獲取PHY的Link及其他工作狀態(tài)等；

設置對應PHY的工作模式等；

除此之外，MDIO協(xié)議接口是一種實時，半雙工，串行的數(shù)據(jù)接口，由兩個線組成，一個被稱為MDIO線，另外一根則是MDC線。

MDIO線負責數(shù)據(jù)的傳輸，MAC與PHY之間可以雙向傳輸，寫寄存器時由MAC驅(qū)動，讀寄存器由PHY驅(qū)動，先傳高位(MSB)，再傳低位(LSB)，且該Pin腳需要上拉1.5kΩ-10kΩ范圍內(nèi)的電阻。

MDC線負責傳遞時鐘同步信號，只能單向通過MAC驅(qū)動，且只能在MDC上升沿對MDIO線上的數(shù)據(jù)進行采樣，該MDC允許最大的時間頻率一般都通過PHY決定。

一個MDIO接口可支持32個PHY地址，該接口有32個寄存器地址，其中前16個寄存器已經(jīng)在標準中定義，其余16個則有各個器件廠商自行定義。

根據(jù)IEEE802.3協(xié)議中將MDIO協(xié)議分為兩種幀格式，分別為Clause 22與Clause 45，其中Clause 22主要用于千兆以下的以太網(wǎng)PHY，而Clause 45則用于千兆以上的以太網(wǎng)PHY。

接下來就針對Clause 22與Clause 45兩者協(xié)議的基本使用與區(qū)別做個簡要說明：

Clause 22讀數(shù)據(jù)幀格式如下：

圖12 Clause 22 讀數(shù)據(jù)幀格式

Clause 22寫數(shù)據(jù)幀格式如下：

圖13 Clause 22 寫數(shù)據(jù)幀格式

Clause 45 地址幀格式如下：

圖14 Clause 45 地址幀格式

Clause 45 讀數(shù)據(jù)幀格式如下：

圖15 Clause 45 讀數(shù)據(jù)幀格式

Clause 45 寫數(shù)據(jù)幀格式如下：

圖16 Clause 45 寫數(shù)據(jù)幀格式

如下圖17，小T根據(jù)上述Clause 22與Clause 45的幀格式定義，列舉了兩者之間的幀格式的定義說明以及區(qū)別聯(lián)系，這樣便于大家對兩者格式的使用有個基本認識。

圖17 Clause 22與Clause 45幀格式區(qū)別與聯(lián)系

DMA協(xié)議基礎(chǔ)介紹

DMA協(xié)議對于使用過它的朋友而言，特別是做底層驅(qū)動開發(fā)的朋友應該不會陌生，DMA就是為了在不需要CPU干預的前提下來實現(xiàn)外設與內(nèi)存之間的搬運或者內(nèi)存與內(nèi)存之間的搬運，那么以太網(wǎng)DMA也是如此，就是為了實現(xiàn)以太網(wǎng)外設與內(nèi)存之間的數(shù)據(jù)交換。

本文不會對DMA協(xié)議本身做過多的解釋說明，旨在說明DMA在以太網(wǎng)數(shù)據(jù)收發(fā)過程中如何起作用，通過如下的兩張圖來了解認識DMA在以太網(wǎng)數(shù)據(jù)收發(fā)過程中的用途。

以太網(wǎng)DMA發(fā)送

如下圖18所示，Tx ringbuffer作為DMA描述符，DMA在以太網(wǎng)發(fā)送過程中的作用表現(xiàn)：

圖18 以太網(wǎng)DMA發(fā)送過程

以太網(wǎng)DMA接收

如下圖19所示，Tx Ringbuffer作為DMA描述符，DMA在以太網(wǎng)接收過程中的作用表現(xiàn)：

圖18 以太網(wǎng)DMA接收過程

常用函數(shù)總結(jié)

為了便于大家更好地使用Eth Driver這個模塊，小T整理了關(guān)于車載以太網(wǎng)驅(qū)動這部分常用的函數(shù)接口與功能說明，如下圖19所示：

圖19 以太網(wǎng)驅(qū)動常用函數(shù)接口

審核編輯：劉清