uCOS-II中的可移植代码的精华分析
uCOS-II中代码是可移植的。其中一些基本知识和基本方法可以供我辈在编译程序时使用。
1.Includes.h
所有的*.C文件都包含头文件 #include “includes.h”
INCLUDE.H可以使用户不必在工程项目中每个*.C文件中都考虑需要什么样的头文件。换句话说,INCLUDE.H是主头文件。这样做唯一的缺点是INCLUDES.H中许多头文件在一些*.C文件的编译中是不需要的。这意味着逐个编译这些文件要花费额外的时间。这虽有些不便,但代码的可移植性却增加了。
2.不依赖于编译的数据类型
因为不同的微处理器有不同的字长,µC/OS-II的移植文件包括很多类型定义以确保可移植性。µCOS-II不使用C语言中的short,int,long等数据类型的定义,因为它们与处理器类型有关,隐含着不可移植性。作者代之以移植性强的整数数据类型,这样,既直观又可移植,如表L1.1所示。为了方便起见,还定义了浮点数数据类型,虽然µC/OS-II中没有使用浮点数。
程序清单 L1.1 可移植型数据类型。 |
Typedef unsigned char BOOLEAN; |
Typedef unsigned char INT8U; |
Typedef signed char INT8S; |
Typedef unsigned int INT16U; |
Typedef signed int INT16S; |
Typedef unsigned long INT32U; |
Typedef signed long INT32S; |
Typedef float FP32; |
Typedef double FP64; |
|
以INT16U数据类型为例,它代表16位无符号整数数据类型。µC/OS-II和用户的应用代码可以定义这种类型的数据,范围从0到65,535。如果将µCO/S-II移植到32位处理器中,那就意味着INT16U不再不是一个无符号整型数据,而是一个无符号短整型数据。然而无论将µC/OS-II用到哪里,都会当作INT16U处理。
3.全局变量
众所周知,全局变量应该是得到内存分配且可以被其他模块通过C语言中extern关键字调用的变量。因此,必须在 .C 和 .H 文件中定义。这种重复的定义很容易导致错误。以下讨论的方法只需用在头文件中定义一次。虽然有点不易懂,但用户一旦掌握,使用起来却很灵活。表1.2中的定义出现在定义所有全局变量的.H头文件中。
程序清单 L 1.2 定义全局宏。 |
#ifdef xxx_GLOBALS |
#define xxx_EXT |
#else |
#define xxx_EXT extern |
#endif |
.H 文件中每个全局变量都加上了xxx_EXT的前缀。xxx代表模块的名字。该模块的.C文件中有以下定义:
#define xxx_GLOBALS |
#include "includes.h" |
当编译器处理.C文件时,它强制xxx_EXT(在相应.H文件中可以找到)为空,(因为xxx_GLOBALS已经定义)。所以编译器给每个全局变量分配内存空间,而当编译器处理其他.C文件时,xxx_GLOBAL没有定义,xxx_EXT被定义为extern,这样用户就可以调用外部全局变量。为了说明这个概念,可以参见uC/OS_II.H,其中包括以下定义:
#ifdef OS_GLOBALS |
#define OS_EXT |
#else |
#define OS_EXT extern |
#endif |
|
OS_EXT INT32U OSIdleCtr; |
OS_EXT INT32U OSIdleCtrRun; |
OS_EXT INT32U OSIdleCtrMax; |
同时,uCOS_II.H有中以下定义:
#define OS_GLOBALS |
#include “includes.h” |
当编译器处理uCOS_II.C时,它使得头文件变成如下所示,因为OS_EXT被设置为空。
INT32U OSIdleCtr; |
INT32U OSIdleCtrRun; |
INT32U OSIdleCtrMax; |
这样编译器就会将这些全局变量分配在内存中。当编译器处理其他.C文件时,头文件变成了如下的样子,因为OS_GLOBAL没有定义,所以OS_EXT被定义为extern。
extern INT32U OSIdleCtr; |
extern INT32U OSIdleCtrRun; |
extern INT32U OSIdleCtrMax; |
在这种情况下,不产生内存分配,而任何 .C文件都可以使用这些变量。这样的就只需在 .H 文件中定义一次就可以了。
发表评论 评论 (0 个评论)