硬件抽象層

硬件抽象層技術最初是由Microsoft公司為確保WindowsNT的穩定性和兼容性而提出的。針對過去Windows系列操作系統經常出現的系統死機或崩潰等現象，Microsoft總結髮現，程序設計直接與硬件通信，是造成系統不穩定的主要原因。在得出這個結論的基礎上，微軟公司在WindowsNT上取消了對硬件的直接訪問，首先提出了硬件抽象層(Hardware Abstraction Layer，簡稱HAL)的概念，硬件抽象層就是：“將硬件差別與操作系統其他層相隔離的一薄層軟件，它是通過採用使多種不同硬件在操作系統的其他部分看來是同一種虛擬機的做法來實現的。“後來，這種HAL設計思路被一些嵌入式操作系統參考，其系統內核被分成兩層，上層稱為“內核(Kernel)”，底層則稱為“硬件抽象層”。在EOS中，HAL獨立於EOS內核；對於操作系統和應用軟件而言，HAL是對底層架構的抽象。綜合分析HAL層的代碼，可以發現這些代碼與底層硬件設備是緊密相關的。因此，可以將硬件抽象層定義為所有依賴於底層硬件的軟件。即使有些EOS的HAL在物理上是與系統內核緊密聯繫的，甚至相互交叉的，但是從功能上可以從分層技術的角度去分析它 ^[1]  。

硬件抽象層是位於操作系統內核與硬件電路之間的接口層，其目的在於將硬件抽象化。它隱藏了特定平台的硬件接口細節,為操作系統提供虛擬硬件平台,使其具有硬件無關性,可在多種平台上進行移植。 從軟硬件測試的角度來看，軟硬件的測試工作都可分別基於硬件抽象層來完成，使得軟硬件測試工作的並行進行成為可能。

硬件抽象層是一個編程層，允許計算機操作系統在邏輯層而不是硬件層與硬件設備交互。Windows 2000就是支持硬件抽象層的操作系統之一。操作系統核心或者硬件驅動程序都可以調用硬件抽象層。無論哪種情況，調用程序都不用瞭解硬件的具體設計細節，只需要給出抽象層所需的參數即可。 ^[2] 

嵌入式操作系統的設計是一個涉及嵌入式軟件、硬件的方方面面的非常複雜的問題，解決這個問題可基於這樣一個基本原理：問題分解，各個擊破。設計易於移植的嵌入式平台，應遵循層次化、模塊化和對象化的設計方法 ^[1]  。

層次化設計對於嵌入式操作系統而言，體現在嵌入式操作系統的縱向結構上。為了適應多種硬件平台，將操作系統劃分出來一個可以直接和硬件通訊的層次，然後為其上層提供抽象支持，下層通過API的形式向上層提供服務。這樣上層在進行硬件操作時，不需要了解設備的具體細節，從而大大減少系統理解和開發的複雜度。所以，層次化的方法主要有以下優點：節省成本、易於理解、易於擴展、易於排錯。

模塊化最大特點就是將接口和實現分離開來，將具體的功能塊隱藏在抽象的接口背後，以保證每個模塊可以在不影響其他模塊的情況下進行改變。這樣，可將模塊之間的依賴關係僅僅限定於接口。模塊化方法與層次化方法不同，軟件模塊之間是相互獨立的關係，而不是層次之間相互依賴的關係。

就當前的目的來説，對象是結構化使用模塊的方法。面向對象設計方法將數據與數據上的操作封裝在對象這個模塊實體中，外界不能直接對對象內部進行訪問和操作，只能通過消息的方式間接訪問。因此，面向對象設計方法能夠使軟件開發人員更加容易理解，並且也提高了軟件的擴展性、維護性和重用性。

下面具體講述了這些功能實現的原理。

首先，為了更好地實現嵌入式系統中硬件相關和硬件無關兩部分程序代碼的隔離，使得硬件抽象層為上層軟件提供一個已屏蔽硬件差異的接口，可將HAL進一步細化為幾個子層次，即採用層次結構設計的思想。那麼，在層次結構設計中，各子層之間定義了統一的接口調用。這些接口採用C/C++語言進行編碼，即下層的功能實現需要按照與上層確定的接口規範來進行。而這些上下層之間的接口是使用宏定義的方式進行的。宏定義在預編譯時進行替換，沒有執行時的性能損失。在系統初始化階段，片級初始化、板級初始化和系統級初始化基本上就是使用了宏定義這一特點。

其次，為保證開發語言的移植性，引入面向對象的思想。C語言雖不能直接支持面向對象的數據結構，如數據類型的動態綁定、多態函數或類繼承。但在設計時可以借鑑面嚮對象語言的特點實現基於C語言的對象，卻又不依賴於它。這樣，就使系統開發難度大為降低。

那麼，與硬件相關的驅動程序是如何利用面向對象的思想進行設計的?在系統初始化階段結束以後，操作系統獲得了系統控制權。HAL層的主要工作就變為向操作系統提供服務：將上層的調用轉化為對硬件的直接訪問和控制，具體活動為建立與硬件相關的驅動程序。這裏的驅動程序指的是操作系統(通常被包含在I/O子系統裏)的一些標準I/O函數，比如任何一個設備都有的Create、Destroy、Open、Close、Write、Read和Ioctl等函數。在這個階段完成兩個工作：

