汽車電子控制器處理芯片及ECU板級(jí)抽象技術(shù)研究報(bào)告

1、 密級(jí)： 汽車電子控制器處理芯片及ECU板級(jí)抽象技術(shù)研究報(bào)告編號(hào)TM-DMP-01-RD-PRE-013擬制陳麗蓉日期 2010 年 2 月 1 日審核日期 年 月 日會(huì)簽日期 年 月 日標(biāo)準(zhǔn)化日期 年 月 日批準(zhǔn)日期 年 月 日顧客/代表日期 年 月 日此文檔版權(quán)歸北京科銀京成技術(shù)有限公司所有。未經(jīng)公司許可，文檔內(nèi)容不得以任何方式外傳。修訂歷史記錄日期&修訂人修訂記錄版本標(biāo)識(shí)備注2010/4/20陳麗蓉完成初稿V1.02010-4-29趙煥宇增加硬件特征描述V1.1 北京科銀京成技術(shù)有限公司 汽車電子控制器處理芯片及ECU板級(jí)抽象技術(shù)研究報(bào)告目 錄引言1背景1概述1縮寫詞和名詞定義1參考資料

2、21 AUTOSAR國(guó)際標(biāo)準(zhǔn)分析31.1 系統(tǒng)概述31.2 微控制器抽象層71.3 復(fù)雜驅(qū)動(dòng)171.4 ECU抽象層191.6 抽象接口實(shí)現(xiàn)示例321.7 主要參考的AUTOSAR規(guī)范列表352 主流汽車電子嵌入式微處理器及ECU硬件特性分析372.1 MPC563X嵌入式微處理器特性372.2 MPC5554特性382.3 MPC555特性392.4 9S12X特性402.5 9S12DP512特性412.6 HCS08特性412.7 STM08特性423 開發(fā)環(huán)境433.1 基礎(chǔ)開發(fā)工具433.2 配置生成工具444 國(guó)內(nèi)汽車廠商應(yīng)用需求分析444.1 一汽應(yīng)用需求分析444.2 上汽應(yīng)用

3、需求分析504.3 奇瑞應(yīng)用需求分析504.4 長(zhǎng)安應(yīng)用需求分析505 汽車電子控制器處理芯片及ECU板級(jí)抽象軟件實(shí)現(xiàn)策略515.1 控制器處理芯片抽象軟件實(shí)現(xiàn)策略515.2 ECU板級(jí)抽象軟件實(shí)現(xiàn)策略5146引言背景本項(xiàng)目來(lái)源于核高基重大專項(xiàng)3-1課題：實(shí)時(shí)嵌入式操作系統(tǒng)及開發(fā)環(huán)境，本項(xiàng)目為該課題的分課題：汽車電子硬件抽象技術(shù)研究。在分課題中，科銀京成將以總課題組制定的汽車電子基礎(chǔ)軟件平臺(tái)體系規(guī)范為基礎(chǔ)，通過(guò)對(duì)國(guó)內(nèi)外相關(guān)技術(shù)和標(biāo)準(zhǔn)的充分研究，以及汽車電子控制系統(tǒng)硬件平臺(tái)的詳細(xì)調(diào)研，研究汽車電子硬件抽象的關(guān)鍵技術(shù)，設(shè)計(jì)開發(fā)汽車電子基礎(chǔ)軟件平臺(tái)中的硬件驅(qū)動(dòng)軟件模塊，并實(shí)現(xiàn)對(duì)電子控制單元（ECU）

4、和微控制器外部設(shè)備的抽象，為汽車電子基礎(chǔ)軟件平臺(tái)中其他相關(guān)的軟件組件如嵌入式實(shí)時(shí)操作系統(tǒng)與系統(tǒng)服務(wù)、存儲(chǔ)服務(wù)、通信服務(wù)等各種服務(wù)及管理組件（包括驅(qū)動(dòng)自身的管理組件）提供支持和功能調(diào)用、以及系統(tǒng)的引導(dǎo)啟動(dòng)、系統(tǒng)軟件加載等支撐服務(wù)；為支撐本課題組形成汽車電子應(yīng)用軟件設(shè)計(jì)、編程、調(diào)試、仿真、集成、測(cè)試、部署的一體化工具環(huán)境，提供與硬件適配相關(guān)的圖形化配置工具、部署工具及接口，以便在進(jìn)行應(yīng)用開發(fā)時(shí)能有效地完成硬件相關(guān)的配置和使用。概述本文檔將從以下幾方面描述有關(guān)汽車電子控制器處理芯片及ECU板級(jí)抽象技術(shù)研究的內(nèi)容：l AUTOSAR標(biāo)準(zhǔn)分析l 主流汽車電子嵌入式微處理器及ECU硬件特性分析l 開發(fā)環(huán)境

5、l 國(guó)內(nèi)汽車廠商應(yīng)用需求分析l 汽車電子控制器處理芯片及ECU板級(jí)抽象軟件實(shí)現(xiàn)策略縮寫詞和名詞定義縮寫、術(shù)語(yǔ)解 釋AUTOSARAUTomotive Open System Architecture 汽車開放系統(tǒng)結(jié)構(gòu)DIODigital Input/Output 數(shù)字輸入/輸出ADCAnalogue Digital Converter 模數(shù)轉(zhuǎn)換器SPISerial Peripheral Interface 串行外設(shè)接口PWMPulse Width Modulation 脈沖寬度調(diào)制PORT端口ICUInput Capture Unit 輸入捕獲單元Watchdog看門狗FLASH閃存EEPRO

6、M電子可檫除、可編程只讀存儲(chǔ)器RAM test內(nèi)存測(cè)試CANController Area Network 控制器局域網(wǎng)Timer定時(shí)器SCI串行通信接口參考資料l AUTOSAR 3.1系列規(guī)范l 各種汽車電子嵌入式微處理器芯片手冊(cè)、ECU板級(jí)資料1 AUTOSAR國(guó)際標(biāo)準(zhǔn)分析以AUTOSAR 3.1為參考，對(duì)汽車電子基礎(chǔ)軟件架構(gòu)進(jìn)行分析，通過(guò)對(duì)AUTOSAR、OSEK國(guó)際規(guī)范的分析和研究，包括在：標(biāo)準(zhǔn)接口、配置描述語(yǔ)言、基本數(shù)據(jù)類型、文件組織結(jié)構(gòu)、錯(cuò)誤處理機(jī)制等內(nèi)容上，集合國(guó)內(nèi)整車廠商和零部件廠商的實(shí)際需求，形成自主汽車電子基礎(chǔ)軟件規(guī)范中關(guān)于汽車電子硬件抽象層（板載設(shè)備抽象、存儲(chǔ)器抽象、通

7、信器件抽象、I/O硬件抽象等）統(tǒng)一接口規(guī)范。1.1 系統(tǒng)概述圖1展示了AUTOSAR軟件架構(gòu)的主要層次關(guān)系，總體上可分為應(yīng)用層、運(yùn)行時(shí)環(huán)境、基礎(chǔ)層（包括操作系統(tǒng)與系統(tǒng)服務(wù)、存儲(chǔ)服務(wù)、通信服務(wù)、硬件抽象與驅(qū)動(dòng)層）。圖1 AUTOSAR嵌入式軟件架構(gòu)圖2 AUTOSAR嵌入式軟件分層架構(gòu)圖3 AUTOSAR嵌入式軟件各層次模塊目標(biāo)硬件環(huán)境適配層處于汽車電子基礎(chǔ)軟件平臺(tái)中最底層的位置，其作用是向上層軟件屏蔽微控制器和ECU硬件設(shè)備驅(qū)動(dòng)的細(xì)節(jié)和差異，是降低汽車電子應(yīng)用軟件與硬件的相關(guān)性，提高汽車電子應(yīng)用軟件和功能組件可重用性和可移植性的重要技術(shù)手段。本課題中目標(biāo)硬件環(huán)境適配層由硬件抽象層和設(shè)備驅(qū)動(dòng)層組

