硬件抽象層（Hardware Abstraction Layer, HAL）是一個輕量級嵌入式運行時環境，它為用戶應用程序和底層硬件提供了一個簡單的設備驅動程序接口。HAL應用程序接口（API）與ANSI C標準庫綜合在一起，可使用類似C語言的庫函數來訪問硬件設備或文件，如printf()、fopen()、fwrite()等函數。軟件工程師可非常方便的使用這些函數來與底層硬件通信，而無須關心底層硬件實現細節。

HAL可以看作是一個支持應用程序開發的軟件平臺，它提供API函數接口，屏蔽硬件訪問細節，雖然占用了一些額外的資源，但是大大增加了應用程序的開發速度和可移植性。用戶只要利用HAL提供的各種函數就可以編寫應用程序。

HAL作為Nios II處理器系統的設備驅動程序包，為系統中的外圍設備提供了一致的接口。Nios II SBT從SOPC信息文件（.sopcinfo）中提取系統信息，生成一個針對于該硬件配置的定制的HAL板級支持包（BSP）。當硬件配置信息發生改變時，HAL設備驅動配置也會自動隨之更改，從而避免了由于底層硬件的變化而產生的編程錯誤。Nios II SBT為用戶自動創建和管理HAL設備驅動程序，用戶不用創建或拷貝HAL文件，也不用編輯HAL中的任何源代碼。

HAL為用戶提供以下支持：

集成了newlib ANSI C標準庫，允許調用類似C標準庫函數；

提供訪問Nios II系統中每個設備的驅動程序；

提供HAL API，用于標準的函數接口如設備訪問、中斷處理以及ALARM等；

提供系統初始化函數，為main()函數和C庫函數建立運行時環境；

提供設備初始化函數，在main()函數之前，分配設備空間并初始化所有的外圍設備；

Nios II HAL的結構如圖下所示。

Nios II HAL的結構

由上圖可以看出，用戶應用程序在硬件抽象層和C標準庫函數上，這說明用戶應用程序要訪問硬件設備至少有4中方法：

調用C標準庫函數，如printf()和fwrite()；

調用硬件抽象層的API函數，如write()；

調用設備驅動程序，如alt_avalon_uart_write()；

直接訪問設備寄存器，如IOWR_ALTERA_AVALON_UART_RXDATA(base, data)；

HAL I/O操作宏

前兩種方法的抽象度最高，可移植性最好，對用戶來說最容易實現，但是需要最多的額外開銷；第三種方法抽象度較低，有一定的移植性，額外開銷較少，但還需要用戶考慮對設備寫數據前的其他硬件操作；最后一種方法完全是對硬件的直接訪問，需要用戶關注設備的每個硬件細節，無額外開銷。

對于I/O外設，HAL提供了一些宏定義來訪問其中的寄存器，這些宏在/components/altera_nios2/HAL/inc/io.h中定義，以下是這些宏定義的詳細介紹。當用戶編寫應用程序時，只需要調用這些宏就可以訪問到I/O外設中的寄存器，而無需關心底層硬件的詳細信息。

另外，在HAL中還定義了常用的數據類型，這些定義在alt_type.h文件中，下面是alt_types.h文件內容的片段，從中我們可以看出，所有的數據類型都是以alt_開頭，若是無符號類型，那么數據類型中含有“u”表示unsigned的意思，最后會用數據的位數來結尾，如8、16、32、64。使用這些HAL數據類型可以很方便的看出變量的數據類型，比如，alt_u8 key_data 就表示key_data是一個8位的無符號數據。

使用HAL開發應用程序

基于HAL的軟件工程的創建和管理與Nios II SBT緊密相關，下圖為Nios II SBT工程結構。

Nios II SBT工程結構

從上圖可以看出，一個Nios II SBT工程包括2個工程：用戶應用程序工程和HAL BSP工程。用戶應用程序工程包含所有的用戶程序代碼文件，最終的可執行映像由此工程生成。HAL BSP工程中包含所有與硬件處理器系統相關的接口信息。

在第一次編譯Nios II SBT過程中，編譯工具會根據硬件系統信息生成一個描述硬件信息的system.h文件，如代碼1.1所示。該文件是HAL的基礎，它提供了關于Nios II系統硬件的描述，是硬件和軟件之間的橋梁。對應用程序開發來說，并不是system.h中的所有信息都有用，因此并不一定要在應用程序的C源代碼文件中包含system.h。

由代碼1.1可知，system.h文件給出了每個外設的詳細信息，包括以下幾部分：

外設的硬件配置；

外設的基地址；

中斷優先級（如果外設有中斷）；

外設的符號名稱；

代碼1.1 system.h文件示例