μC/OSII任务创建和销毁的用户接口改善

 就目前而言，μC/OSII[1]称得上是最小的操作系统内核软件。它由Jean J. Labrosse于1992年推出第一版，立刻在嵌入式系统领域引起强烈反响，而其本人也早已成为嵌入式系统会议(美国)的顾问委员会成员。

μC/OS最鲜明特点就是源码公开，便于移植和维护，而且对于学校研究完全免费，只有在应用于盈利项目时才需要支付少量的版权费，特别适合一般使用者的学习、研究和开发。自问世以来，μC/OS的稳定性和可靠性得到了广泛认可，现已通过美国FAA认证，并被众多的研究开发者作为操作系统的样板，移植到各种的硬件平台上。

1 μC/OS任务用户接口的缺点

μC/OSII中任务的用户接口并不友善，与众多程序员熟悉的Windows多任务接口相异较大。

首先，μC/OSII中任务的栈空间完全由用户自行管理，系统只是简单的要求用户创建任务时传入栈地址，而不参与栈空间的申请和释放。为了简化，μC/OS的示例程序以静态数组作为任务栈。栈空间的放任自流在带来一定灵活性的同时也会带来问题。有些用户仿照示例程序，大量以静态数组形式作为任务栈，极大地浪费了嵌入式系统极为珍贵的内存空间;而有些用户在任务开始时申请了栈空间，在任务结束时却忘记释放，造成难以跟踪的内存漏洞。

其次，在μC/OSII中任务结束时，需要手工调用OSTaskDel使该任务进入睡眠态，不能简单的返回。这是因为μC/OSII规定任务必须为无限循环或自销毁形式，而流行的大多数操作系统，任务结束后只是简单的返回，由系统帮助释放任务占据的资源。

2002年，随着我国相关下游产业，包括移动通信、信息家电以及工业控制等领域的快速发展，嵌入式软件产业迎来了极佳的发展时机。强劲的市场需求带来了研发的快速增长，越来越多的软件公司投入到嵌入式产品的研发中。但是国内嵌入式产品的产业现状是，程序员素质在数量上呈现金字塔状况，高级程序员很少，广大对Windows编程熟悉但对嵌入式开发陌生的普通程序员占据金字塔的底端。

若希望在数量庞大的普通程序员中应用μC/OSII，减少Bug产生的来源，那么对其任务接口作出简化处理是必要的。

2 对μC/OS调度算法的改善

本文参考国内程序员很熟悉的Windows多线程接口，对μC/OS任务接口做出改进，增强易用性和用户亲和力。本文在任务创立时帮助用户申请栈空间，并在初始化用户栈时，将任务销毁函数压入栈中，使其能在用户任务返回时自动调用，自动释放栈空间，并调用OSTaskDel使该任务进入睡眠态。

增加接口OSNewTaskCreate和OSAutoTaskDel。OSNewTaskCreate用于创建任务，该函数在系统内核中代替用户申请栈空间，并在初始化栈内容时压入OSAutoTaskDel地址。改进后的OSNewTaskCreate接口如下:

INT8UOSNewTaskCreate(任务地址pThead,参数pData,栈大小dwStackSize，优先级prio);

用户传入需要栈空间的大小(dwStackSize)而不是栈地址，如果dwStackSize为零，则栈空间为系统预设的大小。系统调用OSMemGet在栈内存分区(MemoryPartition)中申请该空间。该栈内存分区在系统初始化时调用OSMemCreate分配，用来统一管理所有的用户栈。接下来的步骤和μC/OS完全相同，这里不再详述。

图1x86平台栈示意图

栈空间申请了，在哪里释放呢?可以通过修改栈初始化函数OSTaskStkInit，把OSAutoTaskDel地址压入任务栈中。修改前，OSTaskStkInit形成的栈在x86平台上的内容如图1所示。

任务第一次被调度进入运行态时，系统模仿从中断返回，会开始执行用户任务[1]。图1中“任务开始地址”处，理论上应该为任务的返回地址，但在μC/OSII中，任务函数必须为无限循环结构或自销毁形式，不能有返回点。因此，仅仅简单添入任务开始地址，如果用户任务返回，则会有不可预料的后果。修改OSTaskStkInit使栈的内容如图2所示。

图2修改后栈示意图

此时，用户任务的栈内容与OSAutoTaskDel函数用pdata作参数调用它的栈内容完全相同。所以在用户任务返回时，自动调用OSAutoTaskDel函数，省去了手工调用OSTaskDel的麻烦。在OSAutoTaskDel中，先释放栈空间，之后调用OSTaskDel使该任务进入睡眠态。

结语

本文对μC/OSII中任务的用户接口进行了改善，使之更加方便易用、易于维护，并减少了错误出现的机会。通过以上方法，希望能使μC/OSII为普通嵌入式程序员所接受。