8、成，如下圖所示：圖4 目標(biāo)硬件環(huán)境適配層注：上圖中Flash Check，Ext Watchdog Driver，Ext EEPROM Driver，Ext Flash Driver，Ext Can Driver，Ext FlexRay Driver，Complex Driver等7個(gè)基礎(chǔ)軟件模塊目前不屬于AUTOSAR 3.1的規(guī)范。設(shè)備驅(qū)動(dòng)層提供控制和訪問(wèn)設(shè)備的功能，由以下模塊組成：1、 通信驅(qū)動(dòng)程序ECU板上（如SPI）和車輛通信（如CAN）的驅(qū)動(dòng)程序。2、 I/O驅(qū)動(dòng)程序模擬和數(shù)據(jù)I/O（如ADC、PWM、DIO）的驅(qū)動(dòng)程序。3、 存儲(chǔ)驅(qū)動(dòng)程序片上存儲(chǔ)設(shè)備（如內(nèi)部FLASH、內(nèi)部EEP

9、ROM）及內(nèi)存映射的外部存儲(chǔ)設(shè)備（如外部FLASH）驅(qū)動(dòng)程序。4、 微控制器驅(qū)動(dòng)程序其它內(nèi)部設(shè)備（如Watchdog、通用時(shí)鐘）的驅(qū)動(dòng)程序；直接訪問(wèn)微控制器的功能（如核心調(diào)試）。設(shè)備抽象層對(duì)ECU板上設(shè)備的物理特性進(jìn)行抽象，向操作系統(tǒng)、系統(tǒng)服務(wù)和支撐服務(wù)提供統(tǒng)一的訪問(wèn)接口。汽車電子硬件抽象技術(shù)的研究必要性，主要由于汽車電子系統(tǒng)應(yīng)用的硬件環(huán)境差異軟大，因此，如何有效地使汽車電子系統(tǒng)軟件應(yīng)用于各種不同的應(yīng)用環(huán)境是汽車電子發(fā)展中必須解決的關(guān)鍵問(wèn)題，經(jīng)過(guò)不斷的發(fā)展，在操作系統(tǒng)內(nèi)核和各類服務(wù)層軟件與微控制器硬件之間新增加抽象技術(shù)，包含操作系統(tǒng)內(nèi)核和各類服務(wù)層及硬件所要求的所有功能，通過(guò)標(biāo)準(zhǔn)統(tǒng)一的接口與上

10、層操作系統(tǒng)和各類服務(wù)進(jìn)行交互，向底層硬件傳遞信息，這樣就有效地屏蔽了底層硬件的多樣性，上層操作系統(tǒng)和各類服務(wù)不再直接面對(duì)具體的硬件環(huán)境，使硬件系統(tǒng)與軟件系統(tǒng)得到了很好分離，大大提高了移植性和重用性。對(duì)汽車電子硬件抽象技術(shù)的研究主要達(dá)到的目標(biāo)是：隱藏特定平臺(tái)的硬件接口細(xì)節(jié)，為操作系統(tǒng)實(shí)時(shí)內(nèi)核、系統(tǒng)服務(wù)、存儲(chǔ)服務(wù)、通信服務(wù)、提供所需硬件支持的所有功能和統(tǒng)一的標(biāo)準(zhǔn)接口，使其具有與硬件無(wú)關(guān)性，可在多種硬件平臺(tái)上進(jìn)行移植，從軟硬件測(cè)試的角度來(lái)看，軟硬件的測(cè)試工作都可分別基于硬件抽象層來(lái)完成，使得軟硬件測(cè)試工作的并行進(jìn)行成為可能。1.2 微控制器抽象層圖5 微控制器抽象層模塊圖1.2.1 通信驅(qū)動(dòng)通信驅(qū)動(dòng)

11、層主要包括：SPI驅(qū)動(dòng)、LIN驅(qū)動(dòng)、CAN驅(qū)動(dòng)、FlexRay驅(qū)動(dòng)等內(nèi)容。1.2.1.1 SPI驅(qū)動(dòng)（SPI Handler Driver）SPI驅(qū)動(dòng)提供外設(shè)的SPI讀寫通信控制驅(qū)動(dòng)。在很多ECU中，許多板載硬件設(shè)備如外部EEPROM，外部I/O ASIC，外部看門狗等，通過(guò)SPI與微控制器連接，如下圖所示。圖6 通過(guò)SPI接口訪問(wèn)各種板級(jí)外設(shè)SPIHandlerDriver允許多個(gè)客戶端對(duì)一個(gè)或多個(gè)SPI總線的并發(fā)訪問(wèn)。為了抽象SPI的特征，SPIHandlerDriver要直接處理微控制器中的片選引腳。這就意味著這些引腳對(duì)DIO驅(qū)動(dòng)無(wú)效。SPI總線是一種主從多節(jié)點(diǎn)總線系統(tǒng)，主節(jié)點(diǎn)設(shè)置片選（

12、CS）來(lái)選擇一個(gè)從節(jié)點(diǎn)來(lái)進(jìn)行數(shù)據(jù)通信。SPI有一個(gè)4線的同步串行接口。使用片選線來(lái)激活數(shù)據(jù)通信。SPI模塊提供基于通道的對(duì)SPI總線上的不同設(shè)備的讀、寫和傳輸訪問(wèn)。SPI通道代表數(shù)據(jù)元素（8到16比特）。這些通道可能是順序組合的，不能夠被中斷。通道有一個(gè)靜態(tài)配置定義的波特率、片選等等。SPI設(shè)備通常由所使用的SPI硬件單元和相關(guān)的片選線來(lái)標(biāo)識(shí)。這個(gè)模塊能夠作為SPI主節(jié)點(diǎn)來(lái)使用。這個(gè)軟件模塊的功能范圍應(yīng)該是可靜態(tài)配置的，以盡可能多的適應(yīng)每個(gè)ECU的時(shí)間需要。那就是說(shuō)，比如同步的、異步的、或者兩者都有的SPI訪問(wèn)都可以存在于ECU。因此，兩個(gè)SPI驅(qū)動(dòng)可以存在，但僅有一個(gè)處理接口。SPI處理程序

13、/驅(qū)動(dòng)提供了一些服務(wù)來(lái)對(duì)通過(guò)SPI總線連接的設(shè)備進(jìn)行讀寫。它提供了所需的機(jī)制來(lái)配置片上SPI外設(shè)。單片式的SPI處理程序/驅(qū)動(dòng)包含處理和驅(qū)動(dòng)功能。它的主要目標(biāo)是充分利用每個(gè)微控制器的特性，使得依賴于靜態(tài)配置的實(shí)現(xiàn)最優(yōu)化，以盡可能多的適應(yīng)ECU的需要。1.2.1.2 LIN驅(qū)動(dòng)LIN驅(qū)動(dòng)為上層的LIN 接口模塊提供硬件抽象接口，負(fù)責(zé)對(duì)LIN 硬件進(jìn)行控制，比如初始化。對(duì)于屬于相同LIN硬件單元LIN驅(qū)動(dòng)模塊支持多路通道。只支持LIN2.0主節(jié)點(diǎn)。其軟件架構(gòu)如下圖：圖7 LIN Driver架構(gòu)LIN驅(qū)動(dòng)是最底層的一部分，執(zhí)行硬件訪問(wèn)和為上層提供硬件無(wú)關(guān)的API。上層唯一能夠訪問(wèn)到LIN驅(qū)動(dòng)的就是

