1.1.3. HAL Device Drivers and Components
This application note discusses Nios II device drivers and components at several levels. To understand these levels, you need to be familiar with the following concepts:
- HAL-compatible component—A design for a piece of hardware that can be incorporated into a Nios II system and supported by the HAL. A component is an abstract IP core that can be configured for a specific application. A component has abstract parameters, such as base address. These parameters have no specific value until a component instance is created. The Altera Avalon UART is an example of a component.
- Component instance—A component that is instantiated in a system. Component instance parameters have specific values, assigned at the time of instantiation. For example, an instance of the Altera Avalon UART must have a specific base address. There can be multiple instances of a component in a system. Each instance has a unique name, such as uart1, assigned in Qsys.
- HAL-device driver—A piece of software written to interface a component to the HAL. A device driver supports a specific component. A Nios II BSP contains a single device driver for each component found in the system. If there are multiple instances of one component, they are all supported by a single driver. In this application note, my_uart_driver is an example of a device driver.
- HAL-generic device model class—A group of device drivers with similar characteristics and a common high-level API. Generic device models allow you to use a consistent set of API calls with a variety of hardware designs. The class of character-mode devices is an example of a HAL device class, and the printf() function is an example of a function call supported by this device class.
For more information about HAL device classes, refer to “HAL Architecture” in the Overview of the Hardware Abstraction Layer chapter of the Nios II Software Developer's Handbook.
Did you find the information on this page useful?