ucos-ii在ARM7上移植

  随着嵌入式技术的快速发展，实时多任务操作系统作为一种软件平台已逐步成为国际嵌入式系统的主流，目前世界上已经有一大批成熟的实时嵌入式操作系统，通常，对嵌入式软件的基本要求是体积小、指令速度快、具有较好的裁减性和可移植性，目前，实时操作系统很多，如 VxWorks ， Windows CE ， pSOS ， QNX ， LynxOS 等，这些操作系统都具有高可靠性、强实时性等特点，但他们都是商业操作系统，价格昂贵，人们往往很难接受， μC/OS- Ⅱ 操作系统的出现是对这些商业操作系统的一个很大的冲击。

1 μC/OS- Ⅱ 操作系统简介

μC/OS- Ⅱ 是源码公开的实时操作系统，是一个自由操作系统。程序开发人员可以改写源代码，使之符合自己的要求，裁减掉不需要的部分，使操作系统变得小巧、灵活、并且能满足用户特定操作系统的需要。为了提高系统的实时能力， μC/OS- Ⅱ 可以将一个复杂的应用划分为多个相互独立的任务，并根据任务的重要性来分配优先级。任务的调度完全由 μC/OS- Ⅱ 的实时内核完成，主要包括任务的状态管理、选择最高优先级的任务、执行任务和撤销任务等， μC/OS- Ⅱ 内核还负责 CPU 时间分配， CPU 时间总是优先分配给中断事件，其次是任务队列中当前优先级最高的任务，不同任务间的通信可以通过 μC/OS- Ⅱ 提供的信号量、邮箱、信息队列等机制完成，他的绝大部分代码是用 C 语言编写的，可移植性强，因此 1997 年以后，在国际上逐渐被广泛采用。

2 其软硬件体系及可移植性分析

μC/OS- Ⅱ 核心代码很小，程序开发人员要把他移植到自己的目标板中只需做少量的工作。图 1 是基于 μC/OS- Ⅱ 的嵌入式系统的软硬件体系结构。

虽然 μC/OS- Ⅱ 大部分源代码是用 C 语言写的，但是完成和处理器有关的代码时，还是用汇编语言来实现的，由图 1 可以看出， μC/OS- Ⅱ 的移植的主要工作是修改与处理器相关部分的代码 ，他们集中在 3 个文件中，其中， OS_CPU.H 包含与处理器相关的常量、宏和结构体的定义； OS_CPU_C.C 和 OS_CPU_ASM 中定义了用于底层的任务切换，退出中断服务程序，在 CPU 级屏蔽中断、打开中断、对任务栈初始化以及时钟的中断服务程序的函数等，为了使应用程序运行于 μC/OS- Ⅱ 上，还要相应地修改应用中使用的硬件和设备驱动。

3 μC/OS- Ⅱ 的移植工作

3.1 与应用相关的代码

这一部分是用户根据自己的应用系统来定制合适的内核服务功能，包括 2 个文件： OS_CFG.H 和 INCLUDES.H 。

OS_CFG.H 用来配置内核，用户根据需要对内核进行修改，留下需要的部分，去掉不需要的部分，比如系统可提供的最大任务数量，是否定制邮箱服务，是否提供优先级动态改变功能等等，所有的配置更改包括头文件的增减均在该文件中进行。

INCLUDES.H 系统头文件，整个实时系统程序所需要的文件，包括了内核和用户的头文件，这样使得用户项目中的每个 .C 文件不用分别去考虑他实际上需要哪些头文件。

3.2 与处理器相关的代码

这是移植中最关键的部分。内核将应用系统和底层硬件有机地结合成一个实时系统，要使同一个内核能适用于不同的硬件体系，就需要在内核和硬件之间有一个中间层，这就是与处理器相关的代码，处理器不同，这部分代码也不同，我们在移植时需要自己处理这部分代码，在 μC/OS 中这一部分代码分成 3 个文件： OS_CPU.H ， OS_CPU_A.ASM ， OS_CPU_C.C 。

3.2.1 OS_CPU.H

包含了用 #define 定义的与处理器相关的常量、宏和类型定义，具体有系统数据类型定义、栈增长方向定义、关中断和开中断定义、系统软中断的定义等。

（ 1 ）不依赖于编译的数据类型

μC/OS- Ⅱ 不使用 C 语言中的 short ， int 和 long 等数据类型的定义，因为他们与处理器类型有关，隐含着不可移植性，代之以移植性强的整数数据类型，这样，既直观又可移植。根据 ADS 编译器的特性，代码为：

typedef unsigned char BOOLEAN ；
typedef unsigned char INT8U ；
typedef signed char INT8S ；
typedef unsigned short INT16U ；
typedef signed short INT16S ；
typedef unsigned int INT32U ；
typedef signed int INT32S ；
typedef float FP32 ；
typedef double FP64 ；
typedef INT32U OS_STK ；
（ 2 ）使用软中断 SWI 做底层接口

因为带 T 变量的 ARM7 处理器核具有两个指令集，用户任务可以使用两种处理器模式，为了使底层接口函数与处理器状态无关，同时在任务调用相应函数时不需要知道该函数位置，本例使用软中断指令 SWI 作为底层接口，使用不同的功能号区分不同的函数，其 SWI 服务函数代码为：

（ 3 ） OS_STK_GROWTH