14、LIN接口。一個(gè)LIN驅(qū)動(dòng)能夠支持一個(gè)以上的通道。LIN驅(qū)動(dòng)能夠處理一個(gè)或多個(gè)屬于相同LIN硬件單元的LIN通道。1.2.1.3 CAN驅(qū)動(dòng)CAN驅(qū)動(dòng)為上層的CAN 接口模塊提供硬件抽象接口，負(fù)責(zé)對(duì)CAN硬件傳輸進(jìn)行初始化，實(shí)現(xiàn)事件通知，控制屬于相同CAN硬件單元的CAN控制器。CAN驅(qū)動(dòng)盡可能合理地隱藏了相關(guān)CAN控制器的硬件專用性。CAN驅(qū)動(dòng)是最底層的一部分，為上層執(zhí)行對(duì)硬件的訪問(wèn)和提供硬件無(wú)關(guān)的API。上層中唯一能夠訪問(wèn)CAN驅(qū)動(dòng)的是CAN接口。如果幾個(gè)CAN控制器屬于相同的CAN硬件單元，那么它們能夠由CAN驅(qū)動(dòng)來(lái)控制。一個(gè)CAN控制器總是與一個(gè)物理通道相關(guān)聯(lián)。它被允許與總線上的物理通

15、道相連接，不管CAN接口是否將相關(guān)的CAN控制器分別對(duì)待。1.2.1.4 FlexRay驅(qū)動(dòng)FlexRay驅(qū)動(dòng)為上層的FlexRay 接口模塊提供硬件抽象接口，負(fù)責(zé)對(duì)FlexRay 硬件傳輸進(jìn)行初始化，實(shí)現(xiàn)事件通知，控制屬于相同F(xiàn)lexRay 硬件單元的FlexRay 控制器。FlexRay驅(qū)動(dòng)模塊必須為FlexRay接口模塊、API的使用者提供統(tǒng)一接口，以訪問(wèn)許多FlexRay通信控制器，這些控制器通常是相同類型的。FlexRay驅(qū)動(dòng)是一個(gè)軟件層，它將抽象功能請(qǐng)求映射到CC專用硬件的序列上。CC的硬件實(shí)現(xiàn)將從FlexRay接口隱藏。1.2.2 I/O驅(qū)動(dòng)1.2.2.1 ICU驅(qū)動(dòng)ICU輸入捕

16、獲單元驅(qū)動(dòng)：對(duì)周期性輸入信號(hào)進(jìn)行頻率檢測(cè)以及占空比測(cè)量，計(jì)算脈沖，解調(diào)脈寬調(diào)制信號(hào)，捕獲非周期輸入信號(hào)，產(chǎn)生相應(yīng)的中斷或喚醒中斷。ICU驅(qū)動(dòng)提供了下列特性：周期性的、低端的、高端的時(shí)間測(cè)量邊緣檢測(cè)和通知邊緣計(jì)數(shù)邊緣時(shí)間戳，可用于獲取非周期的信號(hào)喚醒中斷對(duì)于信號(hào)邊緣檢測(cè)來(lái)說(shuō)，需要使用捕獲比較單元的邊緣檢測(cè)器或外部時(shí)間的中斷控制器。對(duì)于信號(hào)測(cè)量來(lái)說(shuō)，需要一個(gè)捕獲計(jì)時(shí)器以及至少一個(gè)捕獲寄存器。ICU調(diào)制PWM信號(hào)，計(jì)算脈沖，測(cè)量頻率和責(zé)任（duty）周期，產(chǎn)生簡(jiǎn)單的中斷以及喚醒中斷。為了保證數(shù)據(jù)一致性，應(yīng)該提供可重入的代碼。時(shí)間單元節(jié)拍為了從寄存器值中獲得時(shí)間，需要知道振蕩器頻率、預(yù)定標(biāo)器等等。因?yàn)?/p>

17、這些設(shè)置是在MCU模塊中或其它模塊中產(chǎn)生的，不可能計(jì)算這些時(shí)間。因此，時(shí)間和節(jié)拍之間的轉(zhuǎn)換是由上層負(fù)責(zé)的。1.2.2.2 PWM驅(qū)動(dòng)PWM脈寬調(diào)制驅(qū)動(dòng)負(fù)責(zé)對(duì)微控制器內(nèi)部PWM端口進(jìn)行初始化和控制。每個(gè)PWM通道都連接到一個(gè)屬于微控制器的硬件PWM上。該驅(qū)動(dòng)提供了初始化和控制微處理器內(nèi)部的PWM的服務(wù)。PWM模塊產(chǎn)生有不同脈沖寬度的脈沖。1.2.2.3 ADC驅(qū)動(dòng)ADC模數(shù)轉(zhuǎn)換驅(qū)動(dòng)：負(fù)責(zé)對(duì)微控制器內(nèi)部ADC端口進(jìn)行初始化和控制。ADC驅(qū)動(dòng)初始化并控制微控制器內(nèi)部的模數(shù)轉(zhuǎn)換單元。該驅(qū)動(dòng)包含一系列的基本功能函數(shù)。為了能夠在某些特殊的應(yīng)用中進(jìn)行信號(hào)的頻率分析（例如，快速傅立葉變換），就需要加強(qiáng)流式存取

18、的功能。ADC驅(qū)動(dòng)提供以下服務(wù)：信號(hào)值結(jié)果的訪問(wèn)模式流式訪問(wèn)。通常，ADC通道的變換請(qǐng)求通過(guò)ADC通道組來(lái)進(jìn)行控制。通道組可以運(yùn)行于持續(xù)的變換模式或者單觸發(fā)變換模式。變換處理和交互作用：在同一時(shí)刻，ADC驅(qū)動(dòng)要管理一個(gè)以上的被配置成不同變換模式的組。轉(zhuǎn)換過(guò)程：通常，ADC通道的轉(zhuǎn)換請(qǐng)求通過(guò)ADC通道組來(lái)進(jìn)行控制。一個(gè)組可以運(yùn)行于持續(xù)的轉(zhuǎn)換模式或者單觸發(fā)轉(zhuǎn)換模式。單觸發(fā)轉(zhuǎn)換模式的觸發(fā)條件也要被配置和控制。如果通道運(yùn)行于不同的模式（例如，在普通操作時(shí)采用持續(xù)的轉(zhuǎn)換模式，在特定時(shí)間點(diǎn)的特殊轉(zhuǎn)換時(shí)使用單觸發(fā)或者按照命令的轉(zhuǎn)換方式），通道必須被分配給擁有不同操作模式的多個(gè)組。為了改變組間共享的通道的操作

19、模式，應(yīng)用程序必須停止任何對(duì)包含指定通道的組的當(dāng)前轉(zhuǎn)換，然后啟動(dòng)包含指定通道的新組的轉(zhuǎn)換。為了讓應(yīng)用程序能夠在任何時(shí)候執(zhí)行立即轉(zhuǎn)換，就要定義一個(gè)按照命令的轉(zhuǎn)換方式。它必須掛起組轉(zhuǎn)換，然后在按照命令的轉(zhuǎn)換活動(dòng)完成后重新激活它。1.2.2.4 DIO驅(qū)動(dòng)DIO數(shù)字化I/O驅(qū)動(dòng)負(fù)責(zé)對(duì)DIO通道的管腳和組以及端口進(jìn)行讀寫。DIO驅(qū)動(dòng)提供基于端口和通道的、對(duì)內(nèi)部通用I/O斷點(diǎn)的讀和寫訪問(wèn)。這里的讀和寫并不被緩沖。這個(gè)驅(qū)動(dòng)的基本行為是同步的。DIO驅(qū)動(dòng)提供了用于對(duì)下列設(shè)施進(jìn)行讀、寫的服務(wù)：DIO通道（引腳）DIO端口DIO通道組這些服務(wù)的行為是同步的。該模塊工作于引腳和端口上，由PORT驅(qū)動(dòng)來(lái)對(duì)它進(jìn)行配置

