摘要 基于嵌入式操作系統硬件抽象層理論，設計一種用于嵌入式操作系統內核開發的通用硬件抽象層平臺。通用硬件抽象層能夠為嵌入式操作系統內核的設計開發屏蔽硬件平臺的特性，提供統一的硬件相關的服務接口，可以使嵌入式操作系統內核的設計開發不依賴于特定的硬件平臺，同時開發的嵌入式操作系統內核具有更強的可移植性。

關鍵詞 嵌入式操作系統 通用硬件抽象層（HAL） BSP V開發模式

引言

　　為了便于操作系統在不同硬件結構上進行移植，美國微軟公司首先提出了將底層與硬件相關的部分單獨設計成硬件抽象層美國微軟公司提出了將操作系統底層與硬件相關的部分單獨設計成硬件抽象層HAL（Hardware Abstraction Layer）的思想。硬件抽象層的引入大大推動了嵌入式操作系統的通用程度，為嵌入式操作系統的廣泛應用提供了可能。然而，目前BSP形式的硬件抽象層僅僅能夠解決有限的幾種操作系統在同樣有限的BSP所支持的硬件平臺上的移植，而對絕大多數需要根據不同嵌入式應用而專門定制的嵌入式操作系統來說能起的作用則非常有限。

1? 硬件抽象層原理

1.1? 硬件抽象層概念

　　嵌入式系統是一類特殊的計算機系統。它自底向上包括3個主要部分：硬件環境、嵌入式操作系統和嵌入式應用程序。硬件環境是整個嵌入式操作系統和應用程序運行的硬件平臺，不同的應用通常有不同的硬件環境；因此如何有效地使嵌入式操作應用于各種不同的應用環境，是嵌入式操作系統發展中所必須解決的關鍵問題。

　　硬件抽象層通過硬件抽象層接口向操作系統以及應用程序提供對硬件進行抽象后的服務。當操作系統或應用程序使用硬件抽象層API進行設計時，只要硬件抽象層API能夠在下層硬件平臺上實現，那么操作系統和應用程序的代碼就可以移植。

圖1? 引入HAL后的嵌入式系統結構

　　這樣，原先嵌入式系統的3層結構逐步演化為一種4層結構。圖1顯示了引入硬件抽象層后的嵌入式系統的結構。

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

圖2? 硬件抽象層引入后的V開發模式

1.2? BSP分析

　　作為硬件抽象層的一種實現，板級支持包BSP（Board Support Package）是現有的大多數商用嵌入式操作系統實現可移植性所采用的一種方案。BSP隔離了所支持的嵌入式操作系統與底層硬件平臺之間的相關性，使嵌入式操作系統能夠通用于BSP所支持的硬件平臺，從而實現嵌入式操作系統的可移植性和跨平臺性，以及嵌入式操作系統的通用性、復用性。

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

2? 通用硬件抽象層總體設計

2.1? 通用硬件抽象層的功能結構設計

　　通用硬件抽象層需要為上層操作系統內核提供統一的硬件相關功能服務；而嵌入式操作系統內核主要的硬件相關部分包括系統啟動初始化、任務上下文管理、中斷異常管理以及時鐘管理。因此，通用硬件抽象層對嵌入式操作系統內核所相關的硬件平臺的基本硬件組成部分進行抽象，提供嵌入式操作系統內核硬件平臺的相關功能，并設計相應的通用硬件抽象層API接口。通用硬件抽象層的總體功能結構如圖3所示。

圖3? 通用硬件抽象層總體功能結構示意圖

(1)? 系統啟動初始化

　　啟動初始化功能為操作系統的啟動和運行提供了必要的軟硬件環境。啟動和初始化過程中，對硬件平臺的直接訪問包括對CPU內核的寄存器的初始化設置，以及對于起系統控制作用的端口寄存器的設置。通過啟動初始化過程，為整個操作系統內核的運行提供了必要的運行環境與基礎，隔離了不同硬件平臺上嵌入式微處理器總線結構、存儲系統結構的差異。

(2)? 任務上下文管理

　　任務上下文管理負責嵌入式操作系統內核中任務管理部分中對任務寄存器上下文的創建、刪除以及切換等操作。任務的寄存器上下文是操作系統內核所管理的任務的重要組成部分，是CPU內核的寄存器中內容的映像，因此上下文管理的實現依賴于CPU內核中寄存器的組織，是與體系結構密切相關的。通用硬件抽象層的任務上下文管理統一定義體系結構中的寄存器上下文的保護格式，提供了任務管理對任務上下文的基本操作的API接口。

(3)? 中斷異常管理

　　中斷異常管理是嵌入式操作系統內核中的重要組成部分。中斷異常機制是操作系統內核實現與外部設備通信、任務系統調用、進行出錯處理以及能夠實現對任務的實時調度的重要手段。因此,硬件抽象層中斷系統的管理部分是整個硬件抽象層中的關鍵。

　　通用硬件抽象層中為中斷異常處理進行了必要的包裝，向嵌入式操作系統內核屏蔽底層的中斷異常處理；同時，由于中斷管理必須涉及對中斷控制器的操作。因此，通用硬件抽象層的設計中，將中斷控制器控制的外設請求抽象成為統一的IRQ設備，嵌入式操作系統通過操作抽象IRQ設備來管理外設的中斷服務程序以及進行對中斷控制器的操作，從而為操作系統內核屏蔽了中斷控制器的直接操作。

