利用函数参数和返回值提高嵌入式软件质量

1 参数和返回值分类
    通过对μC／0S—II的学习和研究，可以发现它提供的系统函数大多是用标准C语言写的；受C语言语法规则的限制，这些函数只有一个返回值。为了在使用μC／0SII的系统函数时得到更多的状态信息，将状态信息保存在函数参数中。这样，μC／OS—II系统函数的参数可以分为两类：第一类是普通的形式参数，这类参数符合传统的使用方法，主要传递实际参数的值，起到数值传递的作用；第二类形式参数在使用时，不传递有效数值，仅是一个变量。系统函数在执行时产生的状态信息就保存在第二类参数里，在系统函数调用结束时通过这类参数的值来查看系统函数执行过程中产生的状态信息。
    本文以函数0SSemPend()为例来介绍。这个函数没有返回值，它每个形式参数的具体含义见参考文献，这里不做具体的描述。其参数可归为上述的两类：OS_EVENT*pevent和INTl6U timeout为第一类，应用程序中的实际参数要给予它们具体的数值；INT8U*err为第二类，应用程序中的实际参数不需要给出具体的数值，在函数代码执行时，会根据不同的情况给INT8U*err赋值，这个值反映了函数的执行情况。如OSSemPend()函数的应用所示。

2 函数参数和返回值中的状态信息
    μC／OS—II的系统函数根据实际情况可以分为没有参数和返回值的函数、有参数没有返回值的函数和既有参数又有返回值的函数。在这里不讨论第一种情况，本文主要研究的是第二和第三种情况。如前所述，μC／OS—II为了增加系统函数执行产生的状态信息和返回值，将状态信息放到函数的参数中。笔者通过对μC／0S—II的系统函数的研究发现，这些函数并不是都将状态信息放到函数的参数中。有的也放到返回值中，如OSsemQtJery()函数，就是用返回值传递的状态信息，而用函数的参数传递的有效信息。这些状态信息反映了在使用μC／OS—II的系统函数时出现的问题，通过读这些状态可以知道系统函数执行的情况。因此，从安全的角度来说，在使用这些系统函数时应该读出所有状态信息，并且根据状态的不同给出相应的处理指令。按照这种思路，对OSSemPend()函数的应用的改进如下：

    可以看到，在调用系统服务函数OSSemPend()时，临时变量err作为实际参数传递给OSSemPend()。在执行这个函数后，err这个临时变量就包含了函数执行时产生的状态信息。这些状态信息使用常量而不用一个常数，是为了增加软件的可读性和通用性。具体的定义和含义如表1所列，其中前两种返回值是正常的：第一种是有信号可用时的情况，进行正常的处理；第二种是在规定的时间内没有信号到来，要做超时处理。后面三种情况是人为错误造成的。在调用OSSemPend()系统函数后要对这个包含状态信息的变量进行分析处理，过程如上述程序所示，由于篇幅关系，这里只是用简单的一句话来代表处理过程。[!--empirenews.page--]

3 状态信息的使用
    在调用μC／OS—II的每个系统函数时，只要被调用的函数提供状态信息，都应该对这些状态信息进行分析和处理。专业软件设计者信奉这样一个道理：“编写无错代码的最好方法是把防止错误放在第一位”。以调用μC／OS—II的系统函数OSSemPend()为例，用户不需要去改动OSSemPend()函数的代码，假设这部分内容是没有什么问题的。现在我们要做的是检测这个函数执行时的状态，也就是它产生的出错信息。这个函数返回三种结果说明用户使用的错误，如表1所列：0S_ERR_EVENT_TYPE表示用户在调用OSSemPend()函数时提供的指针数据不是指向信号量的，发生了类型错误；OS_ERR_PEVENT_NULL表示用户提供的用作实际参数的指针是一个空指针；OS_ERR_PEND_ISR表示用户在中断服务程序中调用了OSSemPend()函数；这三种状态错误是在软件设计阶段由于用户粗心或者对μC／OS—II系统函数不了解而导致的。只要用户在设计过程中小心谨慎，这类错误可以避免。但是，从防止错误的角度来考虑，对这些错误的状态进行检测和处理是必要的，这样在错误发生时错误处理程序会给出简单的提示甚至对错误进行修改。错误处理程序防止在程序调试过程中反复阅读程序代码，避免了花费很大的精力去查找错误，提高了软件设计效率。
    按照以上方案设计出的嵌入式系统软件可以认为是一个理想的编译器。现在考虑一下，倘若编译程序能够正确地指出代码中的所有问题，那相应程序的错误情况会怎样?这不单指语法错误，还包括程序中的任何问题，不管它多么隐蔽。显然，现在所有的编译器都无法实现这种功能，所以要对编译器的功能进行扩展。这种设计思路可以认为是：软件设计者要设计出编译器的扩展功能，使得在进行软件设计时，编译器能够自己检查错误。如果能够做到，软件设计的劳动量将大大降低。

4 软件的调试版与交付版
    前面的改进程序对OSSemPend()函数调用产生的所有可能状态进行了处理，而这部分代码中的大部分都是冗余代码，为的是便于软件的设计和调试。使用实时操作系统μC／0S—II进行嵌入式软件设计，用到的系统函数当然不止OSSemPend()一个，如果每个函数调用结束后都像程序中那样处理，代码的空间会迅速增加，程序的效率则会大大降低。
    为了解决这个问题，首先考虑，如果非常谨慎小心进行程序设计，多数的状态检测处理过程就可以省略。之所以对每个状态信息进行检测处理是为了提高软件设计调试的效率。在软件调试通过后，有些状态信息的检测就没有必要了。这就像乘坐飞机出行前要买保险，等航班到达目的地后，保险就没有什么用处了。软件最终是作为一个产品提供给客户的。这个产品是最终版本(当然还会不断升级)。在进行产品设计时会有一个调试版本，这个调试版要贯穿整个软件的生存周期。调试版是为了软件的设计、调试和升级使用，不会提供给用户，更不会出现在产品中。
    具体到嵌入式系统软件设计问题，仍然以调用OS—SemPend()函数的代码为例来说明问题。调用OSSem—

    通过观察上述程序和前面的改进发现，本段程序中加了几个条件编译指令。如果没有定义TEST标志，则有一部分代码将不会被编译，这就是交付版软件。反之，如果定义了TEST标志，则表示为调试版，所有的指令代码都会被编译。通过比较这两个版本看到：交付版的代码比调试版的代码在数量上大大减少。而且通过分析知道，在软件调试通过以后，就不存在OS_ERR_EVENT_TYPE、0S_ERR_PEND_ISR和OS_ERR_PEVENT_NULL的错误了，这两个版本实现的功能完全相同，这部分代码确实没有编译的必要了。

结 语
    嵌入式系统软件设计过程中，大部分场合会用到嵌入式实时操作系统。用户在保证自已设计代码质量的前提下，还要充分考虑调用系统函数时产生的状态信息，并进行适当的处理。只有这样，才能够提高软件的设计效率，缩短设计周期。