20、。因此，在DIO驅(qū)動(dòng)里面就沒(méi)有對(duì)該端口結(jié)構(gòu)進(jìn)行配置和初始化。端口驅(qū)動(dòng)模塊：很多端口和端口引腳是由端口驅(qū)動(dòng)模塊分配給各種功能的，比如常規(guī)I/OADCSPIPWMDIO驅(qū)動(dòng)抽象了對(duì)微控制器硬件引腳的訪問(wèn)。此外，它還能夠?qū)@些引腳進(jìn)行分組。DIO驅(qū)動(dòng)提供以下服務(wù)：一個(gè)一個(gè)地修改端口或通道組的輸出通道的等級(jí)。一個(gè)一個(gè)地讀取端口或通道組的輸入和輸出通道的等級(jí)。DIO驅(qū)動(dòng)中的所有讀寫服務(wù)必須是可重入的。理由是：這些DIO驅(qū)動(dòng)可以被不同的上層處理程序或驅(qū)動(dòng)程序訪問(wèn)。這些上層模塊可以并行的訪問(wèn)驅(qū)動(dòng)。1.2.2.5 PORT驅(qū)動(dòng)PORT(端口)驅(qū)動(dòng)提供微控制所有端口的初始化。該模塊初始化微控制器的整個(gè)端口結(jié)構(gòu)。

21、很多端口和端口引腳可以被分配給不同的功能，比如：通用I/OADCSPISCIPWM由于這個(gè)原因，必須對(duì)這個(gè)端口結(jié)構(gòu)進(jìn)行總的配置和初始化。這些端口引腳的配置和使用是依賴于微控制器和ECU的。該模塊應(yīng)該提供用于初始化微控制器的整個(gè)端口結(jié)構(gòu)的服務(wù)。很多端口和端口引腳可以被分配給各種不同的功能。由于這個(gè)原因，必須有該端口結(jié)構(gòu)的全部配置和初始化。這些端口引腳的配置和模式是依賴于微控制器和ECU的。該端口驅(qū)動(dòng)模塊應(yīng)該完成端口結(jié)構(gòu)的全部配置和初始化，該端口結(jié)構(gòu)是用在DIO驅(qū)動(dòng)模塊中的。因此，DIO驅(qū)動(dòng)工作再引腳和端口之上，由端口驅(qū)動(dòng)對(duì)它進(jìn)行配置。端口和端口引腳的配置順序是由配置工具負(fù)責(zé)的。端口驅(qū)動(dòng)應(yīng)該在使用

22、DIO功能之前進(jìn)行初始化。否則DIO驅(qū)動(dòng)會(huì)產(chǎn)生未定義的行為。端口訪問(wèn)的原子性：端口驅(qū)動(dòng)應(yīng)該通過(guò)使用原子指令或者利用OS的中斷屏蔽功能來(lái)提供對(duì)端口的原子訪問(wèn)。1.2.3 存儲(chǔ)器驅(qū)動(dòng)存儲(chǔ)器驅(qū)動(dòng)層主要包括內(nèi)部EEPROM驅(qū)動(dòng)、內(nèi)部Flash驅(qū)動(dòng)、RAM測(cè)試等內(nèi)容。1.2.3.1 EEPROM驅(qū)動(dòng)EEPROM驅(qū)動(dòng)提供讀、寫、擦除EEPROM的服務(wù)。也提供了用于比較EEPROM中數(shù)據(jù)塊和內(nèi)存中數(shù)據(jù)塊的服務(wù)。這些服務(wù)是異步的。有兩類EEPROM驅(qū)動(dòng)：內(nèi)部EEPROM驅(qū)動(dòng)外部EEPROM驅(qū)動(dòng)內(nèi)部EEPROM驅(qū)動(dòng)直接訪問(wèn)微控制器硬件，并且定位在微控制器抽象層。外部EEPROM驅(qū)動(dòng)使用處理程序（handler）

23、或驅(qū)動(dòng)訪問(wèn)外部EEPROM設(shè)備。它定位在ECU抽象層。兩種類型的驅(qū)動(dòng)的功能需求和功能范圍都是相同的。所以API在語(yǔ)義上是相同的。1.2.3.2 flash驅(qū)動(dòng)如果受到底層硬件的支持，閃存驅(qū)動(dòng)提供讀、寫和擦除閃存的服務(wù)，以及設(shè)置寫/擦除保護(hù)的配置接口。閃存驅(qū)動(dòng)提供了一個(gè)內(nèi)置加載器，以加載閃存存取代碼到RAM中，并在需要的時(shí)候執(zhí)行寫/擦除操作。在ECU應(yīng)用模式下，閃存驅(qū)動(dòng)只用于閃存EEPROM仿真模塊寫數(shù)據(jù)。在應(yīng)用模式下并不將程序代碼寫到閃存中。這應(yīng)該由啟動(dòng)模式處理，超出了AUTOSAR的范圍。有兩類閃存驅(qū)動(dòng)：內(nèi)部閃存驅(qū)動(dòng)外部閃存驅(qū)動(dòng)內(nèi)部閃存的驅(qū)動(dòng)直接存取微控制器硬件，并且定位在微控制器抽象層。外

24、部閃存通常通過(guò)微控制器數(shù)據(jù)/地址總線連接，然后閃存驅(qū)動(dòng)使用總線的處理程序/驅(qū)動(dòng)訪問(wèn)外部閃存設(shè)備。外部閃存設(shè)備的驅(qū)動(dòng)定位在ECU抽象層。兩種類型的驅(qū)動(dòng)的功能需求和功能范圍都是相同的。所以API在語(yǔ)義上是相同的。1.2.3.3 RAM測(cè)試RAM測(cè)試：負(fù)責(zé)RAM單元（包括用于寄存器的單元）的物理性診斷（非數(shù)據(jù)檢測(cè)），不同的診斷方式需要預(yù)編譯然后更據(jù)系統(tǒng)或用戶需要實(shí)時(shí)運(yùn)行。1.2.4 微控制器驅(qū)動(dòng)微控制器驅(qū)動(dòng)層主要包括看門狗驅(qū)動(dòng)、通用定時(shí)器GPT驅(qū)動(dòng)、微控制器單元MCU驅(qū)動(dòng)等內(nèi)容。1.2.4.1 看門狗驅(qū)動(dòng)看門狗驅(qū)動(dòng)：設(shè)定片內(nèi)看門狗模式以及觸發(fā)看門狗設(shè)備，觸發(fā)程序由上層系統(tǒng)服務(wù)層的看門狗管理器模塊進(jìn)行

25、調(diào)用。內(nèi)部看門狗驅(qū)動(dòng)控制MCU的內(nèi)部看門狗計(jì)時(shí)器。它提供觸發(fā)器功能和模式選擇服務(wù)。1.2.4.2 通用定時(shí)器GPT驅(qū)動(dòng)通用定時(shí)器GPT驅(qū)動(dòng)：為定時(shí)服務(wù)程序提供定時(shí)中斷。GPT驅(qū)動(dòng)允許產(chǎn)生單觸發(fā)或持續(xù)的計(jì)時(shí)器通知。這個(gè)模塊使用通用計(jì)時(shí)器的硬件計(jì)時(shí)通道，因此就為操作系統(tǒng)中或者其它基本軟件模塊（在這類模塊中，OS警告服務(wù)有過(guò)多的開銷）中的使用提供了精確的、短期的計(jì)時(shí)。GPT驅(qū)動(dòng)提供了用于啟動(dòng)和停止硬件計(jì)時(shí)模塊中的功能計(jì)時(shí)實(shí)例（通道）的服務(wù)。它能夠產(chǎn)生單個(gè)超時(shí)周期以及重復(fù)超時(shí)周期。如果必須調(diào)用一個(gè)通知，那么當(dāng)所請(qǐng)求的超時(shí)周期過(guò)期時(shí)，用戶就能夠?qū)λM(jìn)行配置。可以在運(yùn)行時(shí)啟用或禁用通知。不管是從上一個(gè)通知

