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.5.1. Altera Logging Usage

You enable Altera logging with the hal.log_port BSP setting by setting the logging level with ALT_LOG_FLAGS. This setting causes the SBT to define ALT_LOG_ENABLE in public.mk.

You can add Altera logging diagnostic messages to your code by invoking ALT_LOG_PRINTF(), a macro that handles most printf() formatting options.

Writes to the Altera logging device are blocking. Therefore, when hal.log_port is set to a component instance of type altera_avalon_jtag_uart, you must run an application to accept the Altera logging output in order for the Nios II application to complete initialization. Otherwise, the application pends on an ALT_LOG_PRINTF() statement until the Altera logging device's output buffer can be drained.

You can handle the JTAG UART logging output in either of the following ways:

  • Run your application in the Nios II SBT for Eclipse. JTAG UART logging output appears in the Nios II Console view.
  • Run your application from the Nios II Command Shell, with the nios2-download command. From another Nios II Command Shell, run nios2-terminal to accept the JTAG UART logging output.

You can disable the Altera logging feature by setting the hal.log_port setting in the BSP to none. This is the default setting. In the example BSP, hal_my_uart, the create-this-bsp script initially sets hal.log_port to jtag_uart. You can enable and disable it in the BSP Editor. After regenerating a BSP, you can check the value of hal.log_port in summary.html, located in the bsp/hal_my_uart folder.

Disabling Altera logging has the effect of leaving ALT_LOG_ENABLE undefined in bsp/hal_my_uart/public.mk. When this feature is disabled, the application does not pend on ALT_LOG_PRINTF() statements, even when no terminal capable of receiving Altera logging output is connected.

You can leave your ALT_LOG_PRINTF() debugging statements in the final source code version intended for production release, provided you set hal.log_port to none. With this setting, the definition of ALT_LOG_PRINTF() is empty, and so the compiler effectively removes these macro invocations. They have no impact on code footprint or performance unless you re-enable Altera logging.

For complete information about using the Altera logging functions, refer to "Using Character-Mode Devices" section in the "Developing Programs Using the Hardware Abstraction Layer" chapter in the Nios II Software Developer's Handbook.

Related Information
Level Two Title