图5
堆栈单位
　因为处理器现场的寄存器在任务切换时都将会保存在当前运行任务的堆栈中，所以OS_STK 数据类型应该是和处理器的寄存器长度一致的。

图6

堆栈增长方向
　堆栈由高地址向低地址增长，这个也是和编译器有关的，当进行函数调用时，入口参数和返回地址一般都会保存在当前任务的堆栈中，编译器的编译选项和由此生成的堆栈指令就会决定堆栈的增长方向。

图7

宏定义
　包括开关中断的宏定义，以及进行任务切换的宏定义。

图8

2.OS_CPU_C.C 文件
任务堆栈初始化
　这里涉及到任务初始化时的一个堆栈设计，也就是在堆栈增长方向上如何定义每个需要保存的寄存器位置，在ARM 体系结构下，任务堆栈空间由高至低依次将保存着pc、lr、r12、r11、r10、…r1、r0、CPSR、SPSR。

图9
　这里需要说明两点，一是当前任务堆栈初始化完成后，OSTaskStkInit 返回新的堆栈指针stk，在OSTaskCreate（）执行时将会调用 OSTaskStkInit 的初始化过程，然后通过OSTCBInit（）函数调用将返回的sp指针保存到该任务的TCB块中。二是初始状态的堆栈其实是模拟了一次中断发生后的堆栈结构，因为任务被创建后并不是直接就获得执行的，而是通过OSSched（）函数进行调度分配，满足执行条件后才能获得执行的。为了使这个调度简单一致，就预先将该任务的pc指针和返回地址lr都指向函数入口，以便被调度时从堆栈中恢复刚开始运行时的处理器现场。

图10

系统hook函数
　此外，在这个文件里面还需要实现几个操作系统规定的hook函数，如下：
    　OSSTaskCreateHook( )
　    OSTaskDelHook( )
　　OSTaskSwHook( )
　　OSTaskStatHook( )
　　OSTimeTickHook( )
　如果没有特殊需求，则只需要简单地将它们都实现为空函数就可以了。

3.OS_CPU_A.S 文件
　OSStartHighRdy（）
　此函数是在OSStart（）多任务启动之后，负责从最高优先级任务的TCB控制块中获得该任务的堆栈指针sp，通过sp依次将cpu现场恢复，这时系统就将控制权交给用户创建的该任务进程，直到该任务被阻塞或者被其他更高优先级的任务抢占cpu。该函数仅仅在多任务启动时被执行一次，用来启动第一个，也就是最高优先级的任务执行，之后多任务的调度和切换就是由下面的函数来实现。
　OSCtxSw（）
　任务级的上下文切换，它是当任务因为被阻塞而主动请求cpu调度时被执行，由于此时的任务切换都是在非异常模式下进行的，因此区别于中断级别的任务切换。它的工作是先将当前任务的cpu现场保存到该任务堆栈中，然后获得最高优先级任务的堆栈指针，从该堆栈中恢复此任务的cpu现场，使之继续执行。这样就完成了一次任务切换。
　OSIntCtxSw（）
　中断级的任务切换，它是在时钟中断ISR（中断服务例程）中发现有高优先级任务等待的时钟信号到来，则需要在中断退出后并不返回被中断任务，而是直接调度就绪的高优先级任务执行。这样做的目的主要是能够尽快地让高优先级的任务得到响应，保证系统的实时性能。它的原理基本上与任务级的切换相同，但是由于进入中断时已经保存过了被中断任务的cpu现场，因此这里就不用再进行类似的操作，只需要对堆栈指针做相应的调整，原因是函数的嵌套。
　OSTickISR（）
　时钟中断处理函数，它的主要任务是负责处理时钟中断，调用系统实现的OSTimeTick函数，如果有等待时钟信号的高优先级任务，则需要在中断级别上调度其执行。其他相关的两个函数是OSIntEnter（）和OSIntExit（），都需要在ISR中执行。
　ARMEnableInt（）& ARMDisableInt（）
　分别是退出临界区和进入临界区的宏指令实现。主要用于在进入临界区之前关闭中断，在退出临界区的时候恢复原来的中断状态。它的实现比较简单，可以采用方法1直接开关中断来实现，也可以采用方法2通过保存关闭/恢复中断屏蔽位来实现。

