这一章介绍如何将μC/OS-Ⅱ移植到不同的处理器上。所谓移植，就是使一个实时内核能在某个微处理器或微控制器上运行。为了方便移植，大部分的μC/OS-Ⅱ代码是用C语言写的;但仍需要用C和汇编语言写一些与处理器相关的代码，这是因为μC/OS-Ⅱ在读写处理器寄存器时只能通过汇编语言来实现。由于μC/OS-Ⅱ在设计时就已经充分考虑了可移植性，所以μC/OS-Ⅱ的移植相对来说是比较容易的。如果已经有人在您使用的处理器上成功地移植了μC/OS-Ⅱ，您也得到了相关代码，就不必看本章了。当然，本章介绍的内容将有助于用户了解μC/OS-Ⅱ中与处理器相关的代码。

要使μC/OS-Ⅱ正常运行，处理器必须满足以下要求：

1.处理器的C编译器能产生可重入代码。

2.用C语言就可以打开和关闭中断。

3.处理器支持中断，并且能产生定时中断(通常在10至100Hz之间)。

4.处理器支持能够容纳一定量数据(可能是几千字节)的硬件堆栈。

5.处理器有将堆栈指针和其它CPU寄存器读出和存储到堆栈或内存中的指令。

像Motorola6805系列的处理器不能满足上面的第4条和第5条要求，所以μC/OS-Ⅱ不能在这类处理器上运行。

图8.1说明了μC/OS-Ⅱ的结构以及它与硬件的关系。由于μC/OS-Ⅱ为自由软件，当用户用到μC/OS-Ⅱ时，有责任公开应用软件和μC/OS-Ⅱ的配置代码。这本书和磁盘包含了所有与处理器无关的代码和Intel80x86实模式下的与处理器相关的代码(C编译器大模式下编译) 。如果用户打算在其它处理器上使用μC/OS-Ⅱ，最好能找到一个现成的移植实例，如果没有只好自己编写了。用户可以在正式的μC/OS-Ⅱ网站www. μCOS-Ⅱ.com中查找一些移植实例。

图 8.1μC/OS-II 硬件和软件体系结构

如果用户理解了处理器和C编译器的技术细节，移植μC/OS-Ⅱ的工作实际上是非常简单的。前提是您的处理器和编译器满足了μC/OS-Ⅱ的要求，并且已经有了必要工具。移植工作包括以下几个内容：

z 用#define设置一个常量的值(OS_CPU.H)

z 声明10个数据类型(OS_CPU.H)

z 用#define声明三个宏(OS_CPU.H)

z 用C语言编写六个简单的函数(OS_CPU_C.C)

z 编写四个汇编语言函数(OS_CPU_A.ASM)

根据处理器的不同，一个移植实例可能需要编写或改写50至300行的代码，需要的时间从几个小时到一星期不等。

一旦代码移植结束，下一步工作就是测试。测试一个象μC/OS-Ⅱ一样的多任务实时内核并不复杂。 甚至可以在没有应用程序的情况下测试。 换句话说， 就是让内核自己测试自己。这样做有两个好处：第一，避免使本来就复杂的事情更加复杂;第二，如果出现问题，可以知道问题出在内核代码上而不是应用程序。 刚开始的时候可以运行一些简单的任务和时钟节拍中断服务例程。一旦多任务调度成功地运行了，再添加应用程序的任务就是非常简单的工作了。

8.00 开发工具

如前所述，移植μC/OS-Ⅱ需要一个C编译器，并且是针对用户用的CPU的。因为μC/OS-Ⅱ是一个可剥夺型内核，用户只有通过C编译器来产生可重入代码;C编译器还要支持汇编语言程序。 绝大部分的C编译器都是为嵌入式系统设计的， 它包括汇编器、 连接器和定位器。

连接器用来将不同的模块(编译过和汇编过的文件)连接成目标文件。 定位器则允许用户将代码和数据放置在目标处理器的指定内存映射空间中。 所用的C编译器还必须提供一个机制来从C中打开和关闭中断。一些编译器允许用户在C源代码中插入汇编语言。这就使得插入合适的处理器指令来允许和禁止中断变得非常容易了。 还有一些编译器实际上包括了语言扩展功能，可以直接从C中允许和禁止中断。

8.01 目录和文件