μC/OS- Ⅱ 使用结构常量 OS_STK_GROWTH 指定堆栈的生长方式，其代码为：

#define OS_STK_GROWTH 1

3.2.2 OS_CPU_C.C

包含了与移植有关的 C 函数，包括堆栈的初始化和一些钩子函数的实现，但是 最重要的是 OSTaskStkInit （）函数，该函数是在用户建立任务时系统内部自己调用的，用来对用户任务的堆栈初始化 。在 ARM7 体系结构下，任务堆栈空间由高至低递减，依次保存着 PC ， LR ， R12 ， … ， R1 ， R0 ， CPSR 的初始化堆栈结构，当用户初始化了堆栈， OSTaskStkInit （）就返回新的堆栈指针 STK 所指的定地址。 OSTaskCreate （）和 OSTaskCreateExt （）会获得该地址并将他保存到任务控制块 TCB 中，其他的几个钩子函数必须声明，但可以不包含任务代码，这些钩子函数在本移植中全为空函数。
3.2.3 OS_CPU_A.S

μC/OS- Ⅱ 移植的绝大部分工作都集中在 OS_CPU_A.S 文件的移植上，在这个文件里，最困难的工作又集中体现在 OSIntCtxSw 和 OSTickISR 这两个函数的实现上。这是因为这两个函数的实现是和移植者的移植思路以及相关硬件定时器、中断寄存器的设置有关，在实际的移植工作中，这两个地方也是比较容易出错的地方，这部分需要对处理器的寄存器进行操作，所以必须用汇编语言编写，包括 4 个子函数： OSStartHighRdy （）、 OSCtxSw （）、 OSIntCtxSw （）、 OSTickISR （）。

OSStartHighRdy （）该函数首先调用钩子函数 OSTaskSwHook （），然后将 OSRunning 标志位设置为真，表示任务开始执行，从而保证任务切换操作的正确执行，紧接着从具有最高优先级的任务控制块中取得任务的堆栈指针，初始化堆栈指针寄存器 SP ，然后恢复其他的寄存器，开始执行最高优先级的任务。

OSCtxSw （）该函数在任务级任务切换函数中调用，首先保存处理器寄存器，将当前 SP 存入任务 TCB 中，载入就绪最高优先级任务的 SP ，从新任务的任务堆栈中恢复处理器所有寄存器的值，然后执行中断返回指令。

OSIntCtxSw （）该函数是在 ISR 中执行任务切换功能，其原理基本上与任务级的切换相同，区别只是 ISR 已经保存了 CPU 的寄存器，因此不要再进行类似的操作，只需对堆栈指针作相应的调整即可。

OSTickISR （）该函数是系统时钟节拍中断服务函数，首先要保存处理器寄存器，接着调用 OSIntEnter （）函数，以保证中断嵌套层数不超过 255 层，如果满足了该条件，则把堆栈指针保存到当前任务的任务控制块 TCB 中，然后给产生中断的设备清中断，重新允许中断，接下来调用 OSTimeTick （）来维持 μC/OS- Ⅱ 内部的定时以及调用 OSIntExit （）函数决定是否因为这个中断服务程序的执行，使得更高优先级的任务就绪。

4 μC/OS- Ⅱ 的测试

做完移植工作以后，就要测试移植是否正确，这其实是移植过程的最后一步，应该首先不加任何用代码来测试移植好的 μC/OS- Ⅱ ，即应该首先测试内核自身的运行状况，这样做的目的是如果有些部分未能正常工作，那就是移植本身的问题，而不是应用代码产生的问题，主要分为以下几个步骤来进行移植的测试：

首先，必须了解处理器所使用的编译器系统，这个步骤取决于使用的编译器，在这期间是无代码的测试，其次，要验证 OSTaskStkInit （）和 OSStartHighRdy （）函数，在 OS_CFG.H 文件中设置 OS_TASK_STAT_EN 为 0 ，只让一个空闲任务 OS_TaskIdle （）运行，检查是否出错，然后需要验证任务级切换 OSCtxSw （）函数，在测试任务 TaskTest （）中加入 OSTimeDly （）函数， OSTimeDly （）函数接着调用 OS_Sched （）， OS_Sched （）调用汇编语言编写的函数 OSCtxSw （）函数，如果是正确配置了 SWI ， CPU 就会开始执行 OSCtxSw （），最后，需要验证 OSIntCtxSw （）和 OSTickISR （）函数。

当上述的这些测试步骤都成功后，可以尝试运行一些具体的任务，按照由简到繁的过程不断使测试变得复杂，来进一步验证内核的稳定性和系统性能。

这里建立了一个简单的 LED 灯闪烁控制任务，其代码如下：

加载后， LED 灯闪烁控制正常，则测试成功，内核正常运转，若测试出现问题，就要认真找出问题所在，不可忽略硬件的问题，还有编译器等，当然也可以采用其他的测试，如串口的测试等。

5 结语
以上所述为 μC/OS- Ⅱ 在 ARM7 上移植的通用方法，但针对不同的处理器还需要作适当的修改， RTOS 是当今嵌入式应用的热点，应用 RTOS ，可以提高产品的可靠性，降低研发周期，其中 μC/OS- Ⅱ 具有很好的实时性和很小的代码量，占用空间少，执行效率高，移植方法相对简单，因此掌握 μC/OS- Ⅱ 的移植方法是相当重要的。