浅谈uC/OS-II实时操作系统移植的一般方法和技巧

　　引言

　　实时操作系统的使用，能够简化嵌入式系统的应用开发，有效地确保稳定性和可靠性，便于维护和二次开发。

　　u C / O S 是一种公开源代码、结构小巧、具有可剥夺实时内核的实时操作系统，商业应用需要付费。 　　μC/OS-II 的前身是μC/OS，早出自于1992 年美国嵌入式系统Jean J.Labrosse 在《嵌入式系统编程》杂志的5 月和6 月刊上刊登的文章连载，并把μC/OS 的源码发布在该杂志的B B S 上。

　　用户只要有标准的ANSI 的C交叉编译器，有汇编器、连接器等软件工具，就可以将μC/OS-II嵌人到开发的产品中。μC/OS-II 具有执行效率高、占用空间小、实时性能优良和可扩展性强等特点， 内核可编译至 2KB 。μC/OS-II 已经移植到了几乎所有的CPU 上。

　　μC/OS-II是一个基于抢占式的实时多任务内核，可固化、可剪裁、具有高稳定性和可靠性，除此以外，μC/OS-II的鲜明特点就是源码公开，便于移植和维护。

　　在μC/OS-II的主页上可以查找到一个比较全面的移植范例列表。但是，在实际的开发项目中，仍然没有针对项目所采用芯片或开发工具的合适版本。那么，不妨自己根据需要进行移植。

　　在选定了系统平台和开发工具之后，进行μC/OS-II的移植工作，一般需要遵循以下的几个步骤：

　　深入了解所采用的系统

　　分析所采用的C语言开发工具的特点

　　编写移植代码

　　uC/OS-II是一种基于优先级的可抢先的硬实时内核。 　　要实现多任务机制，那么目标CPU必须具备一种在运行期更改PC的途径，否则无法做到切换。不幸的是，直接设置PC指针，目前还没有哪个CPU支持这样的指令。但是一般CPU都允许通过类似JMP,CALL这样的指令来间接的修改PC。我们的多任务机制的实现也正是基于这个出发点。事实上，我们使用CALL指令或者软中断指令来修改PC,主要是软中断。但在一些CPU上，并不存在软中断这样的概念，所以，我们在那些CPU上，使用几条PUSH指令加上一条CALL指令来模拟软中断的发生。

　　在uC/OS-II里，每个任务都有一个任务控制块（Task Control Block），这是一个比较复杂的数据结构。在任务控制快的偏移为0的地方，存储着一个指针，它记录了所属任务的专用堆栈地址。事实上，再uC/OS-II内，每个任务都有自己的专用堆栈，彼此之间不能侵犯。这点要求程序员再他们的程序中保证。一般的做法是把他们申明成静态数组。而且要申明成OS_STK类型。当任务有了自己的堆栈，那么就可以将每一个任务堆栈再那里记录到前面谈到的任务控制快偏移为0的地方。以后每当发生任务切换，系统必然会先进入一个中断，这一般是通过软中断或者时钟中断实现。然后系统会先把当前任务的堆栈地址保存起来，仅接着恢复要切换的任务的堆栈地址。由于哪个任务的堆栈里一定也存的是地址（还记得我们前面说过的，每当发生任务切换，系统必然会先进入一个中断，而一旦中断CPU就会把地址压入堆栈），这样，就达到了修改PC为下一个任务的地址的目的。

　　进行移植的测试针对项目的开发平台，封装服务函数

　　（类似80x86版本的PC.C和PC.H）

　　系统

　　无论项目所采用的系统是MCU、DSP、MPU，进行μC/OS-II的移植时，所需要关注的细节都是相近的。

　　首先，是芯片的中断处理机制，如何开启、屏蔽中断，可否保存前中断状态等。还有，芯片是否有软中断或是陷阱指令，又是如何触发的。

　　此外，还需关注系统对于存储器的使用机制，诸如内存的地址空间，堆栈的增长方向，有无批量压栈的指令等。

　　在本例中，使用的是TMS320C6711 DSP。这是TI公司6000系列中的一款浮点型号，由于其时钟频率非常高，且采用了超常指令字（VLIW）结构、类RISC指令集、多级流水等技术，所以运算性能相当强大，在通信设备、图像处理、医疗仪器等方面都有着广泛的应用。

　　此外，C6711也没有专门的中断返回指令、批量压栈指令，所以相应的任务切换代码均需编程完成。由于采用了类RISC，C6711的内核结构中，只有A0-A15和B0-B15这两组32bit的通用寄存器。

　　C语言开发工具

　　无论所使用的系统是什么，C语言开发工具对于μC/OS-II是必不可少的。