1、映射驅動程序函數到HALAPI經過改造後的驅動程序不再直接和硬件打交道，而是通過HALAPI進行硬件資源的訪問和控制。圖1表示了硬件相關設備驅動程序的標準I/O函數與HALAPI集合的映射關係。

2、I/O驅動程序表、設備表與HALAPI的關聯如圖2，顯示了I/O子系統通常維護的I/O驅動程序表。從圖2中可看出，驅動程序表的第二行、第N元素是一個指向內部的驅動函數UARTlCreate()的指針。這個指針建立了通用的Creat函數和設備指定的Creat之間的連接。使用I/O子系統提供的工具函數，可以將任何HALAPI安裝到驅動程序表中或從表中刪除。

I/O子系統中的Create函數用來創建一個虛擬設備實例，每個虛擬實例都以唯一的名字插入到I/O子系統的設備表中。圖2中的設備表顯示了UART0與USB0兩個虛擬實例，設備表中的每一項包含通用信息以及特定的實例信息。設備項的通用部分包括實例的唯一名字和一個對HALAPI的引用。設備項特定的實例信息是由HALAPI為保持特定數據的每一個實例分配的一塊內存，HALAPI初始化並維護。此信息的內容依賴於HALAPI的實現，HALAPI是唯一可以訪問和中斷此數據的實體。

嵌入式系統是一類特殊的計算機系統。它自底向上包括3個主要部分:硬件環境、嵌入式操作系統和嵌入式應用程序。硬件環境是整個嵌入式操作系統和應用程序運行的硬件平台，不同的應用通常有不同的硬件環境;因此如何有效地使嵌入式操作應用於各種不同的應用環境，是嵌入式操作系統發展中所必須解決的關鍵問題。硬件抽象層通過硬件抽象層接口向操作系統以及應用程序提供對硬件進行抽象後的服務。當操作系統或應用程序使用硬件抽象層API進行設計時，只要硬件抽象層API能夠在下層硬件平台上實現，那麼操作系統和應用程序的代碼就可以移植。這樣，原先嵌入式系統的3層結構逐步演化為一種4層結構。圖3顯示了引入硬件抽象層後的嵌入式系統的結構 ^[3]  。

在整個嵌入式系統設計過程中，硬件抽象層同樣發揮着不可替代的作用。傳統的設計流程是採用瀑布式設計開發過程，首先是硬件平台的製作和調試，而後是在已經定型的硬件平台的基礎上再進行軟件設計。由於硬件和軟件的設計過程是串行的，因此需要很長的設計週期;而硬件抽象層能夠使軟件設計在硬件設計結束前開始進行，使整個嵌入式系統的設計過程成為軟硬件設計並行的V模式開發過程，如圖4所示。這樣兩者的設計過程大致是同時進行的或是併發的，縮短了整個設計週期。結構。在整個嵌入式系統設計過程中，硬件抽象層同樣發揮着不可替代的作用。傳統的設計流程是採用瀑布式設計開發過程，首先是硬件平台的製作和調試，而後是在已經定型的硬件平台的基礎上再進行軟件設計。由於硬件和軟件的設計過程是串行的，因此需要很長的設計週期;而硬件抽象層能夠使軟件設計在硬件設計結束前開始進行，使整個嵌入式系統的設計過程成為軟硬件設計並行的V模式開發過程，如圖4所示。這樣兩者的設計過程大致是同時進行的或是併發的，縮短了整個設計週期。

作為硬件抽象層的一種實現，板級支持包BSP(Board Support Package)是現有的大多數商用嵌入式操作系統實現可移植性所採用的一種方案。BSP隔離了所支持的嵌入式操作系統與底層硬件平台之間的相關性，使嵌入式操作系統能夠通用於BSP所支持的硬件平台，從而實現嵌入式操作系統的可移植性和跨平台性，以及嵌入式操作系統的通用性、複用性。然而現有應用較為廣泛的BSP形式的硬件抽象層，完全是為了現有通用或商業嵌入式操作系統在不同硬件平台間的移植而設計的，因此BSP形式的硬件抽象層與BSP所向上支持的嵌入式操作系統是緊密相關的。在同一種嵌入式微處理器的硬件平台上支持不同嵌入式操作系統的BSP之間不僅從組成結構、向操作系統內核所提供的功能以及所定義的服務的接口都完全不同，因而一種嵌入式操作系統的BSP不可能用於其他嵌入式操作系統。這種硬件抽象層是一種封閉的專用硬件抽象層。因此，我們提出了為上層嵌入式操作系統內核的開發和構建提供一種開放、通用的硬件抽象層平台，使得在某種硬件平台上的嵌入式操作系統內核的開發能夠在支持這種硬件平台的硬件抽象層上進行。

*硬件抽象層具有與硬件的密切相關性

*硬件抽象層具有與操作系統無關性

*接口定義的功能應包含硬件或系統所需硬件支持的所有功能

*接口定義簡單明瞭，太多接口函數會增加軟件模擬的複雜性

*具有可測性的接口設計有利於系統的軟硬件測試和集成

硬件抽象層對用户設備接口的功能模擬主要由虛擬驅動模塊完成,包括數據包的收發及協議報文的預處理等工作,為上層協議軟件提供標準的API函數, 而對用户設備的接口管理則由上層網絡管理軟件通地設備管理模塊對其進行管理配置及監控,內部通信模塊運行於內部隊以太網絡,協調各模塊之間的功能接口,保證從處理單元與主處理單元之間實時可靠的數據傳輸.