设。原和宿可以是存储器或其它设备，比如，以太网的连接。
Flash存储设备（Flash memory devices）——使用特殊的编程协议进行存储数据的非易失存储设备。
对应用程序开发人员的好处
HAL定义了一套用户用来初始化和访问每类设备的函数。不管设备硬件的底层实现如 何，API都是统一的。例如，要访问字符型的设备和文件子系统，用户可以使用C的标准库 函数，比如printf()和fopen()。对于应用程序的开发人员，不必去为这些种类的外设编写与硬件建立基本的通信的低层的程序。 对驱动程序开发人员的好处
每一个设备模型定义了一套必要的管理特定种类设备的驱动函数。 如果用户正在为一个新外设编写驱动程序，用户只需这套驱动函数。因此，驱动程序的开发任务是预先定义好了的和充分说明了的。另外，用户可以使用已有的 HAL函数和应用来访问设备，这样就节省了软件开发的工作量HAL调用驱动函数来访问硬件。
C标准库——newlib
HAL同ANSI C 标准库集成到一个运行环境。HAL使用的C标准库是针对嵌入式系统应 用的开源版本——newlib，所以能够和HAL和Nios II处理器很好地匹配。Newlib授权不需要 用户发布自己的源代码，也不需要为基于newlib的工程支付版税。 支持的外设
Altera提供很多外设在Nios II处理器的系统中使用， 大多数的Altera外设提供HAL设备驱 动程序，使得用户可以通过HAL API来访问硬件。下面的Altera外设提供完整的HAL支持：
?
字符型设备：
UART核。
JTAG UART核。
LCD 16207 显示控制器。
?
Flash 存储设备：
Flash芯片的通用flash接口。
Altera’s EPCS 串口配置设备控制器。
?
文件子系统：
基于Altera主机的文件系统。 Altera压缩只读文件子系统。
?
定时器设备：
定时器核。
?
DMA 设备：
DMA 控制器核。
Scatter-gather DMA 控制器核。
?
以太网设备：
三速Ethernet宏核。
LAN91C111 Ethernet MAC/PHY控制器。
LAN91C111和三速Ethernet元件需要μC/OS-II的支持， 第三方的厂商提供的外设此处没 有列出。所有的外设(来自Altera和第三方厂商) 必须提供一个头文件，头文件中定义了外设 的底层硬件接口。由此看来，所有的外设都在一定程度上支持HAL。然而，有些外设可能不提供设备驱动程序。如果没有驱动程序可用，用户只有利用头文件中的 定义来访问硬件，不要使用二进制的地址来访问外设。不可避免地，一些外设具有特殊的硬件特性，不能使用通用的API。为此，HAL提供了UNIX类型的 ioctl( )函数，因为硬件特性和外设相关，ioctl( ) 函数的选项在每个外设的描述文档中说明。一些外设提供专门的访问或不是基于HAL通用设备模型的函数来访问外设。例如，Altera在Nios II处理器系统中提供通用I/O (PIO)核。 PIO外设不属于HAL提供的设备模型中的任何一种，所以只提供了一个头文件和一些专门的访问或函数。想了解对某一个外设的软件支持，参考外设的描述文 档。要获得更详细的信息，参阅Quartus? II Handbook, Volume 5: Embedded Peripheral。 第5节 使用 HAL开发应用程序
本章讨论基于Altera的硬件抽象层系统库开发程序的方法。HAL的API对于第一次接触 Nios II处理器的软件开发人员是很容易理解的。基于HAL的程序，使用ANSI C标准库函数 和运行环境，并且使用HAL API的通用设备模型来访问硬件。HAL API的规范遵照ANSI C 标准库的函数，尽管ANSI C标准库和HAL系统库是相互独立的。ANSI标准库和HAL的紧密集成使得用户开发程序时， 可以不用直接调用HAL系统库的函数。 例如， 可以使用ANSI C 标准库的I/O函数，如printf( )和scanf()来控制字符型的设备。
6.5.1 Nios II IDE 工程结构
基于HAL系统库的软件工程的创建和管理是与Nios III DE紧密联系的。这部分讨论Nios II IDE工程来理解HAL。图6-23为Nios II IDE工程结构，说明了HAL系统库的位置，箭头表示了各个工程之间的依赖关系。
基于HAL的Nios II程序包含两个Nios II IDE工程，用户程序是在用户应用工程中，用户 程序是依赖于独立的系统库工程（HAL system library project）的。 应用工程所有的用户开发的代码，可执行文件最终由该工程编译生成。当用户创建应用
工程时，Nios II IDE创建HAL系统库工程。HAL系统库工程包含所有的用户程序与硬件的接 口的必要信息。生成可执行文件时，所有的和用户的SOPC Builder系统相关的HAL驱动程序 都被加入到系统库工程。HAL设置作为系统库的属性的被保存。系统库工程依赖SOPC Builder系统，SOPC Builder系统由一个.ptf 文件定义，该文件由SOPC Builder生成。Nios II IDE管理HAL系统库并且更新驱动程序的配置以准确地反映系统 硬件的变化。如果SOPC Builder系统发生了改动(即.ptf 文件更新了)，Nios II IDE会在下次用户生成和运行应用程序时重新生成HAL系统库。
这种工程之间的依赖结构使得用户程序不用随着硬件改动而进行修改， 用户开发和调试代码时不用担心自己的程序是否和目标硬件相匹配。简而言之，基于HAL系统库的程序总是和目标硬件相同步的。
6.5.2 系统描述文件——system.h
system.h 文件是HAL系统库的基础，system.h文件提供了完整的Nios II系统硬件的软件 描述。它的作用是将硬件和软件设计连接起来。对应用程序开发者来说，不是system.h中所有的信息都是有用的，很少的情况必须要在用
户的C源程序中包 含system.h。虽然如此，system.h 能回答这个最基本的问题：系统中都有什么硬件？
system.h文件描述系统中的每个外设，并提供如下的细节： 外设的硬件配置。 外设的基地址。 中断请求优先级。 外设的符号名。
在软件工程第一次编译的时候，Nios II IDE为HAL系统库工程生成system.h。system.h 内容取决于硬件配置和用户设置的HAL系统库的属性。用户不要编辑system.h。
下面给出的是从system.h文件中截取出来的一部分代码， 是关于定时器的设备的预定义， 其它设备的定义与定时器类似。 #define SYS_CLK_TIMER_NAME \#define SYS_CLK_TIMER_TYPE \#define SYS_CLK_TIMER_BASE 0x00000820 #define SYS_CLK_TIMER_SPAN 32 #define SYS_CLK_TIMER_IRQ 1
#define SYS_CLK_TIMER_ALWAYS_RUN 0 #define SYS_CLK_TIMER_FIXED_PERIOD 0 #define SYS_CLK_TIMER_SNAPSHOT 1 #define SYS_CLK_TIMER_PERIOD 10
#define SYS_CLK_TIMER_PERIOD_UNITS \#define SYS_CLK_TIMER_RESET_OUTPUT 0
#define SYS_CLK_TIMER_TIMEOUT_PULSE_OUTPUT 0 #define SYS_CLK_TIMER_MULT 0.001 #define SYS_CLK_TIMER_FREQ 85000000
#define ALT_MODULE_CLASS_sys_clk_timer altera_avalon_timer
6.5.3 数据宽度和 HAL 类型定义 对于嵌入式处理器，如Nios II处理器，准确的数据的宽度和精度是非常重要的。由于 ANSI C数据类型没有明确地定义数据宽度，HAL使用了一套标准的类型定义，支持ANSI C类型，但是数据宽度取决于编译器的约定。头文件alt_types.h 定义了HAL类型， Table 6-3 是HAL的数据类型定义。表6-4给出了Altera采用的GNU编译器的ANSI C的数据类型。
6.5.4 UNIX 风格的接口 HAL API提供了许多UNIX-风格的函数， UNIX风格的函数使得Nios II的新手程序员不 会感到开发环境的陌生，并且可以很容易地将原有的代码移植到HAL的环境下运行。HAL主要使用这些函数给ANSI C标准库提供系统接口。例如，C标准库调用的执行设备访问的函 数都在stdio.h中进行了定义。下面的列表是可用的UNIX风格的函数的完全列表，其中使用最多的是和FILE I/O相关的函数： _exit( ) close( ) fstat( ) getpid( )
gettimeofday( ) ioctl( ) isatty( )