[Project Source Code] Reasons and methods for turning off the IP built-in driver in the NIOS development environment

小梅哥

[Project Source Code] Reasons and methods for turning off the IP built-in driver in the NIOS development environment [Copy link]

 

This article and design code were written by FPGA enthusiast Xiao Meige. Without the author's permission, this article is only allowed to be copied and reproduced on online forums, and the original author must be indicated when reprinting.

1. What is the IP driver in the NIOS development environment?
When developing applications based on NIOS II, IP cores such as SPI, timers, and UART serial ports are often used. As long as these IPs are added in Qsys, and then drivers and applications are written in the NIOS II development environment (customized version of Eclipse), the controller can be used. Of course, in order to make these IPs more convenient to use, Intel (Altera) also provides corresponding drivers for most IPs. For example, when using the serial port, we can directly use printf to send data through the serial port and scanf to receive data from the serial port. This is the use of the driver and HAL library developed by Intel. Similarly, for the timers provided in Qsys running in different modes, there are corresponding drivers. For example, watchdog mode, system heartbeat clock mode, etc.

2. Why do we need to turn it off?
For some reasons, we need to directly control the IP registers to achieve the corresponding functions, such as we think the built-in driver is too bloated and increases the size of the program, or we want to learn how to control it by reading and writing IP registers, or the built-in driver cannot meet our needs well. In short, we have reasons to want to turn it off when we need it.

3. What will happen if it is not closed?
Since the built-in drivers of these software will start to execute when NIOS II is initialized, if we operate these IPs by reading and writing direct registers in the user program, there will actually be two programs operating a register at the same time. When one program operates this register, the other program may not be able to operate the register, or the operation of the register may not be executed correctly. Here is a simple example:

For the serial port driver, the system's own driver uses interrupts to complete the sending and receiving of data, but when we write our own programs, we sometimes just want to simply read and write data by querying the register status. So suppose that when the serial port receives a byte of data:
a. First, since the system driver responds by interrupt, in theory, when the serial port receives data, the system driver's interrupt first responds to the event and enters the interrupt service function to read the status register, and then reads the received register according to the status register to know that new data has been received, and then reads the received register, reads out the received data and saves it.
b. However, don't forget that our user layer also has a receiving function, which may desperately read the serial port's status register, and then decide whether the data has been received based on the result of the status register. If the data is received, the data in the data register is read out and saved.
c. Users who are familiar with the serial port IP core should know that the bits in the serial port status register are automatically set and automatically cleared after reading. That is to say, if the serial port receives a piece of data, the corresponding bit in the status register will be set to 1. Then, when the user's own program or the system's built-in driver reads the value of the status register, some bits in the register will be automatically cleared.
Well, I believe that I don't need to say more, everyone knows where the problem lies. If the system's built-in driver responds to the fact that a byte of data has been received first through an interrupt and reads the status register, then when our own user-written driver reads the status register later, it will not read a valid value. In this way, the received data is lost. Alas, it is lost.

4. How to close?
The closing method is very simple. Select the bsp project with the left mouse button. Note that it is a bsp project, not an app project. What is a bsp project? What is an app project? To put it simply, if you create a nios project named hello according to our tutorial, the software will automatically create a project named hello_bsp for you. Then this hello is the app project (application project), and hello_bsp is the bsp project (class support package project).
The closing method is very simple. Select the bsp project with the left mouse button, and then press Ctrl+9 on the keyboard to enter the bsp setting interface. Switch to the drivers option in this interface, and then cancel the default open option behind the IP of the driver you want to close.

After exiting, you need to select the bsp project, right-click to execute the NIOS II ->Generate BSP operation, and then compile the project (ctrl + B).