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

发布: 2009-4-23 22:53 |  作者: 刘斌 李仲阳 |   来源: 嵌入式技术网 |  查看: 53次

就目前而言，μ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完全相同，这里不再详述。

 

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

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

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

结语

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