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.6.2. Making Hardware Modifications

If you make hardware design modifications, you must regenerate your Nios II system in Qsys and recompile the Quartus II project in the Quartus II software. In the regeneration step, Qsys updates the SOPC Information File (.sopcinfo) for your hardware design.

If you have a pre-existing BSP, such as the example design, an updated .sopcinfo file requires that you regenerate your BSP in the BSP Editor (or by executing nios2-bsp on the command line). Then you must do a clean build of the BSP as well as the application that depends on it. The clean build is required because the software needs to obtain the new value of the _BASE symbol from system.h.

For additional information about updating BSP files after a hardware change, refer to Board Support Packages in the "Nios II Software Build Tools" chapter of the Nios II Software Developer's Handbook.

In the Nios II Command Shell, to force the SBT to copy or regenerate all BSP and application files, simply perform the following steps:

  1. Delete the application makefile, for example app/bit_bang_uart/Makefile.
  2. Delete the BSP’s public.mk file, for example bsp/hal_my_uart/public.mk.
  3. Execute the create-this-app script in the application directory, for example app/bit_bang_uart/create-this-app. The create-this-app script runs the create-this-bsp script, which in turn runs nios2-bsp.
Related Information
Level Two Title