μ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完全相同,这里不再详述。
栈空间申请了,在哪里释放呢?可以通过修改栈初始化函数OSTaskStkInit,把OSAutoTaskDel地址压入任务栈中。修改前,OSTaskStkInit形成的栈在x86平台上的内容如图1所示。
任务第一次被调度进入运行态时,系统模仿从中断返回,会开始执行用户任务[1]。图1中“任务开始地址”处,理论上应该为任务的返回地址,但在μC/OSII中,任务函数必须为无限循环结构或自销毁形式,不能有返回点。因此,仅仅简单添入任务开始地址,如果用户任务返回,则会有不可预料的后果。修改OSTaskStkInit使栈的内容如图2所示。
此时,用户任务的栈内容与OSAutoTaskDel函数用pdata作参数调用它的栈内容完全相同。所以在用户任务返回时,自动调用OSAutoTaskDel函数,省去了手工调用OSTaskDel的麻烦。在OSAutoTaskDel中,先释放栈空间,之后调用OSTaskDel使该任务进入睡眠态。
结语
本文对μC/OSII中任务的用户接口进行了改善,使之更加方便易用、易于维护,并减少了错误出现的机会。通过以上方法,希望能使μC/OSII为普通嵌入式程序员所接受。
阅读(912) | 评论(0) | 转发(0) |