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.2.2. Preparing the my_uart_driver Device Driver

This section provides some background on how the my_uart_driver device driver is associated with a component instance. You must specify the name of the directory to store both the software device drivers and the custom components. The name should be descriptive enough to identify the custom component. The directory must be under the <my_design>/ip directory. The librarian searches for user component files named <component_name>_sw.tcl in directories below this ip directory.

Every HAL device driver has a software description file. The software description file naming convention is <component_name> _sw.tcl. This name must match the corresponding <component_name> _hw.tcl file generated by the Component Editor.

The my_uart_driver device driver’s software description file is <my_design> /ip/my_uart/my_uart_sw.tcl.

All components generated by the Component Editor have a <component_name> _hw.tcl file. However, certain components provided by Altera, such as the Altera_Avalon_UART, are generated outside the Component Editor, and therefore do not have a <component_name> _hw.tcl file.

For additional information about creating device driver Tcl scripts, refer to the “Driver and Software Package Tcl Script Creation” section of the Developing Device Drivers for the Hardware Abstraction Layer chapter in the Nios II Software Developer’s Handbook.

Altera provides an additional tool with the Nios II processor, the System Console, that is useful for testing component instances and software device drivers, and for constructing BSPs. This application note does not describe the System Console.

For information about the System Console, refer to the System Console User Guide.

Related Information
Level Two Title