Improving Embedded Software Quality Using Function Parameters and Return Values

introduction

Improving the quality of software code is an issue that every software designer must consider, which involves the effectiveness and economic value of the software. Most software designs based on embedded systems are based on real-time operating systems, which is very different from traditional programming based on Windows operating systems. The former requires a deeper understanding of the operating system, requires users to have a considerable understanding of the working principles of their own processors and compilers, and to be able to write a certain amount of porting code to achieve the connection between the operating system and the underlying hardware. μC/OS-II is a preemptive real-time operating system kernel with open source code. This article mainly combines the application of μC/OS-II system functions to explain how to use the parameters and return values ​​of μC/OS-II system functions to improve programming efficiency and code quality.

1 Parameter and return value classification

Through the study and research of μC/OS-II, it can be found that most of the system functions it provides are written in standard C language; restricted by the syntax rules of C language, these functions have only one return value. In order to obtain more status information when using the system functions of μC/OSII, the status information is saved in the function parameters. In this way, the parameters of μC/OS-II system functions can be divided into two categories: the first category is ordinary formal parameters, which conform to the traditional usage method and mainly pass the value of the actual parameter, playing the role of numerical transmission; the second category of formal parameters does not pass valid values ​​when used, but is only a variable. The status information generated during the execution of the system function is saved in the second category of parameters. At the end of the system function call, the value of this type of parameter can be used to view the status information generated during the execution of the system function.

This article takes the function 0SSemPend() as an example. This function has no return value. The specific meaning of each of its formal parameters can be found in the references, and no specific description is given here. Its parameters can be classified into the above two categories: OS_EVENT*pevent and INTl6U timeout are the first category, and the actual parameters in the application program must give them specific values; INT8U*err is the second category, and the actual parameters in the application program do not need to give specific values. When the function code is executed, INT8U*err will be assigned a value according to different situations. This value reflects the execution status of the function. As shown in the application of the OSSemPend() function.

2 Status information in function parameters and return values

According to the actual situation, the system functions of μC/OS-II can be divided into functions without parameters and return values, functions with parameters but no return values, and functions with both parameters and return values. The first case is not discussed here. This paper mainly studies the second and third cases. As mentioned above, in order to increase the status information and return value generated by the execution of system functions, μC/OS-II puts the status information into the function parameters. Through the study of the system functions of μC/OS-II, the author found that these functions do not all put the status information into the function parameters. Some also put it into the return value, such as the OSsemQtJery() function, which uses the status information passed by the return value and the valid information passed by the function parameters. These status information reflects the problems that occur when using the system functions of μC/OS-II. By reading these status information, the execution status of the system function can be known. Therefore, from a security perspective, all status information should be read when using these system functions, and corresponding processing instructions should be given according to different status. According to this idea, the application of the OSSemPend() function is improved as follows:

It can be seen that when calling the system service function OSSemPend(), the temporary variable err is passed to OSSemPend() as the actual parameter. After executing this function, the temporary variable err contains the status information generated when the function is executed. These status information use constants instead of a constant to increase the readability and versatility of the software. The specific definitions and meanings are listed in Table 1, where the first two return values ​​are normal: the first is when a signal is available, and normal processing is performed; the second is when no signal arrives within the specified time, and timeout processing is performed. The last three situations are caused by human errors. After calling the OSSemPend() system function, the variable containing the status information must be analyzed and processed. The process is shown in the above program. Due to space constraints, only a simple sentence is used here to represent the processing process.

3 Use of status information

When calling each system function of μC/OS-II, as long as the called function provides status information, the status information should be analyzed and processed. Professional software designers believe in such a truth: "The best way to write error-free code is to put error prevention in the first place". Take calling the system function OSSemPend() of μC/OS-II as an example. Users do not need to change the code of the OSSemPend() function, assuming that there is no problem with this part of the content. Now we need to detect the status of this function when it is executed, that is, the error information it generates. This function returns three results to indicate the errors used by the user, as listed in Table 1: OS_ERR_EVENT_TYPE means that the pointer data provided by the user when calling the OSSemPend() function does not point to the semaphore, and a type error occurs; OS_ERR_PEVENT_NULL means that the pointer provided by the user as the actual parameter is a null pointer; OS_ERR_PEND_ISR means that the user called the OSSemPend() function in the interrupt service program; these three status errors are caused by the user's carelessness or lack of understanding of the μC/OS-II system function during the software design stage. As long as the user is careful during the design process, such errors can be avoided. However, from the perspective of preventing errors, it is necessary to detect and handle the status of these errors, so that when an error occurs, the error handler will give a simple prompt or even modify the error. The error handler prevents repeated reading of program code during program debugging, avoids spending a lot of energy to find errors, and improves software design efficiency.

The embedded system software designed according to the above scheme can be considered an ideal compiler. Now consider, if the compiler can correctly point out all the problems in the code, what will the error situation of the corresponding program be? This does not only refer to syntax errors, but also any problems in the program, no matter how hidden it is. Obviously, all current compilers cannot achieve this function, so the functions of the compiler need to be extended. This design idea can be considered as: the software designer needs to design the extended functions of the compiler so that the compiler can check errors by itself when designing the software. If this can be done, the workload of software design will be greatly reduced.

4 Debug and delivery versions of software

The previous improved program handles all possible states generated by the OSSemPend() function call, and most of this part of the code is redundant code, in order to facilitate software design and debugging. When using the real-time operating system μC/0S-II for embedded software design, there are certainly more than one system function used, OSSemPend(). If each function call is handled as in the program, the code space will increase rapidly and the program efficiency will be greatly reduced.

To solve this problem, first of all, if the program design is done very carefully, most of the state detection and processing processes can be omitted. The reason for detecting and processing each state information is to improve the efficiency of software design and debugging. After the software is debugged, it is unnecessary to detect some state information. This is like buying insurance before taking a flight. After the flight arrives at the destination, the insurance is useless. The software is ultimately provided to customers as a product. This product is the final version (of course it will be continuously upgraded). There will be a debugging version when designing the product, and this debugging version must run through the entire software life cycle. The debugging version is for software design, debugging and upgrading. It will not be provided to users, let alone appear in the product.

When it comes to embedded system software design, we still use the code that calls the OS_SemPend() function as an example to illustrate the problem.

By observing the above program and the previous improvements, it is found that several conditional compilation instructions are added to this program. If the TEST flag is not defined, a part of the code will not be compiled, which is the delivery version of the software. On the contrary, if the TEST flag is defined, it means it is a debug version, and all instruction codes will be compiled. By comparing the two versions, we can see that the code of the delivery version is much less than that of the debug version. And through analysis, we know that after the software is debugged, there will be no errors of OS_ERR_EVENT_TYPE, 0S_ERR_PEND_ISR and OS_ERR_PEVENT_NULL. The functions implemented by these two versions are exactly the same, and there is really no need to compile this part of the code.

Conclusion

In the process of embedded system software design, embedded real-time operating systems are used in most cases. On the premise of ensuring the quality of the designed code, users must also fully consider the state information generated when calling system functions and perform appropriate processing. Only in this way can the design efficiency of the software be improved and the design cycle be shortened.