26、發(fā)生以來(lái)的相對(duì)時(shí)間消耗，還是到下一個(gè)通知之間的剩余時(shí)間，都可以進(jìn)行查詢。圖8 GPT時(shí)序注意，GPT驅(qū)動(dòng)僅產(chǎn)生時(shí)間基礎(chǔ)，而不服務(wù)于時(shí)間計(jì)數(shù)器。這個(gè)功能是由另一個(gè)模塊（ICU驅(qū)動(dòng)）提供的。GPT驅(qū)動(dòng)可以用來(lái)喚醒ECU，不管預(yù)定義的超時(shí)周期是否過(guò)期。模式轉(zhuǎn)換服務(wù)將GPT驅(qū)動(dòng)在普通操作和睡眠模式之間進(jìn)行轉(zhuǎn)換。該驅(qū)動(dòng)不提供超時(shí)周期，這些超時(shí)周期超過(guò)了被時(shí)鐘源、預(yù)定標(biāo)器和計(jì)時(shí)寄存器所限制的最大值。用戶必須對(duì)這個(gè)進(jìn)行處理。1.2.4.3 微控制器單元MCU驅(qū)動(dòng)微控制器單元MCU驅(qū)動(dòng)負(fù)責(zé)微處理器的各項(xiàng)設(shè)定，包括復(fù)位，初始化，電源管理，喚醒，時(shí)鐘設(shè)定等。MCU驅(qū)動(dòng)提供用于基本微控制器的初始化，下電，復(fù)位和其它

27、MCAL軟件模塊需要的微控制器特定功能的服務(wù)。初始化服務(wù)提供了靈活性，同時(shí)，除了啟動(dòng)代碼之外，還提供了應(yīng)用程序相關(guān)的MCU初始化。啟動(dòng)代碼是完全特定于MCU的。MCU驅(qū)動(dòng)直接訪問(wèn)微控制器硬件，它位于微控制器抽象層（MCAL）中。MCU驅(qū)動(dòng)的特征：初始化MCU時(shí)鐘，PLL，時(shí)鐘預(yù)定標(biāo)器和MCU時(shí)鐘分布初始化RAM部件激活微控制器節(jié)電模式激活微控制器復(fù)位另外，還有提供一個(gè)服務(wù)來(lái)從硬件處獲得復(fù)位的原因。MCU驅(qū)動(dòng)微時(shí)鐘和RAM初始化提供MCU服務(wù)。在MCU配置集中，特定于MCU的時(shí)鐘（例如，PLL設(shè)置）和RAM（例如，段基地址和大?。┰O(shè)置必須被配置。注意：外部設(shè)備驅(qū)動(dòng)是屬于ECU抽象層而非微控制器抽

28、象層的，但內(nèi)存映射型外部設(shè)備(如外部flash存儲(chǔ)器)的驅(qū)動(dòng)是個(gè)例外，因?yàn)榭梢灾苯油ㄟ^(guò)微控制器訪問(wèn)它們。這些外部設(shè)備的驅(qū)動(dòng)位于微控制器抽象層。1.3 復(fù)雜驅(qū)動(dòng)圖9 復(fù)雜驅(qū)動(dòng)層示意圖復(fù)合驅(qū)動(dòng)（如圖3-2所示）使用對(duì)微控制器的直接訪問(wèn)來(lái)實(shí)現(xiàn)復(fù)合的傳感器評(píng)估和致動(dòng)器控制，它所訪問(wèn)的微控制器使用指定的中斷和/或復(fù)合的微控制器外設(shè)（如PCP，TPU），例如：注入控制（injection control）整流管控制（Electric valve control）增量位置檢測(cè)（Incremental position detection）例子：圖10 復(fù)雜驅(qū)動(dòng)內(nèi)容任務(wù)：滿足處理復(fù)合傳感器和致動(dòng)器的特殊功能和

29、時(shí)間需求。復(fù)雜驅(qū)動(dòng)在實(shí)現(xiàn)上高度依賴于C、ECU和應(yīng)用。1.4 ECU抽象層1.4.1 通信硬件抽象圖11 通信硬件抽象層次圖通信硬件抽象是從通信控制器的位置和ECU硬件布局中抽象出來(lái)的一組模塊。對(duì)所有的通信系統(tǒng)來(lái)說(shuō)，都需要特定的通信硬件抽象（如：LIN，CAN，MOST，F(xiàn)lexRay）。它提供平等的機(jī)制來(lái)訪問(wèn)總線通道（如：LIN、CAN、SPI、FlexRay），而不管這些總線通道的位置（在片上或在板上）。例子：一個(gè)ECU有一個(gè)帶有兩個(gè)內(nèi)部CAN通道的微控制器，以及一個(gè)帶有四個(gè)CAN控制器的板載ASIC。CAN-ASIC通過(guò)SPI與微控制器連接。通信驅(qū)動(dòng)通過(guò)總線特殊接口來(lái)訪問(wèn)（如CAN接口）

30、。通信硬件抽象在實(shí)現(xiàn)上與微控制器無(wú)關(guān)，而依賴于ECU硬件和外部設(shè)備。其上層接口依賴于總線，而與微控制器和ECU硬件無(wú)關(guān)。通信抽象層主要是LIN接口、CAN接口和CAN收發(fā)驅(qū)動(dòng)、FlexRay接口和FlexRay收發(fā)驅(qū)動(dòng)構(gòu)成。圖12 通信硬件抽象層和通信驅(qū)動(dòng)層1.4.1.1 LIN接口LIN接口(包括LIN TP)：為上層LIN SM模塊和PDU Router模塊提供驅(qū)動(dòng)抽象接口，通過(guò)下層驅(qū)動(dòng)模塊對(duì)LIN硬件設(shè)備進(jìn)行控制。功能主要包括：根據(jù)上層通信模塊切換調(diào)度表，執(zhí)行LIN數(shù)據(jù)幀的收發(fā)，控制設(shè)備的喚醒和睡眠，錯(cuò)誤處理以及診斷服務(wù)。其向下層的軟件架構(gòu)如下圖所示。圖13 LIN Interface架

31、構(gòu)LIN接口被設(shè)計(jì)成硬件無(wú)關(guān)的。到上層模塊（PDU路由器）和下層模塊（LIN驅(qū)動(dòng)）的接口被很好地定義。LIN接口可以處理一個(gè)以上的LIN驅(qū)動(dòng)。一個(gè)LIN驅(qū)動(dòng)能夠支持一個(gè)以上的通道。這指的是LIN驅(qū)動(dòng)能夠處理一個(gè)或多個(gè)LIN通道。LIN接口負(fù)責(zé)向上層提供LIN 2.0主要功能有：（1）為每個(gè)與ECU連接的LIN總線執(zhí)行當(dāng)前選擇的調(diào)度。（2）當(dāng)上層請(qǐng)求到來(lái)時(shí)，切換調(diào)度表。（3）從上層接收幀的傳送，并傳送數(shù)據(jù)部分作為適當(dāng)LIN幀中的響應(yīng)。（4）當(dāng)相應(yīng)的響應(yīng)在適當(dāng)?shù)膸薪邮諘r(shí)，為上層提供幀接收通知。（5）睡眠和喚醒服務(wù)（6）錯(cuò)誤處理（7）診斷傳輸層服務(wù)1.4.1.2 CAN接口CAN接口：為上層CAN

