Specifications

• ALT_DRIVER_READ(instance, buffer, len, flags)
• ALT_DRIVER_WRITE(instance, buffer, len, flags)
• ALT_DRIVER_IOCTL(instance, req, arg)
These macros are defined in <Nios II EDS install path>/components/altera_hal/HAL/inc/sys/alt_driver.h.
These macros, together with the system-specific macros that the Nios II SBT creates in system.h, generate
calls to your driver functions. For example, with lightweight drivers turned on, printf() calls the HAL
write() function, which directly calls your driver’s <component class>_write() function, bypassing
file descriptors.
You can enable ALT_USE_DIRECT_DRIVERS in a BSP with the
hal.enable_lightweight_device_driver_api BSP setting.
For more information, refer to the "Nios II Software Build Tools Reference" chapter.
Related Information
Nios II Software Build Tools Reference on page 15-1
Invoking Macros in Your Application Software
You can also take advantage of the lightweight device driver API by invoking ALT_DRIVER_READ(),
ALT_DRIVER_WRITE() and ALT_DRIVER_IOCTL() in your application software. To use these macros,
include the header file sys/alt_driver.h. Replace the instance argument with the device instance name
macro from system.h; or if you are confident that the device instance name will never change, you can use
a literal string, for example custom_uart_0.
Calling Direct Without Macros
Another way to use your driver functions is to call them directly, without macros. If your driver includes
functions other than <component class>_read(), <component class>_write() and <component
class>_ioctl(), you must call those functions directly from your application.
HAL Namespace Allocation
To avoid conflicting names for symbols defined by devices in the hardware system, all global symbols
need a defined prefix. Global symbols include global variable and function names. For device drivers, the
prefix is the name of the component followed by an underscore. Because this naming can result in long
strings, an alternate short form is also permitted. This short form is based on the vendor name, for
example alt_ is the prefix for components published by Altera. It is expected that vendors test the
interoperability of all components they supply.
For example, for the altera_avalon_jtag_uart component, the following function names are valid:
• altera_avalon_jtag_uart_init()
• alt_jtag_uart_init()
The following names are invalid:
• avalon_jtag_uart_init()
• jtag_uart_init()
As source files are located using search paths, these namespace restrictions also apply to file names for
device driver source and header files.
NII5V2
2015.05.14
Invoking Macros in Your Application Software
7-31
Developing Device Drivers for the Hardware Abstraction Layer
Altera Corporation
Send Feedback