MCU delay method (Keil software delay)

There are four commonly used delay methods in C language, as shown in Figure 4-2.

Figure 2-4 C language delay method

Figure 2-4 shows four common delay methods used in C language programming, two of which are inaccurate delays and two more accurate delays. Both the for statement and the while statement can change the delay time by changing the range of i, but the execution time of the C language loop cannot be seen through the program. There are two methods for accurate delay. One method is to use a timer to delay. We will introduce this method in detail in the later course. The timer is a key point of the microcontroller. The other is to use the library function nop();. The time of a NOP is the time of a machine cycle, which will also be introduced later.

Inaccurate delay is only used in some simple demonstration experiments such as flashing small lights and flowing lights. In the actual project development process, this kind of inaccurate delay is rarely used.

Okay, now that we have introduced it, we are going to practice. In the last lesson, the delay method used in the LED light flashing program is for(i=0;i<30000;i++); if you change i here to 100 and download it into the microcontroller, you will find that the light is always on instead of flashing. Now please change this program to 100, then download it and observe the phenomenon before continuing...

After the observation, there is no doubt that the actual phenomenon is consistent with the theory I mentioned. Why is this? Here is a common sense. Our naked eyes have a minimum resolution for flickering light. Usually, when the flickering frequency is higher than 50 Hz, the signal we see is always on. That is, when the delay time is less than 20 ms, our naked eyes cannot distinguish that the small light is flickering. The most we can see is that the light of the small light changes slightly. In order to clearly see the flickering of the small light, the delay value must be larger. How large is it? Lights of different brightness are not exactly the same. You can do experiments yourself.

So how do we observe how long the delay we wrote is? Select the Keil menu item Project-->Options for Target “Target1”..., or click the icon mentioned in Figure 2-17 to enter the project options, as shown in Figure 4-3.

Figure 4-3 Project Options - Clock Frequency Settings

First, open the Target tab and find the Xtal (MHz) position. This is where we fill in the crystal oscillator option for simulation time. From our schematic diagram and board, we can see that the crystal oscillator used by the microcontroller is 11.0592 MHz, so we need to fill in 11.0592 here. Then find the Debug tab, select Use Simulator on the left, and then click OK at the bottom, as shown in Figure 4-4.

Figure 4-4 Project Options - Simulation Settings

Select the menu item Debug-->Start/Stop Debug Session, or click the button in the red box in Figure 4-5, and you will enter a new page as shown in Figure 4-6.

Figure 4-5 Start/End Debugging Button

Figure 4-6 Project debugging interface

The leftmost column shows the current values ​​of some registers of the microcontroller and system information. The topmost column is the code that Keil converts from C language to assembly language. Below is the program we write in C language. The debugging interface contains many sub-windows, which can be opened and closed through the options in the View menu. You may feel that this default distribution is not in line with your habits or inconvenient to observe specific information. It is easy to deal with. The positions of almost all sub-windows on the interface can be adjusted. For example, if I want to place the Disassembly window and the source code window side by side horizontally, I only need to drag the title bar of the Disassembly window with the mouse. At this time, multiple icons indicating the target position will appear on the screen. Drag the window and move the mouse to the corresponding icon. The software will also indicate the specific position with a blue background, as shown in Figure 4-7. Release the mouse and the window will be placed in the new position. The effect after adjustment is shown in Figure 4-8.

Figure 4-7 Adjusting the window position

Figure 4-8 Window position adjustment effect

You may have noticed that there is a yellow arrow in the C language source code file and the disassembly window. This arrow represents the current running position of the program. Because the code in the disassembly is generated by compiling the source file, they indicate the same actual position. In this project debugging interface, we can see the process of program running. There are three buttons in the toolbar in the upper left corner: the first one marked with RST is reset. After clicking it, the program will run to the beginning; the button next to the right is full speed run. Click it and the program will run at full speed; the cross on the right is the stop button. When the program runs at full speed, we can stop the program by clicking the third icon to observe where the program runs. After clicking reset, you will find that there is gray or green on the left side of the C language program, and some places still remain white. We can double-click the mouse to set a breakpoint in our gray position. For example, if the program has 20 lines in total, after setting a breakpoint on the tenth line, click full speed run, and the program will run to the tenth line and stop, which is convenient for us to observe the situation when it runs to this place.

Students will find that breakpoints can be set at some locations, but not at others. Why is this? Because Keil software itself has the function of program optimization. If you want to set breakpoints at all code locations, you can set the optimization level to 0 in the project options, which means telling Keil not to optimize. As shown in Figure 4-9.

Figure 4-9 Engineering Optimization Level

In this lesson, we will focus on the running time of the C language code. In the register box on the far left, there is a sec option, which shows how long the microcontroller has been running. Click the reset button and you will find that the sec becomes 0. Then we add a breakpoint at the sentence LED = 0; and another breakpoint at the position LED = 1;. When we click the full speed run button, it will stop directly at LED = 0; and we will see that our time changes to 0.00042752 seconds, as shown in Figure 4-10. Please note that the optimization level we set here is the default 8. If you use other levels, the running time will be different because the optimization level will directly affect the execution efficiency of the program.

Figure 4-10 View program running time

Click on Run at Full Speed ​​again, and you will find that sec becomes 0.16342556. Then minus the last value, we get the time the program takes to execute between the two breakpoints, which is the execution time of the for loop, which is about 163 ms. We can also change the delay time by changing the number 30000. Of course, everyone should pay attention to the value range of i. If you write a value greater than 65535, the program will not run any more, because no matter how i changes, it will not be greater than this value. If you want to exceed this value and run normally, you must change the type defined by i. Later, if we want to check how long a program has been running, we can check it in this way.

In fact, when you enter debug mode, you can not only see how long the program has been running, but also observe the value changes of each register and each variable. Click Watch Windows-->Watch 1 in the View menu to open the variable observation window, as shown in Figure 4-11.

Figure 4-11 Variable observation window

In this window, we can double-click or press the F2 key, then enter the name of the variable or register we want to observe, and its value will be displayed. This function is more useful in our later debugging program, so let's learn about it first.