32、 SM模塊，CAN NM模塊，CAN TP模塊以及PDU Router模塊和下層CAN控制驅(qū)動(dòng)和CAN收發(fā)驅(qū)動(dòng)提供接口。提供了唯一的接口來(lái)訪問(wèn)管理CAN硬件設(shè)備，為上層服務(wù)層抽象了CAN硬件設(shè)備的分布和數(shù)量。其與下層軟件結(jié)構(gòu)關(guān)系如下圖：圖14 CAN Interface下層軟件結(jié)構(gòu)CAN接口提供標(biāo)準(zhǔn)化的接口，通過(guò)ECU的CAN總線系統(tǒng)來(lái)支持通信。其API與專用CAN控制器及其通過(guò)CAN驅(qū)動(dòng)層的訪問(wèn)無(wú)關(guān)。CAN接口能夠通過(guò)統(tǒng)一的接口訪問(wèn)一個(gè)或多個(gè)CAN驅(qū)動(dòng)。CAN接口僅能用于CAN通信，并且是為操作一個(gè)或多個(gè)底層CAN驅(qū)動(dòng)而專門設(shè)計(jì)。涵蓋不同CAN硬件單元的幾個(gè)CAN驅(qū)動(dòng)模塊由一個(gè)在CAN驅(qū)動(dòng)規(guī)

33、范中指定的通用接口來(lái)表示。CAN之外（也就是LIN）的其他協(xié)議不支持。1.4.1.3 CAN收發(fā)器驅(qū)動(dòng)CAN收發(fā)器驅(qū)動(dòng)負(fù)責(zé)對(duì)CAN收發(fā)器硬件進(jìn)行控制驅(qū)動(dòng)，為上層CAN接口模塊提供CAN收發(fā)器硬件抽象接口。CAN收發(fā)器驅(qū)動(dòng)負(fù)責(zé)處理ECU上的CAN收發(fā)器，依據(jù)的是與整個(gè)ECU當(dāng)前狀態(tài)相關(guān)的總線專用NM的狀態(tài)。CAN收發(fā)設(shè)備驅(qū)動(dòng)的目標(biāo)：CAN收發(fā)設(shè)備驅(qū)動(dòng)抽象使用CAN收發(fā)設(shè)備硬件芯片。它向更高層提供硬件無(wú)關(guān)接口。它也可以通過(guò)MCAL層的API從ECU設(shè)計(jì)中抽象出來(lái)，訪問(wèn)CAN收發(fā)設(shè)備硬件。 CAN收發(fā)設(shè)備硬件必須提供功能和接口，以映射到AUTOSAR CAN收發(fā)設(shè)備驅(qū)動(dòng)的運(yùn)行模式模型上。下層驅(qū)動(dòng)（S

34、PI和DIO）使用的API必須同步。不支持同步行為的下層驅(qū)動(dòng)的實(shí)現(xiàn)不能與CAN收發(fā)設(shè)備驅(qū)動(dòng)一起使用。1.4.1.4 外部CAN驅(qū)動(dòng)外部CAN驅(qū)動(dòng)（AUTOAR范圍之外）：為上層的CAN接口模塊提供外部CAN硬件抽象接口。1.4.1.5 FlexRay接口FlexRay接口為上層FlexRay SM模塊，F(xiàn)lexRay NM模塊，F(xiàn)lexRay TP模塊以及PDU Router模塊提供驅(qū)動(dòng)抽象接口，通過(guò)下層驅(qū)動(dòng)模塊對(duì)FlexRay硬件設(shè)備進(jìn)行控制。提供的功能包括：初始化，收發(fā)數(shù)據(jù)，設(shè)定FlexRay運(yùn)行模式，狀態(tài)信息捕獲以及各種定時(shí)。FlexRay接口提供一種標(biāo)準(zhǔn)化的接口以訪問(wèn)FlexRay通信

35、系統(tǒng)/硬件。FlexRay接口必須與所使用的專用FlexRay CC及其通過(guò)FlexRay驅(qū)動(dòng)的訪問(wèn)無(wú)關(guān)。FlexRay接口提供通過(guò)統(tǒng)一接口的對(duì)一個(gè)或幾個(gè)FlexRay驅(qū)動(dòng)的訪問(wèn)。FlexRay接口的主要任務(wù)有：（1）為上層提供到FlexRay通信系統(tǒng)的抽象接口。（2）FlexRay接口通過(guò)一個(gè)或多個(gè)硬件專用驅(qū)動(dòng)模塊來(lái)訪問(wèn)FlexRay硬件，而不是直接訪問(wèn)。（3）為了訪問(wèn)FlexRay通信控制器，F(xiàn)lexRay接口使用一個(gè)或多個(gè)FlexRay驅(qū)動(dòng)模塊。（4）為了訪問(wèn)FlexRay收發(fā)器，F(xiàn)lexRay接口使用一個(gè)或多個(gè)FlexRay收發(fā)器驅(qū)動(dòng)模塊。（5）FlexRay接口可執(zhí)行代碼與FlexR

36、ay通信控制器和FlexRay收發(fā)器完全不相關(guān)。（6）FlexRay接口允許代碼模塊的對(duì)象代碼提交，遵循“one-fits-all”原則。（7）FlexRay接口提供給上層AUTOSAR BSW模塊的功能如下：A初始化B配置/重配置C數(shù)據(jù)傳送（發(fā)送和接收）D啟動(dòng)/停止/中斷通信EFlexRay專用服務(wù)F設(shè)置運(yùn)行模式G獲取狀態(tài)信息H各種計(jì)時(shí)器功能1.4.1.6 FlexRay收發(fā)器驅(qū)動(dòng)FlexRay收發(fā)器驅(qū)動(dòng)負(fù)責(zé)對(duì)FlexRay收發(fā)器硬件進(jìn)行控制驅(qū)動(dòng)，為上層FlexRay 接口模塊提供FlexRay收發(fā)器硬件抽象接口。FlexRay收發(fā)器驅(qū)動(dòng)負(fù)責(zé)處理ECU上的FlexRay收發(fā)器，其依據(jù)是總線專

37、用NM的狀態(tài)。1.4.1.7 外部FlexRay驅(qū)動(dòng)外部FlexRay驅(qū)動(dòng)（AUTOSAR范圍之外）：為上層的FlexRay接口模塊提供外部FlexRay硬件抽象接口。1.4.2 I/O硬件抽象圖15 I/O硬件抽象層次圖I/O抽象層提供微控制器外設(shè)的硬件輸入輸出抽象接口，通過(guò)下層驅(qū)動(dòng)模塊對(duì)相應(yīng)硬件外設(shè)進(jìn)行控制，包括，微控制器通用I/O，ADC，PWM，ICU等。上層的汽車電子應(yīng)用和組件可以通過(guò)該模塊提供的I/O信號(hào)訪問(wèn)接口實(shí)現(xiàn)不同I/O設(shè)備的訪問(wèn)。圖16 I/O硬件抽象層和I/O驅(qū)動(dòng)層這主要通過(guò)把ECU信號(hào)映射到IO抽象端口上來(lái)實(shí)現(xiàn)。模塊IO硬件抽象要提供用于初始化整個(gè)IO硬件抽象的模塊。下

38、圖顯示了IO硬件抽象模塊。它位于MCAL驅(qū)動(dòng)之上。就是說(shuō)IO硬件抽象模塊要調(diào)用驅(qū)動(dòng)API來(lái)管理片上設(shè)備。MCAL驅(qū)動(dòng)的配置依賴于將由IO硬件抽象模塊提供的ECU信號(hào)的質(zhì)量。例如，當(dāng)引腳層發(fā)生相關(guān)的改變時(shí)（上升沿、下降沿），需要進(jìn)行通知。系統(tǒng)設(shè)計(jì)者不得不配置MCAL驅(qū)動(dòng)，以允許對(duì)給定信號(hào)進(jìn)行通知。通知來(lái)自于驅(qū)動(dòng)，并在IO硬件抽象模塊中進(jìn)行處理。圖171.4.3 存儲(chǔ)硬件抽象圖18 存儲(chǔ)硬件抽象層次圖存儲(chǔ)硬件抽象是從外圍存儲(chǔ)設(shè)備位置（片上或板上）和ECU硬件布局中抽象出來(lái)的一組模塊。存儲(chǔ)硬件抽象的任務(wù)是提供相等的機(jī)制訪問(wèn)內(nèi)部（片上的）和外部（板上的）的存儲(chǔ)設(shè)備以及各種存儲(chǔ)硬件（EEPROM，F(xiàn)la

