Guidelines for Developing a Nios II HAL Device Driver

Download PDF
ID 683146
Date 6/12/2015
Public
Document Table of Contents
Document Table of Contents x
1. Guidelines for Developing a Nios II HAL Device Driver
1. Guidelines for Developing a Nios II HAL Device Driver x
1.1. Prerequisites for HAL Device Driver Development 1.2. Developing the HAL UART Device Driver 1.3. Debugging the bit_bang_uart Project 1.4. The BitBangUartTransmit() Function 1.5. The BitBangUartReceive() Function 1.6. Creating Device Hardware Access Macros 1.7. Staging the HAL Device Driver Development 1.8. Understanding the Hardware-Specific INSTANCE and INIT Macros 1.9. Integrating a New HAL Device Driver in the BSP 1.10. Understanding HAL Mutual Exclusion Resources 1.11. Overview of Debugging Tools for HAL Device Drivers 1.12. Debugging the HAL UART Device Driver 1.13. Conclusion 1.14. Document Revision History
1.1. Prerequisites for HAL Device Driver Development x
1.1.1. Using the HAL Architecture and Services 1.1.2. Software Requirements for the Driver Example 1.1.3. HAL Device Drivers and Components
1.2. Developing the HAL UART Device Driver x
1.2.1. Preparing the bit_bang_uart Application and hal_my_uart BSP 1.2.2. Preparing the my_uart_driver Device Driver 1.2.3. Configuring the Altera_Avalon_UART Component 1.2.4. Importing Projects 1.2.5. Verifying Software Functionality 1.2.6. Preview: Customizing the Design
1.2.6. Preview: Customizing the Design x
1.2.6.1. Making Software Modifications 1.2.6.2. Making Hardware Modifications
1.12. Debugging the HAL UART Device Driver x
1.12.1. Setting Breakpoints in the my_uart_driver Device Driver 1.12.2. Setting Watchpoints in the HAL UART Device Driver 1.12.3. Reducing Driver Code and Memory Footprint 1.12.4. Interrupt Latency and Determinism 1.12.5. Debugging with the Altera Logging Functions
1.12.3. Reducing Driver Code and Memory Footprint x
1.12.3.1. Using the Reduced Device Drivers API Option 1.12.3.2. Using the Lightweight Device Drivers API Option
1.12.5. Debugging with the Altera Logging Functions x
1.12.5.1. Altera Logging Usage 1.12.5.2. Altera Logging Example
1. Guidelines for Developing a Nios II HAL Device Driver

1.12.3.2. Using the Lightweight Device Drivers API Option

The Lightweight device driver API option generates a #define statement for ALT_USE_DIRECT_DRIVERS. To turn on this option, set hal.enable_lightweight_device_driver_api to true. Setting this option has the following effects on correctly-written UART device drivers:

  • Sets #define ALT_USE_DIRECT_DRIVERS.
  • Eliminates the option of using a file system. File descriptors cannot be created.
  • Disables stdio device descriptor redirection. alt_main() cannot call alt_io_redirect().
  • Disables the open() and close() functions. Attempting to call these functions generates a link time error.
  • Causes direct calls to your UART device driver using macros, bypassing the device manipulation function invocations normally accessed through the file descriptor structure. The macros are defined in alt_driver.h, which is in the BSP folder, in HAL/inc/sys.

For example, a call to alt_putstr() is normally treated as a call to the run-time library function fputs(). With lightweight device drivers enabled, alt_putstr() is translated to ALT_DRIVER_WRITE() (defined in alt_driver.h) and state-obtaining macros. The ALT_DRIVER_WRITE() macro in turn calls the ALT_DRIVER_FUNC_NAME() macro (also defined in alt_driver.h), and eventually ALTERA_AVALON_UART_WRITE(), which is defined in the altera_avalon_uart_write.c driver file for the UART, where the UART is defined for stdout. Calling ALT_DRIVER_FUNC_NAME(uart1, write) returns ALTERA_AVALON_UART_WRITE.

ALT_USE_DIRECT_DRIVERS is dual-purposed in the my_uart_driver device driver. It provides a convenient way to map the names of the ALTERA_AVALON_UART_INIT() and ALTERA_AVALON_UART_INSTANCE() macros, which are tied to the component name, to names that are specific to the my_uart_driver device driver. This setting of ALT_USE_DIRECT_DRIVERS already maps ALTERA_AVALON_UART_INIT() and ALTERA_AVALON_UART_INSTANCE() to macros that change based on the setting of ALT_USE_DIRECT_DRIVERS in altera_avalon_uart.h. At the same time, the ALTERA_AVALON_UART_INIT() and ALTERA_AVALON_UART_INSTANCE() macros have the ALTERA_AVALON portion of their names change to MY_UART. The resulting four macro name mappings are MY_UART_DEV_INIT(), MY_UART_STATE_INIT(), MY_UART_DEV_INSTANCE(), and MY_UART_STATE_INSTANCE().

The figure below shows excerpts from the summary.html file generated by the SBT for a BSP with lightweight device drivers enabled.

Figure 23. hal.enable_lightweight_device_driver_api in summary.html
Note: For more information about the Lightweight device driver API option, refer to "Reducing Code Footprint" in the "Developing Programs Using the Hardware Abstraction Layer" chapter and to "Reducing Code Footprint" in the "Developing Device Drivers for the Hardware Abstraction Layer" chapter of the Nios II Software Developer's Handbook.
Related Information
Level Two Title