Visible to Intel only — GUID: iga1430780444820
Ixiasoft
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
Visible to Intel only — GUID: iga1430780444820
Ixiasoft
1.12.5. Debugging with the Altera Logging Functions
The Altera logging functions are a very useful mechanism for debugging device drivers. Altera logging uses macros to bypass the HAL driver and access the peripheral directly. As a result, software can print debugging messages during the boot process before the devices are initialized.
You do not need to regenerate the .sopcinfo file in Qsys or recompile the .sof image in the Quartus II software.
Another advantage of Altera logging is that you can disable it without modifying your source code. You simply change a BSP setting and recompile, leaving zero residual impact in the compiled and linked application .elf file. All the Altera logging mechanisms are macros, and so the compiler eliminates them when they are not enabled. As a result, you can leave these calls to obtain debugging information in the source code for your released final product, with no loss of speed or code memory space. Compiling with Altera logging disabled creates a .elf file identical to a .elf compiled from source code without the Altera logging macros.
When Altera logging is enabled, the behavior of the application might be less deterministic, due to the collection and output of Altera logging messages.