日志
OS初探及μC/OS-II移植
||
作者：yuyixuantai 首发：21ic 系列：OS探究1
从最简约的角度来考虑操作系统（OS），并暂时忽略OS相关的一系列相关的概念，那么原本复杂的OS将不在神秘，它的实现以及移植将不是一件困难的事情，无论是在时间上还是技术上。
我们最简单的OS实现是在在几个任务之间自由的跳转运行。而最简单的任务可以最简化为一个while(1)死循环，当自己的代码能够在从一个死循环中跳到另一个并行的死循环中，并在恰当的时候的跳转回来，从刚才跳开的断点上重新开始运行，那么一个OS的雏形就出来了。
这是非常简单的想法。它实现的难易程序跟我们的硬件环境系统和编程语言有关。幸运的是，我们能够很轻松的找到这样的环境。C语言是首选，它的系统设计上的优越性几乎无可比拟，而对于硬件环境，我们可以使用单片机或者与相类似的ARM，DSP等处理器，甚至我们可以使用一种模拟环境，只需是UV2或者VC这样的IDE就可以了——只要我们的选择满足这样的条件就可以：提供C语言程序运行的现场环境（通常是所有的寄存器）以及至少一个中断（这是实现任务调度的前提）。VC中可以使用定时器等实现来替代。
我选择的是台湾Sunplus公司的61系列的16位IC－SPL2002，它简单而便宜，共拥有16个寄存器，我们总是而且只是使用前8个(R1-R5,SP,BP,SR,PC)，在任务初始化的的时候，核心任务是对这8个寄存器进行初始化并予以保存，而在任务切换的时候，其核心任务是保存当前的现场环境（即保存寄存器个寄存器的值），然后切换至另一个任务的现场环境（恢复被保存起来的所有寄存器值）。对寄存器的操作采用汇编或者嵌入式汇编语言。任务切换在中断中进行操作。这些的实现非常的简单，值得关注的是进入中断的前后现场环境和堆栈所发生的变化。
这种，OS雏形可以在几分钟之内建立起来。然而，后面的任务将变得的令人犯难，定义关于任务（现在应该为进程）的数据结构，对进程进行调度，进程之间进行通信，都可以一种简约的形式来实现，但在简约之后要达到合理和稳定可不容易。我们需要细致的思考和探究，这时候，移植并参考一款成功的OS是更好的选择。开放源代码的μC/OS-II实在是令人激动－足够稳定而且允许学习的时候完全免费。
以下是我对μC/OS-II的移植报告，它写与几个月前，前前后后花了我两天多近24个小时的时间。令人郁闷的是，其中的大部分时间用在了比较各版本的代码和写总结上。
//============================================================================
//移植报告 (开始)
//============================================================================
1.关于我的移植环境。我使用的MCU是GPL2002，IDE是u'nSP2.4.0，移植的版本uc/OS2是2.00和2.61以及最新的2.84(之所以同时移植这几个版本是因为在阅读代码的时候发现他们之间差别比较大)。
2.需要编译的文件。2.00版需要编译source下的所有.c文件，所以要将所有的.c文件都加入项目中，而2.61和2.84中有一个uCOS_II.C文件，它包含了所有的.c文件，只需要编译它即可，如果此时不是加入除uCOS_II.C之外的其他c文件，则可能导致重复定义的错误。
3.关于最新版本。我拿到的是2.84，其中的头文件包含方式做了改动，以前诸如#include "os_cpu.h"之类都改成了#include <os_cpu.h>，有些编译器可能是只搜索系统路径(我使用的编译器原理便是如此)，这就需要改回#include "os_cpu.h"，使编译器搜索当前路径。源代码的dbg处理有冲突，ucos_ii.c文件中并没有包含os_dbg.c，但OS_DEBUG_EN埆被定义为1，处理的方法定义OS_DEBUG_EN为0，要么自己将os_dbg.c包含进ucos_ii.c。在os_tmr.c中
作者提示
* 1) Your application MUST define the following #define constants:
*
* OS_TASK_TMR_PRIO The priority of the Timer management task
* OS_TASK_TMR_STK_SIZE The size of the Timer management task's stack
实际是上你只需要定义OS_TASK_TMR_PRIO即可。
4.关于找不到的文件。你可以中找不到os_dbg.c，os_cfg.h，将对应的os_dbg_r.c以及os_cfg_r.h中改名字就是。同时自己需要创建app_cfg.h文件，或者注释掉对它的包含。
5.关于移植代码相关硬件工作。移植前需要对自己的编译器和MCU做如下了解。基本类型的长度，堆栈的生长方向，如何启动时间中断，如何使用C语言打开和关必中断，如何获得函数的地址，如何完整的保存现场(编译器使用的所有寄存器)和恢复现场，中断和函数调用的以及他们返回时对于现场的影响。提前编写一些小函数测试他们不需要多少时间但非常有用。
6.需要重点注意的几个函数。OSTaskStkInit，需要模拟一个首次调用函数的现场环境，我使用的16位MCU用到的寄存器为r0－r7，其中r0作为sp，为栈顶，函数调用时需要将函数的段地址和偏移地址分别提供给r6(sr),r7(pc)所以模拟的如下：
OS_STK *OSTaskStkInit(void (*task)(void *pd), void *pdata, OS_STK *ptos, INT16U opt)
{//john modified 2008-01-02
OS_STK* stk;
opt = opt;
stk = (OS_STK*)ptos;
//*stk-- = (int)ptos; /* bp */
*stk-- = OSFunPtGetOff(task); /* pc */
*stk-- = OSFunPtGetSeg(task); /* sr */
*stk-- = (int)ptos; /* bp */
*stk-- = 0x0000; /* r4 */
*stk-- = 0x0000; /* r3 */
*stk-- = 0x0000; /* r2 */
*stk-- = 0x0000; /* r1 */
return (void *)stk; /* sp */
}
需要切换至此任务的时候(OSStartHighRdy)，将stk值赋予sp，将系统堆栈切换为当前任务堆栈， 然后将r1-r5依次弹出堆栈，初始化现场，再次弹出sr和pc，便进入函数的入口处。
OSCtxSw，OSIntCtxSw处理相似，保护当前现场，然后切换至最高优先级的任务。处理比较简单，唯一麻烦的是OSIntCtxSw从中断进入，完美只需要保存中断前的现场即可，从中断到OSIntCtxSw之间会有多余的压栈，所以在中断的时候需要将任务栈顶保存下来，此时在付给sp即可。做到这一步，已是万事大吉，可以享受几个任务起跑的喜悦了。
7.顺便抱怨两句，越新的版本，移植起来居然越费事，同时，写总结真的，真的很累。
//============================================================================
/移植报告 (结束)
//============================================================================
无论μC/OS-II拥有这样的声誉和评价，我们仅仅从我需要的角度来探究一些问题。OS的以下几个方面令我们非常兴奋：
1.内存管理。作为一种稀缺资源，内存非常的有限，但很多系统上我们可以申请远多于真实内存的可用内存。
2.程序空间。多个任务会被读入有限的内存空间之内，却互不冲突。（当然，很多单片机上面并没有实现这一点，但它们现在正在实现，我们自己也可以试着实现。
3.文件系统。文件系统方便了对大容量存储设备的操作。而虚拟文件系统几乎具备神奇的作用。
4.输入/输出管理。键盘，鼠标，屏幕，磁盘，网卡之类都变得顺手可用。
然而，审视μC/OS-II以及我们此刻的实现，这些问题我们都没有解决。（1）此刻并没有虚拟内存，而μC/OS-II上的内存管理仅仅是申请和释放固定的块，尽管这的确可以如作者所说的避免内存碎片的出现，但也带来极大的使用局限。（2）程序空间仅仅是并行堆叠。μC/OS-II上的可以确定堆栈大小，但是但是堆栈的并行排列实在是制约很大。（3）文件系统，并没有涉及到。（4）输入/输出管理目前并不存在。
这些等实现的功能涉及到设备驱动以及其他比较复杂的技术。我们只能另起文章来探究它们。这里，对于OS，我们完成了初探，而初探，仅仅是开始而已。 （完）
04/13/2008