(4)? 定時管理

　　定時管理負責為操作系統內核中的時鐘滴答處理提供必要的定時機制，同時也為內核之外的系統功能提供定時服務，如TCP/IP協議棧等。操作系統內核通過時鐘滴答處理來執行重要的定時任務（如任務時間的分配、任務運行時間統計、任務定時等待更新等），因此定時功能是硬件抽象層需要為操作系統內核提供的最為基本和重要的功能之一。

　　通用硬件抽象層根據對硬件定時器的抽象為操作系統內核提供統一的抽象定時器設備，并且對定時中斷服務程序進行了包裝，從而使嵌入式操作系統內核直接面對的是統一、通用的抽象定時器設備，通過對抽象定時器的操作來實現定時服務，而不必直接操作硬件定時器。

2.2? 通用硬件抽象層的層次結構設計

　　通用硬件抽象層的設計是為在各種不同硬件平臺上的嵌入式操作系統內核的開發提供統一的硬件平臺相關的功能，因此這就要求硬件抽象層本身能夠易于擴展和移植到不同的硬件平臺之上，才能為這種硬件平臺上嵌入式操作系統內核的開發提供支持。與硬件平臺相關的軟件分為體系結構相關以及外圍端口寄存器操作相關部分。體系結構相關軟件部分能夠用于與CPU內核體系結構兼容的不同嵌入式微處理器上，而對外圍端口寄存器的操作，則每種嵌入式微處理器都不同。因此，通用硬件抽象層功能的實現設計成為圖4所示的3個層次的結構：通用層、體系結構層以及外圍層。通過這3個實現層次的劃分盡可能地實現代碼的可復用性。

圖4? 通用硬件抽象層層次結構示意圖

(1)? 通用層

　　通用層是以C語言編寫的、不涉及體系結構及外圍端口寄存器具體操作的、能夠通用于各種硬件平臺的一層。通用層內包括： 對統一的與編譯器無關的數據類型、抽象設備的數據結構定義，以及提供給嵌入式操作系統內核的對抽象設備的各種統一的操作服務的接口通用的實現部分。

　　通用層中抽象設備操作的實現中需要涉及的對CPU內核寄存器的操作以及對外圍I/O端口寄存器的操作，是通過調用體系結構層以及外圍層中統一定義的接口進行的。當擴展或移植到其他硬件平臺上時，上層無須修改，而只須進行下層替換。

(2)? 體系結構層

　　針對各種嵌入式微處理器CPU內核的體系結構，體系結構層需要分別設計實現。體系結構層中對體系結構相關的數據類型以及數據結構進行定義，包括寄存器上下文保存格式的定義以及對中斷異常向量起始地址、各種異常和中斷處理的入口偏移等，并負責通用硬件抽象層功能中體系結構相關部分的實現。實現的內容主要是對CPU內核中各個寄存器的訪問，對于中斷異常向量表的操作以及底層的中斷和異常處理。

　　體系結構層的實現是按照上層規定的調用接口來進行的，因而針對不同的體系結構，上層通用層無須進行修改。體系結構層中對有關I/O端口寄存器的操作通過對外圍層接口的調用來實現。

　　針對某種體系結構設計實現的體系結構層能夠通用于CPU內核體系結構兼容的嵌入式微處理器的硬件平臺上，從而易于硬件抽象層在體系結構兼容的嵌入式微處理器硬件平臺上的擴展和移植。

(3)? 外圍層

　　外圍層是針對各種嵌入式微處理器而分別設計實現的。外圍層主要包括對外圍I/O接口和設備屬性的定義（包括中斷控制器連接的外設個數、定時器個數等），并且負責對各個外圍I/O設備端口寄存器的訪問操作。外圍層的實現需要根據上層定義的接口進行。

　　通用硬件抽象層的外圍層必須提供對存儲控制、總線控制、中斷控制器、定時器控制器、UART等基本I/O接口和設備的I/O端口寄存器的訪問功能。外圍層是與各種嵌入式微處理器一一對應的，在采用不同的嵌入式微處理器的硬件平臺之間，外圍層是無法通用的。因此針對新的嵌入式微處理器的通用硬件抽象層的擴展或移植，外圍層都需要重新設計實現。

(4)? 層次間接口的設計

　　通用硬件抽象層除了為嵌入式操作系統內核提供統一的功能服務接口外，為了便于擴展和移植到其他硬件平臺，還在各層的調用之間設計了統一的調用接口。下層的功能實現需要按照與上層確定的接口規范來進行。其中某些上下層之間的接口，尤其是外圍層與上層之間的接口是使用宏定義的方式進行的。宏定義在預編譯時進行替換，沒有執行時的性能損失。相反，對于底層的操作直接使用宏定義能夠提高執行效率，尤其對外圍端口寄存器的操作，由于操作本身的執行時間短，而一般函數調用則需要返回地址、參數壓棧等過程。這些開銷可能超過這些I/O端口寄存器的訪問時間，使用宏定義則沒有調用開銷，從而能夠直接實現接口對底層端口寄存器的訪問而不損失操作的效率。