　　上述的这样一些特性，会给嵌入式的开发带来很多便利。TI的C语言开发工具CCS for C6000就包含上述的所有功能。

　　而在此基础上，可以进一步地弄清开发工具的一些技术细节，以便进行之后真正的移植工作。

　　首先，开启C编译器的“汇编代码列表（list）”功能，这样编译器就会为每个C语言源文件生成其对应的汇编代码文件。

　　在CCS开发环境中的方法是：在菜单“/Project/Build options”的“Feedback”栏中选择“Interlisting：Opt/C and ASM（-s）”；或者，也可以直接在CCS的C编译命令行中加上“-s”参数。

　　然后分别编写几个简单的函数进行编译，比较C源代码和编译生成的汇编代码。例如：

　　void FUNC_TEMP （void）

　　{

　　Func_tmp2（）； //调用任一个函数

　　}

　　在CCS中编译后生成的ASM代码为：

　　.asg B15, SP // 宏定义

　　_FUNC_TEMP:

　　STW B3,*SP--（8） // 入栈

　　NOP 2

　　CALL _ Func_tmp2 //-----------

　　MVKL BACK, B3 // 函数调用

　　MVKH BACK, B3 //-----------

　　NOP 3

　　BACK: LDW *++SP（8），B3 // 出栈

　　NOP 4

　　RET B3 // 函数返回

　　NOP 5

　　由此可见，在CCS编译器的规则中，B15寄存器被用作堆栈指针，使用通用存取指令进行栈操作，而且堆栈指针必须以8字节为单位改变。

　　，再编写一个用“interrupt”关键字声明的函数：

　　interrupt void ISR_TEMP （void）

　　{

　　int a;

　　a=0;

　　}

　　生成的ASM代码为：

　　_ISR_TEMP:

　　STW B4,*SP--（8） // 入栈

　　NOP 2

　　ZERO B4 //---------

　　STW B4,*+SP（4） // a=0

　　NOP 2 //----------

　　B IRP // 中断返回

　　LDW *++SP（8），B4 // 出栈

　　NOP 4

　　与前一段代码相比，对于中断函数的编译，有两点不同：

　　函数的返回地址不再使用B3寄存器，相应地也无需将B3入栈。（IRP寄存器能自动保存中断发生时的程序地址）

　　编译器会自动统计中断函数所用到的寄存器，从而在中断一开始将他们全部入栈保护——例如上述程序段中，只用到了B4寄存器。

　　编写移植代码

　　在深入了解了系统与开发工具的基础上，真正编写移植代码的工作就相对比较简单了。

　　μC/OS-II自身的代码绝大部分都是用ANSI C编写的，而且代码的层次结构十分干净，与平台相关的移植代码仅仅存在于OS_CPU_A.ASM、OS_CPU_C.C以及OS_CPU.H这三个文件当中。

　　但是，由于系统、开发工具的千差万别，在实际项目中，一般都会有一些处理方法上的不同，需要特别注意。以C6711的移植为例：

　　中断的开启和屏蔽的两个宏定义为：

　　#define OS_ENTER_CRITICAL（） Disable_int（）

　　#define OS_EXIT_CRITICAL（） Enable_int（）

　　Disable_int和Enable_int是用汇编语言编写的两个函数。在这里使用了控制状态寄存器（CSR）的一个特性——CSR中除了控制全局中断的GIE位之外，还有一个PGIE位，可用于保存之前的GIE状态。

　　因此在Disable_int中先将GIE的值写入PGIE，然后再将GIE写0，屏蔽中断。而在Enable_int中则从PGIE读出值，写入GIE，从而回复到之前的中断设置。

　　这样，就可以避免使用这两个宏而意外改变了系统的中断状态——此外，也没有使用堆栈或局部变量，比原作者推荐的方法要好。

　　任务的切换：

　　前文说过，C6711中没有软中断机制，所以任务的切换需要用汇编语言自行编写一个函数_OSCtxSw来实现，并且

　　#define OS_TASK_SW（） OSCtxSw（）

　　在C6711中需要入栈保护的寄存器包括A0-A15、B0-B15、CSR、IER、IRP和AMR，这些再加上当前的程序地址构成一个存储帧，需要入栈保存。

　　_OSCtxSw函数中，需要像发生了中断那样，将上述存储帧入栈，然后获取被激活任务的TCB指针，将其存储帧的内容弹出，从而完成任务切换。

　　需要特别注意的是，在这里OS_TASK_SW是作为函数调用的，所以如前文所述，调用时的当前程序地址是保存在B3寄存器中的，这也就是任务重新激活时的返回地址。

　　中断的编写：

　　但是，这会导致各种中断发生时，出入栈的内容各不相同。这对于μC/OS-II是会引起严重错误的。因为μC/OS-II要求中断发生时的入栈操作使用和发生任务切换时完全一样的存储帧结构。

