Specifications

altera_avalon_jtag_uart.h Defining Macros
For example, altera_avalon_jtag_uart.h must define the macros ALTERA_AVALON_JTAG_UART_INSTANCE and
ALTERA_AVALON_JTAG_UART_INIT. The purpose of these macros is as follows:
• The *_INSTANCE macro performs any required static memory allocation. For drivers, *_INSTANCE is
invoked once per device instance, so that memory can be initialized on a per-device basis. For software
packages, *_INSTANCE is invoked once.
• The *_INIT macro performs runtime initialization of the device driver or software package.
In the case of a device driver, both macros take two input arguments:
• The first argument, name, is the capitalized name of the device instance.
• The second argument, dev, is the lower case version of the device name. dev is the name given to the
component at system generation time.
You can use these input parameters to extract device-specific configuration information from the system.h
file.
The name of the header file must be as follows:
• Device driver: <hardware component class>.h. For example, if your driver targets the
altera_avalon_uart component, the file name is altera_avalon_uart.h.
• Software packages <package name>.h. For example, if you create the software package with the
following command:
create_sw_package my_sw_package
the header file is called my_sw_package.h.
For more information about a complete example, refer to any of the Altera-supplied device drivers,
such as the JTAG UART driver in <Altera installation>/ip/sopc_builder_ip/altera_avalon_jtag_uart.
Note:
For optimal project rebuild time, do not include the peripheral header in system.h. It is included in
alt_sys_init.c.
Device Driver Source Code
In addition to the header file, the component driver might need to provide compilable source code, to be
incorporated in the BSP. This source code is specific to the hardware component, and resides in one or
more C files (or assembly language files).
Reducing Code Footprint in HAL Embedded Drivers
The HAL provides several options for reducing the size, or footprint, of the BSP code. Some of these
options require explicit support from device drivers. If you need to minimize the size of your software,
consider using one or both of the following techniques in your custom device driver:
• Provide reduced footprint drivers. This technique usually reduces driver functionality.
• Support the lightweight device driver API. This technique reduces driver overhead. It need not reduce
functionality, but it might restrict your flexibility in using the driver.
These techniques are discussed in the following sections.
NII5V2
2015.05.14
altera_avalon_jtag_uart.h Defining Macros
7-29
Developing Device Drivers for the Hardware Abstraction Layer
Altera Corporation
Send Feedback