39、sh）。例如：可以通過(guò)相等的機(jī)制訪問(wèn)片上EEPROM和外部EEPROM設(shè)備。通過(guò)仿真一個(gè)EEPROM接口和Flash硬件單元，可以經(jīng)過(guò)存儲(chǔ)器抽象接口訪問(wèn)兩種類型的硬件。圖19 存儲(chǔ)器硬件抽象層和存儲(chǔ)器驅(qū)動(dòng)層存儲(chǔ)器硬件抽象層主要是內(nèi)存抽象接口、EEPROM抽象、Flash EEPROM仿真。1.4.3.1 EEPROM抽象EEPROM抽象層（EA）擴(kuò)展EEPROM驅(qū)動(dòng)，提供片內(nèi)EEPROM的訪問(wèn)接口，抽象了EEPROM的地址以及數(shù)量，向上層提供線性地址空間上的虛擬分段和“實(shí)際上無(wú)限制的”擦除/寫循環(huán)。除此之外，它還應(yīng)該提供與EEPROM驅(qū)動(dòng)相同的功能。1.4.3.2 Flash EEPROM仿真

40、閃存EEPROM仿真（FEE）按照閃存技術(shù)仿真EEPROM抽象層的行為，利用Flash來(lái)仿真EEPROM的數(shù)據(jù)存儲(chǔ)，為上層的內(nèi)存抽象接口模塊提供數(shù)據(jù)的虛擬尋址。所以它與EEPROM抽象層有相同的功能和API，并且給出基于下層閃存驅(qū)動(dòng)和閃存設(shè)備的相似配置。1.4.3.3 內(nèi)存抽象接口內(nèi)存抽象接口（MemIf）對(duì)于不同內(nèi)存設(shè)備提供抽象內(nèi)存接口。上層的NVRAM管理器模塊可以通過(guò)抽象內(nèi)存接口來(lái)訪問(wèn)不同的抽象內(nèi)存模塊甚至是供應(yīng)商的特殊內(nèi)存驅(qū)動(dòng)（FEE或EA模塊），如下圖所示。內(nèi)存抽象接口抽象于下層FEE和EA模塊的數(shù)目，并向上層提供統(tǒng)一線性地址空間上的虛擬分段。圖20 內(nèi)存抽象接口與上下層的關(guān)系1.4

41、.3.4 外部EEPROM驅(qū)動(dòng)外部EEPROM 驅(qū)動(dòng)（AUTOSAR范圍之外）：屬于ECU抽象層，提供了對(duì)片外EEPROM設(shè)備的擦除，讀，寫訪問(wèn)的驅(qū)動(dòng)，以及與RAM數(shù)據(jù)的比較功能。1.4.3.5 外部flash驅(qū)動(dòng)外部Flash驅(qū)動(dòng)（AUTOSAR范圍之外）：屬于ECU抽象層，提供了對(duì)片外Flash設(shè)備的擦除，讀，寫訪問(wèn)的驅(qū)動(dòng)。1.4.4 板載設(shè)備抽象板上設(shè)備抽象模塊包括除傳感器/激勵(lì)器外的ECU板上設(shè)備（如板上系統(tǒng)芯片、外部watchdog等）的驅(qū)動(dòng)程序，它通過(guò)微控制器抽象層實(shí)現(xiàn)對(duì)ECU板上設(shè)備的訪問(wèn)。圖21 板載設(shè)備抽象層次圖板載設(shè)備抽象層和微控制器驅(qū)動(dòng)層與微控制器設(shè)備之間上下層關(guān)系：圖2

42、2板載設(shè)備抽象層主要是看門狗接口：針對(duì)微控制器的看門狗設(shè)備提供了相同的訪問(wèn)機(jī)制，抽象了看門狗設(shè)備的地址以及數(shù)量。1.4.4.2 外部看門狗驅(qū)動(dòng)外部看門狗驅(qū)動(dòng)控制外部硬件看門狗。它提供觸發(fā)器功能和模式選擇服務(wù)。它有和內(nèi)部看門狗驅(qū)動(dòng)一樣的功能作用域。如果在一個(gè)ECU內(nèi)使用了多于一個(gè)的看門狗設(shè)備和看門狗驅(qū)動(dòng)（例如，內(nèi)部軟件看門狗和外部硬件看門狗），該模塊就使得看門狗管理程序能夠選擇合適的看門狗驅(qū)動(dòng)，以及看門狗設(shè)備?？撮T狗驅(qū)動(dòng)接口提供了對(duì)下層看門狗驅(qū)動(dòng)的服務(wù)的統(tǒng)一訪問(wèn)，比如模式轉(zhuǎn)換和觸發(fā)。有設(shè)備索引選擇適當(dāng)?shù)目撮T狗設(shè)備。看門狗驅(qū)動(dòng)的服務(wù)的行為（同步/異步/計(jì)時(shí)）是受保護(hù)的?？撮T狗驅(qū)動(dòng)接口沒(méi)有給看門狗驅(qū)

43、動(dòng)增加額外的功能?？撮T狗驅(qū)動(dòng)接口也沒(méi)有從看門狗屬性中進(jìn)行抽象，比如toggle或窗口模式，超時(shí)周期等，就是說(shuō)，該驅(qū)動(dòng)接口沒(méi)有隱藏下層看門狗驅(qū)動(dòng)和看門狗設(shè)備的任何特性。1.6 抽象接口實(shí)現(xiàn)示例外部設(shè)備驅(qū)動(dòng)位于ECU抽象層上，它通過(guò)微控制器抽象層的驅(qū)動(dòng)訪問(wèn)外部設(shè)備。下面的例子說(shuō)明了如何通過(guò)SPIHandlerDriver訪問(wèn)外部EEPROM。圖23 NVRAM管理和看門狗管理與假設(shè)的硬件配置上的驅(qū)動(dòng)的相互影響這個(gè)實(shí)例展示了NVRAM管理器和看門狗管理器與假設(shè)的硬件配置上的驅(qū)動(dòng)的相互影響，如上圖所示。使ECU硬件擁有一個(gè)外部EEPROM（ST16RF42）和通過(guò)同樣的SPI與微控制器連接的外部看門狗

44、。SPIHandlerDriver控制對(duì)SPI硬件的并發(fā)訪問(wèn)，并且必須使看門狗訪問(wèn)的優(yōu)先級(jí)高于EEPROM訪問(wèn)。假設(shè)微控制器還有個(gè)能和外部EEPROM并行使用的內(nèi)部flash。EEPROM抽象和Flash EEPROM仿真有在語(yǔ)義上相同的API。內(nèi)存抽象接口通過(guò)下面的方法實(shí)現(xiàn)：在運(yùn)行期間基于設(shè)備索引（int/ext）的路由在運(yùn)行期間基于塊索引（如：0x01FF=外部EEPROM）的路由通過(guò)帶有NVRAM管理器中的函數(shù)指針（這種情況下內(nèi)存抽象接口只存在“虛擬的”）的ROM表在配置時(shí)間期間路由。結(jié)構(gòu)描述NVRAM管理器通過(guò)內(nèi)存抽象接口訪問(wèn)驅(qū)動(dòng)，如圖23所示。使用設(shè)備索引尋址不同的內(nèi)存設(shè)備。接口描述