　　因此，在移植时、基于μC/OS-II进行开发时，都不应当使用“interrupt”关键字，而应用如下结构编写中断函数：

　　void OSTickISR （void）

　　{

　　DSP_C6x_Save（）； // 服务函数，入栈

　　OSIntEnter（）；

　　if （OSIntNesting == 1） // v2.51版本新增加

　　{

　　OSTCBCur->OSTCBStkPtr

　　=（OS_STK*） DSP_C6x_GetCurrentSP（）； // 服务函数

　　} // 获取当前SP的值

　　// 允许中断嵌套 则在此处开中断

　　OSTimeTick（）；

　　OSIntExit（）；

　　DSP_C6x_Resume（）； // 服务函数，出栈

　　}

　　DSP_C6x_Save和DSP_C6x_Resume是两个服务函数，分别完成中断的出、入栈操作。它们与OS_TASK_SW函数的区别在于：中断发生时的当前程序地址是自动保存在IRP寄存器的，应将其作为任务返回地址，而不再是B3。此外，DSP_C6x_Resume是一个永远不会返回的函数，在将所有内容出栈后，它就直接跳转回到中断发生前的程序地址处，继续执行。

　　进行移植的测试

　　在编写完了所有的移植代码之后，就可以编写几个简单的任务程序进行测试了，大体上可以分三个步骤来进行，相关资料比较详尽，这里就不多作赘述了。

　　封装服务函数

　　这个步骤，往往是容易被忽视的，但对于保持项目代码的简洁、易维护有很重要的意义。

　　μC/OS-II的原作者强烈建议将源代码分路径进行存储，例如本文例子中的所有源代码就应按如下路径结构存储：

　　\uCOS-II

　　├─SOURCE // 平台无关代码

　　│ OS_CORE.C

　　│ ……

　　└─TI_C6711 // 系统

　　├─CCS // 开发工具

　　│ OS_CPU.H

　　│ OS_CPU_A.ASM

　　│ OS_CPU_C.C

　　│

　　├─ DSP_C6x_Service // 服务函数

　　│ DSP_C6x_ Service.H

　　│ DSP_C6x_ Service.ASM

　　│

　　└─ TEST // 具体的开发项目代码

　　OS_CFG.H

　　INCLUDES.H

　　TEST.C ……

　　如上，DSP_C6x_Service中的服务函数，类似于原作者提供的80x86版本中的PC.C和PC.H文件。在本文的例子中，服务函数则包括了上文提及的中断相关函数，以及系统初始化函数DSP_C6x_SystemInit（）和时钟初始化函数DSP_C6x_TimerInit（）等。

　　而具体的开发项目代码，则可以分别在“/TI_C6711”路径下新建自己的目录，就如同移植测试的“TEST”项目，而无需再关注μC/OS-II的源代码和服务函数。

　　如此，就可以避免不必要的编译错误，也便于开发项目的维护。

　　关于μC/OS-II系列软件版权的说明

　　Micrium 公司产品包括μC/OS-II，μC/GUI，uC/FS，μC/TCP-IP，μC/USB等。Micrium 公司提供嵌入式系统应用方面的产品，并对其软件拥有知识产权。Micrium花费了大量的时间和财力为嵌入式领域提供高质量的软件产品。所有上述产品都以源代码的形式提供给客户，具有极大的适用性。

　　开发和研究者可以通过购买Micrium公司的Jean先生的μC/OS-II的书籍，而得到μC/OS-II源代码，但是仅可以作为个人和学校学习使用，所有和μC/OS-II直接和间接相关的商业目的行为，必须购买使用μC/OS-II及系列产品的商业授权，包括芯片/单板/系统厂家的任何参考设计，教学设备和终的产品，如果没有得到Micrium公司Jean先生签字的合法授权都是不合法的使用。

　　Micrium公司其它软件如μC/GUI，μC/FS，μC/TCP-IP，μC/USB 等的销售模式与μC/OS-II不同，如果没有购买使用授权，完全不可以拥有该源代码，也不能将源代码用于产品的设计，培训，教学和生产。

　　μC/OS-II, μC/GUI，μC/FS，μC/TCP-IP，μC/USB 等授权方式有：单个产品、产品线（系列）、按照CPU 划分的产品三种形式，μC/OS-KA，μC/OS-VIEW 等工具是按照使用人的数目收取费用的，相对起传统的RTOS 动辄2-3万美圆的开发费用和每块单板的使用费（根据数量从数百到几个美圆），μC/OS-II及系列产品是采用性的收费方式，应该只是大约相当于传统RTOS 的10-20% 的总体费用。