本书所付的磁盘中提供了μC/OS-Ⅱ的安装程序，可在硬盘上安装μC/OS-Ⅱ和移植实例代码(Intel80x86实模式，大模式编译)。我设计了一个连续的目录结构，使得用户更容易找到目标处理器的文件。如果想增加一个其它处理器的移植实例，您可以考虑采取同样的方法(包括目录的建立和文件的命名等等) 。

所有的移植实例都应放在用户硬盘的\SOFTWARE\μCOS-Ⅱ目录下。各个微处理器或微控制器的移植源代码必须在以下两个或三个文件中找到：OS_CPU.H，OS_CPU_C.C，OS_CPU_A.ASM。汇编语言文件OS_CPU_A.ASM是可选择的，因为某些C编译器允许用户在C语言中插入汇编语言，所以用户可以将所需的汇编语言代码直接放到OS_CPU_C.C中。放置移植实例的目录决定于用户所用的处理器， 例如在下面的表中所示的放置不同移植实例的目录结构。注意，各个目录虽然针对完全不同的目标处理器，但都包括了相同的文件名。

8.02INCLUDES.H

在第一章中曾提到过，INCLUDES.H是一个头文件，它在所有.C文件的第一行被包含。

#include"includes.h"

INCLUDES.H使得用户项目中的每个.C文件不用分别去考虑它实际上需要哪些头文件。使用INCLUDES.H的唯一缺点是它可能会包含一些实际不相关的头文件。这意味着每个文件的编译时间可能会增加。 但由于它增强了代码的可移植性， 所以我们还是决定使用这一方法。用户可以通过编辑INCLUDES.H来增加自己的头文件，但是用户的头文件必须添加在头文件列表的最后。

8.03OS_CPU.H

OS_CPU.H包括了用#defines定义的与处理器相关的常量，宏和类型定义。OS_CPU.H的

大体结构如程序清单L8.1所示。

程序清单 L8.1 OS_CPU.H.

#ifdefOS_CPU_GLOBALS

#defineOS_CPU_EXT

#else

#defineOS_CPU_EXTextern

#endif

/*

************************************************************************

* 数据类型

*(与编译器相关)

************************************************************************

*/

typedefunsignedcharBOOLEAN;

typedefunsignedcharINT8U;/* 无符号8位整数 */(1)

typedefsignedcharINT8S;/* 有符号8位整数 */

typedefunsignedinTINT16U;/* 无符号16位整数 */

typedefsignedintINT16S;/* 有符号16位整数 */

typedefunsignedlONgINT32U;/* 无符号32位整数 */

typedefsignedlongINT32S;/* 有符号32位整数 */

typedeffloatFP32;/* 单精度浮点数 */(2)

typedefdoubleFP64;/* 双精度浮点数 */

typedefunsignedintOS_STK;/* 堆栈入口宽度为16位 */

/*

*************************************************************************

* 与处理器相关的代码

*************************************************************************

*/

#defineOS_ENTER_CRITICAL()???/* 禁止中断 */(3)

#defineOS_EXIT_CRITICAL()???/* 允许中断 */

#defineOS_STK_GROWTH1/* 定义堆栈的增长方向： 1=向下,0=向上 */(4)

#defineOS_TASK_SW()???(5)

8.03.01与编译器相关的数据类型

因为不同的微处理器有不同的字长，所以μC/OS-Ⅱ的移植包括了一系列的类型定义以确保其可移植性。尤其是，μC/OS-Ⅱ代码从不使用C的short,int和long等数据类型，因为它们是与编译器相关的，不可移植。相反的，我定义的整型数据结构既是可移植的又是直观的[L8.1(2)]。为了方便，虽然μC/OS-Ⅱ不使用浮点数据，但我还是定义了浮点数据类型[L8.1(2)]。

例如，INT16U数据类型总是代表16位的无符号整数。现在，μC/OS-Ⅱ和用户的应用程序就可以估计出声明为该数据类型的变量的数值范围是0-65535。 将μC/OS-Ⅱ移植到32位的处理器上也就意味着INT16U实际被声明为无符号短整型数据结构而不是无符号整型数据结构。但是，μC/OS-Ⅱ所处理的仍然是INT16U。

用户必须将任务堆栈的数据类型告诉给μC/OS-Ⅱ。这个过程是通过为OS_STK声明正确的C数据类型来完成的。如果用户的处理器上的堆栈成员是32位的，并且用户的编译文件指定整型为32位数，那么就应该将OS_STK声明位无符号整型数据类型。所有的任务堆栈都必须用OS_STK来声明数据类型。用户所必须要做的就是查看编译器手册，并找到对应于μC/OS-Ⅱ的标准C数据类型。

