SkyEye仿真调试器是基于ARM7TDMI 核的，因此移植 uC/OS-II 到 SkyEye 上可以借鉴网上已有的例如 Sansung S3C3410X的移植代码，这在 uC/OS-II的主页上很容易找到。 当然自己动手做移植也是对 ARM 体系结构和汇编语言的进一步熟悉，同时对于 uC/OS-II 内核的调度机制会有更深的认识。
整个移植工作可以分为两个方面，一部分是和 ARM 相关，一部分是和移植原理相关。在开始实际的移植工作前，需要对这两部分有一定的背景知识，尤其是和侧重于和移植工作相关的概念和原理，下面分别做一些介绍。
ARM的体系结构
ARM（Advanced RISC Machines）是目前在嵌入式领域里应用最广泛的RISC微处理器结构，以其低成本、低功耗、高性能的特点占据了嵌入式系统应用领域的领先地位。ARM系列的处理器当前有ARM7、ARM9、ARM9E、ARM10等多个产品，此外ARM公司合作伙伴，例如Intel 也提供基于XScale微体系结构的相关处理器产品。所有的ARM处理器都共享ARM通用的基础体系结构，所以开发者在不同的ARM处理器上做操作系统移植时，可以将节省相当多的工作量，这无疑将大大降低软件开发成本。
要详细完整的了解ARM的体系结构，当然是去读 ARM Architectur Reference Manual ，这是一个13M 的pdf 文档，有800多页，可以从ARM的网站下载，也可以到北京亚嵌教育研究中心的FTP服务器( http://www.akae.cn/ftp/ )上找到。北航出的一本《ARM 嵌入式处理器结构与应用基础》基本上翻译了这个pdf中大部分重要的内容，可以作为入门的中文教材。这里我们仅仅对其中和移植工作密切相关的概念做简要介绍。
1.处理器模式： ( cpu mode )
ARM 的处理器可以工作在 7 种模式，如图1所示。
图1
这里除 usr 模式以外的其他模式都叫做特权模式，除 usr 和 sys 外的其他5种模式叫做异常模式。在 usr 模式下对系统资源的访问是受限制的，也无法主动地改变处理器模式。异常模式通常都是和硬件相关的，例如中断或者是试图执行未定义指令等。这里需要强调的是和移植相关的两种处理器模式：svc态和 IRQ 态，分别指操作系统的保护模式和通用中断处理模式。这两种模式之间的转换可以通过硬件的方式，也可以通过软件的方式。uC/OS-II内核在执行过程中，大部分时间都是工作在 svc 态，当有硬件中断，例如时钟中断到来时，cpu 硬件上会自动完成从svc态进入 irq态，在中断处理程序的结束处，则需要通过编程的方法使得 cpu 从irq 态恢复到 svc 态，这个在移植代码中可以找到。
2.程序状态寄存器： ( PSR：Program status register )
在任何一种处理器模式中，都使用同一个寄存器来标识当前处理器的工作模式：这个寄存器叫做CPSR ( Current Program Status Register )，它的 [0--4] 位用来表示cpu mode，如图2、图3所示。
图2
图3
3.ARM寄存器：( register )
ARM处理器一共有37个寄存器，其中31个是通用寄存器，包括一个程序计数器 PC。另外6个就是上面提到的程序状态寄存器。
a）通用寄存器：
i.R0－R7：与所有处理器模式无关的寄存器，可以用作任何用途。
ii.R8－R14：与处理器模式有关的寄存器，在不同的模式下，对应到不同的物理寄存器。其中 R13又叫做 sp，一般用于堆栈指针。R14又叫做lr，一般用于保存返回地址。这两个寄存器在每种异常模式下都对应到不同的物理寄存器上，例如lr_irq、lr_svc、lr_fiq 等。
iii.R15：又叫做程序计数器，即pc，所有的模式下都使用同一个 pc。
b）状态寄存器：
i.CPSR：当前程序状态寄存器，所有的模式下都使用同一个 CPSR。
ii.SPSR：保存的程序状态寄存器，每种异常模式下都有自己的SPSR，一共有5种SPSR，即SPSR_irq、SPSR_fiq、SPSR_svc、SPSR_abt、SPSR_und。usr和sys 态下没有 SPSR 。
所有的ARM寄存器的命名和含义，可以用下面的这张表来说明，其中相同命名的都是同一个物理寄存器，不同命名的寄存器都对应不同的物理寄存器，如图4所示。
图4
uCOS-II 移植工作介绍
uCOS-II 实际上可以简单地看作是一个多任务的调度器，在这个任务调度器之上完善并添加了和多任务操作系统相关的一些系统服务，如信号量、邮箱等。它的90%的代码都是用C语言写的，因此只要有相应的C语言编译器，基本上就可以直接移植到特定处理器上，这也是uC/OS-II具有良好的可移植性的原因。移植工作的绝大部分都集中在多任务切换的实现上，因为这部分代码主要是用来保存和恢复处理器现场（即相关寄存器），因此不能用C语言，只能使用特定的处理器汇编语言完成。
uCOS-II的全部源代码量大约是6000－7000行，一共有15个文件。将 uC/OS-II 移植到ARM处理器上，需要完成的工作也非常简单，只需要修改三个和ARM体系结构相关的文件，代码量大约是500行。以下分别介绍这三个文件的移植工作：
1.OS_CPU.H 文件
数据类型定义
这部分的修改是和所用的编译器相关的，不同的编译器会使用不同的字节长度来表示同一数据类型，比如int，同样在x86平台上，如果用GNU的gCC 编译器，则编译为4 bytes，而使用MS VC＋＋则编译为2 bytes。我们这里使用的是 GNU 的 arm-elf-gcc，这是一个免费并且开放源码的编译器。相关的数据类型的定义如下，如图5所示。
www.55dianzi.com
图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。该函数仅仅在多任务启动时被执行一次，用来启动第一个，也就是最高优先级的任务执行，之后多任务的调度和切换就是由下面的函数来实现。
本文关键字：暂无联系方式嵌入式系统-技术，单片机-工控设备 - 嵌入式系统-技术
