Share one year of program debugging experience

   First of all, the software writing environment. Choosing a compilation platform is crucial for the efficiency of writing code. In actual development, Source Insight is basically used to write and modify program code. I am currently using Source Insight3.5. This software is very powerful and can help you quickly locate code, view code variable usage, and call status of each location. Color management is also excellent. You can judge various information based on color, such as whether the variable is defined, whether it is a local variable or a global variable, etc. It can be said that once you have used it, you will never want to write code in the KEIL environment again. Of course, it is a bit difficult to feel if the program is small, but for large programs and full use of program modularization, that is, the use of header files, the speed of locating the program can reach wherever you want. After getting familiar with it, you basically use various shortcut keys to operate, and then KEIL is used as a compiler.

There are still some particularities in building a KEIL project. If the code is relatively large and the entire project is placed in the same file, then the things in this file are like a grocery store, and it is difficult to find something. The following is how to build a simple Keil project. After setting the relevant header file call path, list and project storage files in Keil, the program code of the entire project will be independent of the Keil project file, which will greatly facilitate the transplantation and backup of the code, and of course, there are more detailed projects. In this way, it is convenient to add files to the Source Insight project and manage the code with SVN version.

 

  The naming convention of variables and functions in a project is very important, so that you can know the meaning and function of variables and functions by seeing the function or variable name. I usually name the commands according to the keywords related to the function, and distinguish between keywords with uppercase and lowercase. My English is also very poor, but I don’t need to understand grammar, but I still need to know how to use professional English words. For variable definitions, try to use structures. For example, you can build a time structure variable for time, which contains year, month, day, hour, minute, second, and week. In this way, it is very easy to operate and intuitive to define a time.

 

  Program debugging is the most important part of writing programs. A good debugging method can quickly complete program debugging. In the past, debugging meant setting a light on the board, otherwise you would not know where the program went wrong. So in the past, you did not know how to debug without a light. But even with a light, the efficiency is very low and it is not very realistic in practice. Using serial port printing information to debug the program can completely print information in the printf function format under TUBRO C 2.0, such as using %d, %s, %f, and %c to print the values ​​of various types of variables. This function is the debug.c and debug.h module files. Precompilation plays an important role here. You can control the printed information according to your own configuration definition. When the program debugging is completed, the printing information is closed, so that the compiler will not compile the debugging information. This means that you don’t have to delete the debugging code one by one. When you want to change the program, you can reopen the compilation information. This makes full use of the precompilation and DUBUG in the C language. This is why there are debug and release versions in the program. When the debug version program is running, you can often see related information on the serial port. Assert (condition) is also an important debugging method for detecting key parameters in the program, but when the condition is not met, the line number of the file where the error occurs and the error condition information are printed. The construction of the serial port debugging environment consumes some resources when debugging is enabled, but now the microcontroller basically has external RAM, making serial port debugging possible on the 51 microcontroller.

 

  Appendix: When I was debugging keil51, I encountered some problems with printing char type. For example, if char a=0X01, using printf("a=%c",a), the serial port will print out a=0100, and using printf("a=%d",a), the serial port will print out a=512, but it did not appear in keilARM. It should be a problem with the 51keil standard library.

 

  In the past, the most commonly used comments for program shielding were "//" and "/**/". // shields a line of code. When shielding a section of code, /**/ is used to shield it, but some comments are often also commented with /**/. If the shielded section of code happens to use the comment of /**/, then there will be a problem. In the past, /**/ in the code section would be changed to // comment. Now we can use #if a section of code #endif to shield a section of code. When the condition is true, the compiler compiles the code. If it is 0, the code is not compiled. This is much easier.

  In the front-end and back-end systems, when writing a program to handle a single task, the difficult function is just one function, and the code is easy to write. When multiple tasks are given and the tasks seem to be real-time, such as digital tube display, button operation, running lights, and dot matrix display lights, when these tasks are put together, there is a problem of time allocation. These buttons need to react immediately when we press them, digital display, dot matrix display, and running lights all need to be processed in real time. For example, if a button cannot react in time when it is pressed, the display stops at a certain state when the button is pressed. In reality, these phenomena can occur at the same time, and you cannot see the above phenomena. To handle such events, the foreground and background systems are often *running, and the foreground and background systems are just like looking at the timer to build the soft interrupt of this program. For example, the interrupt in the microcontroller is a machine cycle to query the status bit of the interrupt. If it meets the interrupt, the program will put down the current code to execute the interrupt code. However, buttons, digital displays, and dot matrices are very short for people, but very long for microcontrollers. With this kind of thinking, we can build a simulation software interrupt query cycle set by ourselves. This cycle is *timer to set the interrupt interval time, and the event processed in the timer is best to take up a short time, such as counting, a few assignments, status judgment and marking, and then the background (the code in the main() function) will process the corresponding event according to the mark status returned by the foreground (the code in the TimerTnterrupt() function). This is a bit like the system beat of the operating system, simply called the heart of the system.