我的移植体会
　移植 uC/OS-II 的绝大部分工作都集中在 os_cpu_a.S 文件的移植，这个文件的实现集中体现了所要移植到处理器的体系结构和uC/OS-II 的移植原理；在这个文件里，最困难的工作又集中体现在OSIntCtxSw 和 OSTickISR 这两个函数的实现上。这是因为这两个函数的实现是和移植者的移植思路以及相关硬件定时器、中断寄存器的设置有关。在实际的移植工作中，这两个地方也是比较容易出错的地方。
　OSIntCtxSw 最重要的作用就是它完成了在中断ISR中直接进行任务切换，从而提高了实时响应的速度。它发生的时机是在 ISR 执行到 OSIntExit 时，如果发现有高优先级的任务因为等待的 time tick 到来获得了执行的条件，这样就可以马上被调度执行，而不用返回被中断的那个任务之后再进行任务切换，因为那样的话就不够实时了。
　实现 OSIntCtxSw 的方法大致也有两种情况：一种是通过调整 sp 堆栈指针的方法，根据所用的编译器对于函数嵌套的处理，通过精确计算出所需要调整的 sp 位置来使得进入中断时所作的保存现场的工作可以被重用。这种方法的好处是直接在函数嵌套内部发生任务切换，使得高优先级的任务能够最快的被调度执行。但是这个办法需要和具体的编译器以及编译参数的设置相关，需要较多技巧。
　另一种是设置需要切换标志位的方法，在 OSIntCtxSw 里面不发生切换，而是设置一个需要切换的标志， 等函数嵌套从进入 OSIntExit => OS_ENTER_CRITICAL() => OSIntCtxSw() =>OS_EXIT_CRITICAL() => OSIntExit退出后，再根据标志位来判断是否需要进行中断级的任务切换。这种方法的好处是不需要考虑编译器的因素，也不用做计算，但是从实时响应上不是最快，不过刚开始学习这种方法比较容易理解，实现起来也简单。SkyEye 目前的移植就是基于第二种方法的。
　在中断态下进行任务切换，需要特别说明的一个问题是如何获得被中断任务的 lr_svc 。因为进入中断态后，lr 变成了lr_irq ，原来任务的 lr_svc 无法在中断态下获得，这样要得到 lr_svc ，就必须在中断ISR 里面进行一次 cpu mode 强制转换，即对 CPSR 赋值为0x000000d3 ，只有返回到 svc 态之后才能得到 原来任务的 lr ，这个对于任务切换很重要。还有一个需要留意的问题是在强制 CPSR 变成 svc 态之后，SPSR 也会相应地变成 SPSR_irq ，这样就需要在强制转变之前保存 SPSR ，也就是被中断任务中断前的 CPSR 。
　全部移植代码在SkyEye仿真器上调试通过，在SkyEye的主页上可以下载获得。欢迎大家访问我们的主页 【 http://www.skyeye.org 】。 另外在 Linuxfans.org的论坛上 【http://www.linuxfans.org/bbs/forum-58-1.html 】， 有关于 SkyEye 进展的最新讨论， 和另一个嵌入式开源项目【www.lumit.org 】的大量资料下载， 【 http://www.linuxfans.org/bbs/forum-66-1.html 】。希望大家对我们的工作提出建议和批评，更希望有越来越多的人关注和参与进来。

总结
　移植 uC/OS-II到 SkyEye 上，既是对 uC/OS-II 的学习和实验，同时也是对 SkyEye仿真器的验证和实践。uC/OS-II 作为一个优秀的实时操作系统已经被移植到各种体系结构的微处理器上，也是目前较为常用的公开源码的实时内核。从这里入手学习嵌入式系统开发的基本概念，以及在 SkyEye 里构造一个可以运行的RTOS，能够使我们更深入地了解嵌入式开发的流程，在没有硬件的条件下也能对ARM的体系结构有个初步的认识。
　在移植 uC/OS-II 到 SkyEye 之后，我得到了一块 Samsung 的ARM 评估板，在调通了板子上一些相关硬件（例如串口输出和定时器）的驱动后，仅仅花了不到一天时间就将SkyEye 下的 uC/OS-II 移植到了真实的开发板上，这也说明在 SkyEye 上所做的移植工作是非常有意义和帮助的，完全可以作为嵌入式开发的入门捷径。
　如果大家移植过程中遇到什么问题，欢迎发email和我讨论。