以下介绍如何将μC/OS-II移植到MOTOROLA MC68K系列CPU上。
一、MC68K CPU简介
MC68K及68020、68040等的著名的MOTOROLA32位微处理器，和与之兼容的68K、CPU32、CPU32+等CPU扩充定时处理单元TPU、队列串行模块QSM、系统控制模块和RAM等组成MC683xx系列单片机。
CPU32内部有8个32位通用数据寄存器，8个32位通用地址寄存器。8个通用数据寄存器可作为累加器使用，也可看成C语言中各种类型的变量;8个通用地址寄存器，可作为变址寄存器使用，也可看成C语言中的指针型变量。CPU32 有独立的用户堆栈指针和系统堆栈指针，可区分程序区、数据区、系统区、用户区等存储空间，有7级中断。
要实现μC/OS-II向MC68K的移值，需要有MC68K的C编译器。我们使用的HIWARE公司的C编译器。该C编译器允许嵌入行汇编。
二、移植中所需修改的文件
和CPU相关的文件主要有三个：C语言文件OS_CPU32.C、头文件OS_CPU32.H和汇编文件OS_CPU32.ASM。
1.INCLUDES.H文件
INCLUDES.H是主头文件，在所有后缀名为.C文件的开始都包含 INCLUDES.H文件。对于不同类型的处理器，用户需要改定INCLUDES.H文件，增加自己的头文件，但必须加在文件末尾。在安装μC/OS- II的时候，附带了几个移植实例，例如，针对Intel 80x86的代码安装到IIL目录。我们为MC68K编写的移植实例都放在II下，在INCLUDES.H文件中增加有：
#include "iiK_CPU32.ASM"
#include "iiK_CPU32.C"
#include "iiK_CPU32.H"
2.OS_CPU32.H文件
OS_CPU32.H文件中定义了与硬件相关的基本信息：
typedef unsigned char INT8U; /*无符号8位数*/
typedef signed char INT8S; /*带符号8位数*/
typedef unsigned int INT16U; /*无符号16位数*/
typedef signed int INT16S; /*带符号16位数*/
typedef signed long INT32S; /*带符号32位数*/
typedef unsigned int OS_STK; /*堆栈入口宽度为16位*/
#define OS_STK_GROWTH1 /*堆栈由高地址向低地址增长*/
#define UCOS 0 /*用于任务切换的软中断*/
define OS_TASK_SW() _TRAP(UCOS)
#define OS_ENTER_CRITICAL() move.w#$2700,SR /*进入临界区*/
#define OS_EXIT_CRITICAL() move.w #$2000,SR /*退出临界区*/
(1)数据类型
由于不同的处理器有不同的字长，μC/OS-II的移植需要重新定义一系列的数据结构。由于MC68K为32位MCU，整数(int)类型数据为16位，长整开有(long)为32位。在MC68K中堆栈都是按字进行操作的，所以堆栈数据类型OS_STK声明为16位。所有的堆栈必须用OS_STK声明。
(2)代码临界区
μC/OS-II在进入系统临界代码区之间要关中断，等到退出临界区后再打开，从而保护核心数据不被多任务环境下的其他任务或中断破坏。在MC68K中，开关中断可以通过设置状态寄存器SR中的中断屏蔽位来实现。μC/OS-II中的宏OS_ENTER_CRITICAL()定义将状态寄存器的中断屏蔽位置位，屏蔽所有的七级中断;OS_EXIT_CRITICAL()定义将状态寄存器的中断屏蔽位清零，打开所有的七级中断。这种处理方法非常简单，但CPU32提供分级中断机制得不到使用。如果要使用分级中断，必须改写一些相关的函数，将在第4节中阐明。
(3)堆栈方向
MC68K处理器的堆栈是由高地址向低地址递减的，所以OS_STK_GROWTH必须设置为1。
(4)OS_TASK_SW()函数的定义
在μC/OS-II中，OS_TASK_SW()用来实现任务切换。就绪任务的堆栈初始化应该模拟一次中断发生后的样子，椎栈中应该按入栈次序设置好各个寄存器。OS_TASK_SW()函数模拟一次断过程，在中断返回的进修进行任务切换。CPU32有16个软中断可供选用，称为陷阱TRAP调用。中断程序程序的入口必须指向汇编函数OSCtxSw()。
我们在μC/OS-II所提供的例程中使用的0号陷阱调用，由下面的语句完成定义：
#define OS_TASK_SW() -TRAP(UCOS)
3.OS_CPU32.ASM文件
μC/OS-II的移植需要用户改写OS_CPU_A.ASM中的4个函数：OSStartHighRdy()、OSCtxSw()、OSIntCtxSw()和OSTickISR()。
(1)OSStartHighRdy()函数
该函数由OSStart()函数调用，功能是运行优先级最高的就绪态任务。在调用OSStart()之前，用户必须先调用OSInit()，并且已经至少创建了一个任务。为启动任务，OSStartHighRdy()首先找到当前就绪的优先级最高的任务，OSTCBHighRdy中保存有优先级最高任务的任务控制块(TCB)的地址，并从任务的任务控制块中找到指向堆栈的指针，然后运行指令MOVEM.L(A7)+，A0-A6/D0-D7，从堆栈中弹出全部寄存器的内容，运行RTE中断返回。由于任务创建时堆栈的结构就是按中断捕捞堆栈结构初始化的，执行RET指令后就切换到了新任务。有关μC/OS-II的任务切换机制，请参考系列计座(3).
OSStartHighRdy的汇编代码如下：
_OSStarHighRdy
MOVE.L(_OSTCBHighRdy)，A1
;获取最高优先级就绪任务的TCB地址
MOVE.L A1，(_OSTCBCur)
MOVE.L (A1)，A7 ;取得堆栈指针
MOVEM.L (A7)+，A0-A6/D0-D7
RTE ;中断返回，切换任务
(2)OSCtxSw( )函数
OSCtxSw( )是一个任务级的任务切换函数(在任务中调用，区别于在中断程序中调用的OSIntCtxSw()，在MC68K系统上，通过执行一条软中断指令来实现任务切换。软中断向量指向函数，而该函数的执行结构可能造成系统任务重新调度(例如，试图唤醒一个优先级更高的任务)，则在函数的末尾会调用 OSSched()，OSSched()将查找当前就绪的优先级最高的任务。如果不是当前任务，则判断是否需要进行任务调度，再找到该任务控制块 OS_TCB的地址，并将该地址拷贝到变量OSTCBHighRdy中，然后通过宠OS_TASK_SW()执行软中断，进行任务切换。在此过程中，变量 OSTCBCur始终包含一个指向当前运行任务OS_TCB的指针。OSCtxSw()的汇编代码如下：
_OSCtxSw
MOVEM.L A0-A6/D0-D7,-(A7) ;存储当前任务环境
MOVE.L (_OSTCBCur)，A1 ;保存当前任务TCB指针
MOVE.L A7，(A1)
MOVE.L (_OSTCBHighRdy)，A1 ;获取最高优先级就绪任务的TCB地址
MOVE.L A1，(_OSTCBCur) ;将就绪任务设置为当前运行任务
MOVE.L (A1)，A7 ;取得新任务的堆栈指针
MOVEM.L (A7)+，A0-A6/D0-D7 ;
RTE ;中断返回，切换任务
(3)OSIntCtxSw()函数
在μC/OS-II中，由于中断的产生可能会引起任务切换，在中断服务程序的最后会调用OSICntExit()函数检查任务就绪状态。如果需要进行任务切换，将调用OSIntCtxSw()，所以，OSIntCtxSw()又称为中断级的任务切换函数。由于在调用OSIntCtxSw()之前已经发生了中断，OSIntCtxSw()默认CPU寄存器已经保存在被中断任务的堆栈了。OSIntCtxSw()的代码与OSCtxSw()的大部分相同，不同之处是：第一，由于中断已经发生，此处不需要再保存CPU寄存器;第二，OSIntCtxSw()需要调整堆栈指针，去掉堆栈中一些不需要的内容，以使堆栈中包含任务的运行环境。
_OSIntCtxSw
ADDA #10，A7 ;忽略掉由于函数嵌套调
;用而压入堆栈的内容
MOVE.L (_CSTCBCur)，A1 ;在TCB中保存当前
;任务的堆栈指针
MOVE.L A7，(A1)
MOVE.L (_OSTCBHighRdy)，A1
;获取最高优先级就绪任务的TCB地址
MOVE.L A1，(_OSTCBCur) ;将就绪任务设备为当前
;运行任务
MOVE.L (A1)，A7 ;取得堆栈指针
MOVEM.L (A7)+，A0-A6/D0-D7 ;
RTE ;中断返回，切换任务
(4)OSTickISR()函数
在μC/OS-II中，当调用OSStart()启动多任务环境后，时钟中断非常重要。在时钟中断中处理所有与定时相关的工作，如任务的延时、等待操作等等。在时钟中断中将查询处于等待状态的任务，判断是否延时结束，以重新进行任务调度。
和μC/OS-II中的其他中断服务程序一样，OSTickISR()首先在被不断任务堆栈中保存CPU寄存器的值，然后调用OSIntEnter()。ΜC/OS-II要求在中断服务程序开头调用OSIntEnter()，其作用是将记录中断嵌套层数的全局变量OSIntNesting加1。如果不调用OSIntEnter()，直接将OSIntNesting加1也是允许的。随垢，OSTickISR()调用OSTimeTick()，检查所有处于延时等待状态的任务，判断是否有延时结束并就绪的任务。在OSTickISR() 的最后调用OSIntExit()，如果在中断中(或其他嵌套的中断)有更高优先级的任务就绪，并且当前中断为中断嵌套的最后一层，OSIntExit()将进行任务调度。注意，如果进行了任务调度，OSIntExit()将不再返回调用者，而是用新任务堆栈中的寄存器数值恢复 CPU现场，然后用RTE实现任务切换。如果当前中断不是中断嵌套的最后一层，或中断中没有改变任务的就绪状态，OSIntExit()将返回调用者 OSTickISR()，最后OSTickISR()返回被中断的任务。
4.OS_CPU32.C文件
μC/OS-II的移值需要用户在OS_CPU32.C中定义6个函数，而实际上需要定义的只有OSTaskStkInit()一个函数，其他5个函数需要声明，
但不一定有实际内容。这5个函数都是用户定义的，所以OS_CPU32.C中没有给出代码。如果用户需要使用这些函数，请将文件OS_CDG.H中的#define constant OS_CPU_HOOKS_EN设为1，设为0表示不使用这些函数。
OSTaskStkInit()函数由任务创建函数 OSTaskCreate()或OSTaskCreateExt()调用，用来初始化任务的堆栈。初始状态的堆栈模拟发生一次中断后的堆栈结构。按照中断后的进栈次序预留各个寄存器的存储空间，而中断返回地址指向任务代码的起始地址。当调用OSTaskCreate()或 OSTaskCreateExt()创建一个新任务时，需要传递的参数是：任务代码的起始地址、参数指针、任务堆栈顶端的地址、任务的优先级。 OSTaskCreateExt()还需要一些其他参数，但与OSTaskStkInit()没有关系。OSTaskStkInit()只需要以上提到的 3个参数：task、pdata、ptos。由于MC68K堆栈是16位宽的(以字为单位)，OSTaskStkInit()将创立一个指向以字为单位的内存区域的指针，同时要求堆栈指针指向空堆栈的顶端。堆栈初始化工作结束后，OSTaskStkInit()返回新的堆栈顶指针，OSTaskCreate()或OSTaskCreateExt()将指针保存在任务的OS_TCB中。
三、移植中的几点注意事项
由于μC/OS-II运行的实时性，调试内核几乎不可能。一旦移植过程中内核运行不稳定，很难确定是什么地方的问题，更困难的是有些现象几乎是不可重复的。这就需要详细了解内核运行机理，认真分析，找出可能存在的问题。下面就来分析这些移植过程中的问题。
1.编译器的优化选项
在移植过程中，除了要熟悉μC/OS-II和目标芯片之外，熟悉使用的C编码器也非常重要。通常C编译器都会提供一些优化代码的选项，在移植μc/OS-II的过程中，这些选项往往会带来麻烦。下面是移植中与HIWARE的C编译器有关的例子。
通常在调用子程序或进入中断时，C编译器会自动保存CPU内部寄存器到堆栈中。例如，在进入中断时编译器会加入下面2条指令：
LINK #$0000，A6;
MOVEM.L D0/D1/D3/D4/D5/D6/D7/A0/A1/A2/A3/A4/A5，-(A7);
这2条汇编指令的作用是将CPU的数据寄存器D0～D7、地址寄存器A0～A5 保存到堆栈中，再将此时的堆栈指针A7也保存到堆栈中，并使用A6作为临时的堆栈指针。这本是一个非常好的优化选项，可以防止在中断中偶然地更改了数据寄存器或地址寄存器;但在μC/OS-II中，这个机制将对OS_CPU_C.C和OS_CPU_ASM.ASM中的几个子程序和中断服务例程产生致命的影响。
OS_CPU_C.C和OS_CPU_ASM.ASM中的子程序中断引发任务调度，当前的任务被挂起。挂起任务是通过下面的语句来完成的：
MOVEM.L A0-A6/D0-D7，-(A7);
MOVE.L @OSTCBCur，A2;
MOVE.L (A2)，A1;
MOVE.L A7，(A1);
保存任务的指针和所有数据地址寄存器的值，那么理想情况下，此时的任务堆栈应该是如图1所示的情况(以OSCtxSw()函数为例，可以对应到OS_CPU_C.C和OS_CPU_ASM.ASM中的其他函数和中断处理例程)。
那么恢复挂起的任务时，只要通过如下语句：
MOVE.L OSTCBHighRdy，A1;
MOVE.L @OSTCBCur，A2;
MOVE.L A1，(A2);
MOVE.L (A1)，A7;
MOVEM.L (A7)+，A0-A6/D0-D7;
将保存在任务TCB中的任务堆栈指针恢复，再恢复数据地址寄存器，最后执行OSCtxSw()的中断返回，就可以顺利地恢复被挂起的任务。
如果C编译器在OSCtxSw()函数入口处插入了2条保存数据地址寄存器和堆栈指针的语句后，再执行挂起任务的语句，任务的堆栈会变成图2所示的情况。编译器引起了堆栈的变化，如果所有的任务都是用这种方式挂起和恢复的，并不会产生致命的问题，因为编码器退出OSCtxSw()函数时会插入如下语句恢复堆栈：
MOVEM.L (A7)+，D0-D7/A0-A5;
UNLK A6;
问题在于初始化任务的时候，每个任务实际上是按照图1所示的堆栈结构被初始化的，那么，按照图2的堆栈结构来恢复自然会导致堆栈崩溃。
解决这个问题的方法很多，可以改定任务初始化的代码以适应C编译器的这个“优化”，也可以在进入OSCtxSw()函数时首先调用如下语句恢复堆栈，抵消C编码器的影响：
MOVEM.L (A7)+，D0-D7/A0-A5;
UNLK A6;
而在退出OSCtxSw()函数前再调用如下语句模拟出更动的堆栈：
LINK #$0000，A6
MOVEM.L D0-D7/A0-A5，-(A7);
较好的方法当然是调整编译器，取消这个优化选项。如果无法调整编译器，就只有用以上办法来适应编译器了。
2.开关中断的方法
在μC/OS-II中，开关中断是非常重要的，它可以保证关键代码或访问全局变量时不受中断的意外影响。CPU32的中断控制比较复杂，提供了7级具有不同级别的中断;可以选择关闭或打开某几级中断。但多级中断会使得μC/OS- II的中断处理变得复杂。在简单的应用或初次尝试移植μC/OS-II时，可以使用全开全关的方法。
如果考虑多级中断，必须注意到中断开关级别的控制是一个重要的信息，在关闭中断之前需要将这个信息保存起来，在对应的开中断时恢复这个中断级别控制信息。最容易想到的方法是用一个全局变量存存这个信息。
使用这个方法的程序如下：
#define OS_EXIT_CRITICAL() asm move SR_TEMP,sr;
#define OS_ENTER_CRITICAL() asm move.w SR,SR_TEMP;
asm ori.w #0x0700,SR;
接着构造两个任务，每个任务分别向屏幕输出一句话，同时修改内核的代码，让空闲任务也输出一句话。运行内核，通常在几分钟内会发现内核停止调试，只有空闲任务不停地向屏幕输出。这种情况非常麻烦，因为根据无法通过调试手段判断何时何处导致内核停止调度。
分析一下，当只有空闲任务运行时，代码为：
move.w sr,sr_temp
ori.w #0700,sr
addi.1 #1,OSIdleCtr
move.w sr_temp,sr
jmp ****
这5句语句在循环运行，而中断(这时只有定时中断)可以在任意一句语句中间切入。那么，如果在MOVE.W SR，SR_TEMP的时候产生了中断，
就会执行中断(因为正要关中断，但还没有关上);而中断程序调用的OSIntENTER和OSIntEXIT都会调用OS_ENTER_CRITICAL()来关闭中断，递增中断嵌套层数全局变量。这时，再次执行MOVE.W SR，SR_TEMP变量就被改写成关中断的值，当从中断返回到IDLE任务执行MOVE.W SR_TEMP，SR时，就关闭了中断，而不是恢复原来的状态寄存器。这样就导致内核无法响应中断，无法调度任务，只有IDLE任务在运行。
如何解决?最容易想到的方法是再增加一个全局变量，用来保存进入中断时的中断开关信息，退出中断恢复这个信息;但如果考虑到中断嵌套，相同的情况又出现了，并且如果一个任务在执行MOVE.W SR，SR_TEMP时被中断打断并且发生了任务调度，那么当个任务恢复时，它使用的中断信息SR_TEMP可以已经是被其他任务更改后的值了。内核无法响应中断，无法调度的任务可能依然存在。
给每个任务和中断都定义一个这样的全局变量，在不考虑中断嵌套的情况下似乎可以解决问题，但想象一下为每一个任务和中断提供一个单独的OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()函数所带来的工作量。显然这不一个好办法。
将中断信息推入堆栈是一个好主意，但我们会看到由此带来的一些更加隐蔽而复杂的问题。实现这个方法的程序代码如下：
#define OS_ENTER_CRITICAL() asm move SR,-(A7);
asm ori.w #0x0700,SR;
#define OS_EXIT_CRITICAL() asm move (A7)+,sr;
这样，每次调用OS_ENTER_CRITICAL()，都将当前的中断开关信息保存到当前任务堆栈或系统堆栈中断OS_EXIT_CRITICAL()时，恢复这个信息。
使用了这个方法后，必须小心地计算堆栈的使用情况，修改 OS_CPU_A.ASM和OS_CPU_C.C文件里的函数。以OSIntCtxSw()函数为例，这个函数将导致中断级的任务调度，即被中断打断的程序不能继续运行，退出中断中另一个优先级更高的任务得以运行。在这个函数中必须对被中断的任务堆栈进行清理，使得这个任务的堆栈看起来和一次正常的任务切换后的情况相同，这样，才能保证这个任务被正确地恢复运行。OSIntCtxSw()函数仅仅在OSICntExit()函数中被调用。
须指出的是，在中断发生时，CPU32已经将全部的寄存器和状态寄存器，PC指针内容保存到了堆栈中，这样已经为被打断的任务的恢复作好了准备。如果按照正常的中断流程，在退出中断时，被打断的任务应该恢复运行。现在，由于执行了中断级的任务切换，被打断的任务不能立刻恢复，而是被挂起，这就要求在执行任务调度前调整堆栈，使得被中断打断的任务处于随时可以被恢复的状态。
在中断处理程序中，当执行到OSIntExit()时，堆栈的情况和刚刚进入中断还是相同的，是能够随时恢复被打断的任务的情况。那么，只需要忽略OSIntExit()函数造成的堆栈变化。首先，是OSIntExit()函数本身的返回地址，长度为2个字;调用OS_ENTER_CRITICAL()压入堆栈的状态寄存器，长度为1个字;最后，是OSIntCtxSw()函数的返回地址，长度为2个字。那么在OSIntCtxSw()进行任务切换时，首先要把这5个字的堆栈的内容清除，才能保证被中断任务的正确恢复。该语句如下：
ADDA #10，A7;
在完成了这些调整后，由于开关中断可能导致的内核调度死锁的可能已经不存在了。但是在这种情况下，另一个更加隐蔽的问题会出现，这个问题又是和使用的C编码器相关的。
问题出现在使用OSSemPend()函数时，一旦调用这个函数，CPU就会出现地址错误而进入异常处理，内核被终止。这个问题相当奇怪，因为，OSSemPend()函数完全是一个C语言写成的子函数，函数本身不应出现地址错误。通过阅读编译器编译出来的目标码发现了问题。EmPend()函数，发现这个函数没有任何局部变量。在进入OSSemPend()函数时，编译器不需要产生LINK指令来提供局部变量空间。所有的参数都是使用带偏移量的地址寄存器间接寻址方式直接从堆栈中取得，而且使用的地址寄存器就是A7寄存器。问题可能就在这里，OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()对堆栈的操作都会调整A7寄存器，这就会导致下面的语句在利用A7作寄存器间接寻址时发生错乱，出现地址错误。
这需要详细研究编译器的特性。我们使用的HIWARE的编译器实际上已经考虑到了这一点，当调用OS_ENTER_CRITICAL()或OS_EXIT_CRITICAL()函数更加了A7寄存器后，使用A7的地址寄存器间接寻址也会做出相应的调整，保证仍然能够得到函数调用时传递的变量。每出现一个OS_ENTER_CRITICAL()，接下来的A7寄存器间接寻址的偏移量就会加2;每出现一个OS_EXIT_CRITICAL()，接下来的A7寄存器间接寻址的偏移量就会减2。但是问题却依然存在，对OSSemPend()的调用会导致地址错误，这应该是一个更深层次的错误。
这个问题的解决方法是：定义一个局部变量，迫使编译器生成LINK指令，构造内部参数寻址指针A6，这样调用OS_ENTER_CRITICAL()或OS_EXIT_CRITICAL()时，更动的只是A7，而对参数寻址用的是A6，不受影响。
如果强迫编译器在调用函数时都加上LINK和UNLINK指令也可以解决这个问题，但是又会面临最先提到的编译器的优化选项问题。可以看出，编译器的特性对移植μC/OS-II是非常重要的，并且往往这些特性是相互制约的。
在移植和运行μC/OS-II的过程中，也许还会有新的问题出现，遇到问题时只要仔细分析，分析堆栈的使用、中断的影响，分析编译生成的代码，就可以实现μC/OS-II的稳定可靠运行。