深度剖析Nios II 处理器的硬件抽象层-电子发烧友网

硬件抽象层（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文件给出了每个外设的详细信息，包括以下几部分：

外设的硬件配置；

外设的基地址；

中断优先级（如果外设有中断）；

外设的符号名称；