45、內(nèi)存抽象接口應(yīng)該有下面的接口（如：為寫函數(shù)）：Std_ReturnType MemIf_Write(Uint8DeviceIndex,Uint16BlockNumber,Uint8*DataBufferPtr)EEPROM抽象以及Flash EEPROM仿真應(yīng)該有下面的接口（如：為寫函數(shù)）：Std_ReturnType Ea_Write(Uint16BlockNumber,Uint8*DataBufferPtr)圖24 NVRAM管理通過(guò)內(nèi)存抽象接口訪問(wèn)驅(qū)動(dòng)示意圖情形1:只使用一種類型的NV設(shè)備, 這是一般的使用情況。在這種情況下，內(nèi)存抽象被實(shí)現(xiàn)為一個(gè)忽略DeviceIndex參數(shù)的簡(jiǎn)單宏。下

46、面的例子只列出了寫函數(shù)：文件 MemIf.h:#include “Ea.h”/*for providing access to the EEPROM abstraction*/#define MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr) Ea_Write(BlockNumber, DataBufferPtr)File MemIf.c: 不存在結(jié)果：在運(yùn)行時(shí)沒(méi)有額外的代碼，NVRAM管理器虛擬地訪問(wèn)EEPROM抽象或直接的訪問(wèn)Flash仿真。情形2: 使用兩個(gè)或多個(gè)不同類型的NV設(shè)備，這種情況下使用DeviceIndex來(lái)選擇正確的NV

47、設(shè)備。可以使用指向函數(shù)的指針數(shù)組很有效的實(shí)現(xiàn)設(shè)備的選擇。下面的例子只列出了寫函數(shù)：文件MemIf.h:Extern const WriteFctPtrType WriteFctPtr2;#define MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr) WriteFctPtrDeviceIndex(BlockNumber, DataBufferPtr)File MemIf.c:#include “Ea.h”/*for getting the API function addresses*/#include “Fee.h”/* for get

48、ting the API function addresses */#include “MemIf.h”/*for getting the WriteFctPtrType*/Const WriteFctPtrType WriteFctPtr2 = Ea_Write, Fee_Write;結(jié)果：如果函數(shù)指針表在NVRAM管理器中，需要同樣的代碼和運(yùn)行時(shí)間。內(nèi)存抽象接口不會(huì)引起開銷。結(jié)論：能有效的實(shí)現(xiàn)抽象層抽象層是可升級(jí)的內(nèi)存抽象接口使NVRAM管理器能方便的訪問(wèn)一個(gè)或多個(gè)EEPROM和Flash設(shè)備完成了體系目標(biāo)和需求EEPROM抽象層中包含了一些可以很容易用宏來(lái)代替的功能，因此該層不可替代。1

49、.7 主要參考的AUTOSAR規(guī)范列表分類子類AUTOSAR規(guī)范名板載設(shè)備抽象層和微控制器驅(qū)動(dòng)層看門狗接口AUTOSAR_SWS_WatchdogInterface.pdf外部看門狗驅(qū)動(dòng)MCU/ECU硬件抽象AUTOSAR_SRS_SPAL_General.pdf微控制器單元MCU驅(qū)動(dòng)AUTOSAR_SWS_MCU_Driver.pdfAUTOSAR_SRS_MCU_Driver.pdf通用定時(shí)器GPT驅(qū)動(dòng)AUTOSAR_SWS_GPT_Driver.pdfAUTOSAR_SRS_GPT_Driver.pdf看門狗驅(qū)動(dòng)AUTOSAR_SWS_WatchdogDriver.pdfAUTOSAR_

50、SRS_Watchdog_Driver.pdf存儲(chǔ)器硬件抽象層和存儲(chǔ)器驅(qū)動(dòng)層存儲(chǔ)器抽象接口AUTOSAR_SWS_Mem_AbstractionInterface.pdfAUTOSAR_SRS_MemHw_AbstractionLayer.pdfEEPROM抽象AUTOSAR_SWS_EEPROM_Abstraction.pdfflash EEPROM仿真AUTOSAR_SWS_Flash_EEPROM_Emulation.pdf外部EEPROM驅(qū)動(dòng)外部flash驅(qū)動(dòng)內(nèi)部EEPROM驅(qū)動(dòng)AUTOSAR_SWS_EEPROM_Driver.pdfAUTOSAR_SRS_EEPROM_Driver

51、.pdf內(nèi)部flash驅(qū)動(dòng)AUTOSAR_SWS_FlashDriver.pdfAUTOSAR_SRS_Flash_Driver.pdfRAM測(cè)試AUTOSAR_SWS_RAM_Test.pdfAUTOSAR_SRS_RAM_Test.pdf通信硬件抽象層和通信驅(qū)動(dòng)層CAN接口AUTOSAR_SWS_CAN_Interface.pdfCAN收發(fā)器驅(qū)動(dòng)AUTOSAR_SWS_CAN_TransceiverDriver.pdf外部CAN驅(qū)動(dòng)FlexRay接口AUTOSAR_SWS_FlexRayInterface.pdfFlexRay收發(fā)器驅(qū)動(dòng)AUTOSAR_SWS_FlexRayTranscei

52、ver.pdf外部FlexRay驅(qū)動(dòng)LIN接口AUTOSAR_SWS_LIN_Interface.pdfCAN驅(qū)動(dòng)AUTOSAR_SWS_CAN_Driver.pdfSCI驅(qū)動(dòng)LIN驅(qū)動(dòng)AUTOSAR_SWS_LIN_Driver.pdfFlexRay驅(qū)動(dòng)AUTOSAR_SWS_FlexRayDriver.pdfSPI驅(qū)動(dòng)AUTOSAR_SWS_SPI_HandlerDriver.pdfAUTOSAR_SRS_SPI_HandlerDriver.pdfI/O硬件抽象層，I/O驅(qū)動(dòng)層I/O硬件抽象AUTOSAR_SRS_IOHW_Abstraction.pdfAUTOSAR_SWS_IO_HWA

53、bstraction.pdfPORT驅(qū)動(dòng)AUTOSAR_SWS_Port_Driver.pdfAUTOSAR_SRS_PORT_Driver.pdfDIO驅(qū)動(dòng)AUTOSAR_SWS_DIO_Driver.pdfAUTOSAR_SRS_DIO_Driver.pdfADC驅(qū)動(dòng)AUTOSAR_SWS_ADC_Driver.pdfAUTOSAR_SRS_ADC_Driver.pdfPWM驅(qū)動(dòng)AUTOSAR_SWS_PWM_Driver.pdfAUTOSAR_SRS_PWM_Driver.pdfICU驅(qū)動(dòng)AUTOSAR_SWS_ICU_Driver.pdfAUTOSAR_SRS_ICU_Driver.p

54、df2 主流汽車電子嵌入式微處理器及ECU硬件特性分析在本課題中將針對(duì)主流的、汽車廠商應(yīng)用的汽車電子微處理器或單片機(jī)進(jìn)行驅(qū)動(dòng)軟件和硬件抽象層軟件的開發(fā)，具體型號(hào)如下表所示。序號(hào)微處理器/單片機(jī)型號(hào)處理器核數(shù)據(jù)寬度（位數(shù)）芯片供應(yīng)商1MPC563X(MPC5633/MPC5634)e200z332freescale2MPC5554e200z632freescale3MPC555e200z632freescale49S12XHCS12X16freescale59S12DP512HCS1216freescale6HCS08HCS088freescale7STM08STM088ST下面列出上述各種微處理器/單片機(jī)的主要特性參數(shù)。2.1 MPC563X嵌入式微處理器特性2.1.1 MPC563X CPU Core特性CPU Core型號(hào)：e200z335體系架構(gòu)：PowerPC Book E指令流水線深度：4級(jí) 數(shù)據(jù)寬度： 32位I/O端口編址方式：內(nèi)存映射編址2.1.2 MPC563X片內(nèi)存儲(chǔ)結(jié)構(gòu)及片內(nèi)外設(shè)數(shù)據(jù)Ca