8.03.02OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()

与所有的实时内核一样，μC/OS-Ⅱ需要先禁止中断再访问代码的临界段，并且在访问完毕后重新允许中断。这就使得μC/OS-Ⅱ能够保护临界段代码免受多任务或中断服务例程(ISRs)的破坏。中断禁止时间是商业实时内核公司提供的重要指标之一，因为它将影响到用户的系统对实时事件的响应能力。 虽然μC/OS-Ⅱ尽量使中断禁止时间达到最短， 但是μC/OS-Ⅱ的中断禁止时间还主要依赖于处理器结构和编译器产生的代码的质量。 通常每个处理器都会提供一定的指令来禁止/允许中断，因此用户的C编译器必须要有一定的机制来直接从C中执行这些操作。有些编译器能够允许用户在C源代码中插入汇编语言声明。这样就使得插入处理器指令来允许和禁止中断变得很容易了。其它一些编译器实际上包括了语言扩展功能，可以直接从C中允许和禁止中断。为了隐藏编译器厂商提供的具体实现方法，μC/OS-Ⅱ定义了两个宏来禁止和允许中断：

OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()[L8.1(3)]。

{

OS_ENTER_CRITICAL();

/* ? μC/OS-II 临界代码段 */

OS_EXIT_CRITICAL();

}

方法1

执行这两个宏的第一个也是最简单的方法是在OS_ENTER_CRITICAL()中调用处理器指令来禁止中断，以及在OS_EXIT_CRITICAL()中调用允许中断指令。但是，在这个过程中还存在着小小的问题。如果用户在禁止中断的情况下调用μC/OS-Ⅱ函数，在从μC/OS-Ⅱ返回的时候，中断可能会变成是允许的了!如果用户禁止中断就表明用户想在从μC/OS-Ⅱ函数返回的时候中断还是禁止的。在这种情况下，光靠这种执行方法可能是不够的。

方法2

执行OS_ENTER_CRITICAL()的第二个方法是先将中断禁止状态保存到堆栈中，然后禁止中断。而执行OS_EXIT_CRITICAL()的时候只是从堆栈中恢复中断状态。如果用这个方法的话，不管用户是在中断禁止还是允许的情况下调用μC/OS-Ⅱ服务，在整个调用过程中都不会改变中断状态。如果用户在中断禁止的时候调用μC/OS-Ⅱ服务，其实用户是在延长应用程序的中断响应时间。用户的应用程序还可以用OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()来保护代码的临界段。 但是， 用户在使用这种方法的时候还得十分小心，因为如果用户在调用象OSTimeDly()之类的服务之前就禁止中断，很有可能用户的应用程序会崩溃。发生这种情况的原因是任务被挂起直到时间期满，而中断是禁止的，因而用户不可能获得节拍中断!很明显，所有的PEND调用都会涉及到这个问题，用户得十分小心。一个通用的办法是用户应该在中断允许的情况下调用μC/OS-Ⅱ的系统服务!

问题是：哪种方法更好一点?这就得看用户想牺牲些什么。如果用户并不关心在调用μC/OS-Ⅱ服务后用户的应用程序中中断是否是允许的，那么用户应该选择第一种方法执行。

如果用户想在调用μC/OS-Ⅱ服务过程中保持中断禁止状态，那么很明显用户应该选择第二种方法。

给用户举个例子吧，通过执行STI命令在Intel80186上禁止中断，并用CLI命令来允许中断。用户可以用下面的方法来执行这两个宏：

#defineOS_ENTER_CRITICAL()asmCLI

#defineOS_EXIT_CRITICAL()asmSTI

CLI和SCI指令都会在两个时钟周期内被马上执行(总共为四个周期)。为了保持中断状态，用户需要用下面的方法来执行宏：

#defineOS_ENTER_CRITICAL()asmPUSHF;CLI

#defineOS_EXIT_CRITICAL()asmPOPF

在这种情况下，OS_ENTER_CRITICAL()需要12个时钟周期，而OS_EXIT_CRITICAL()需要另外的8个时钟周期(总共有20个周期)。这样，保持中断禁止状态要比简单的禁止/允许中断多花16个时钟周期的时间(至少在80186上是这样的)。当然，如果用户有一个速度比较快的处理器(如IntelPentiumⅡ),那么这两种方法的时间差别会很小。