嵌入式实时操作系统PetOS设计与实现

1 引言

在嵌入式领域中，嵌入式实时操作系统正得到越来越广泛的应用。采用嵌入式实时操作系统(RTOS)可以更合理、更有效地利用CPU 的资源,简化应用软件的设计,缩短系统开发时间,更好地保证系统的实时性和可靠性。由于RTOS需占用一定的系统资源(尤其是RAM 资源),只有μC/OS II、PalOS等少数实时操作系统能在小RAM 系统上运行。相对于μC/OS II[2]等商业操作系统,PalOS[1]操作系统是完全免费的操作系统,具有源码公开、内核简单等的特点。但该系统不支持任务优先级、中断等相对复杂的功能，不能很好的满足嵌入式电子设备的需要。

2 PetOS简介

PalOS是UCLA（加州大学洛山机分校）为传感器网络而设计微型操系统。系统轮询每个任务的消息队列，如果存在消息则调用任务相应的消息处理函数。但是这种简单的轮询机制和系统结构无法满足更为复杂的应用需求。在任务管理、系统时钟管理和中断管理等功能上,PalOS的功能都有待加强。

PetOS以PalOS为原型，改进了任务调度算法，引入优先级的概念。每个任务可根据重要程度的不同被赋予一定的优先级, CPU总是让处于就绪态的、优先级最高的任务先运行，从而实现任务的优先级管理。PetOS还提供了严格优先级调度模式和非严格优先级调度模式，用于缓解高优先级任务持续被调度时，低优先级任务出现‘饿死’的现象。

图1 PetOS内核框架

简单轮询或者优先级调度都无法保证系统的实时性。这两种调度都基于事件驱动，任务必须完成事件响应才会执行下一轮调度，因此系统的实时性会受到事件响应函数的粒度的影响，为了增加系统的实时性，PetOS加入了中断管理及系统时钟管理，用于提高系统的实时性。中断可以由硬件产生，也可以由应用程序产生。中断产生后，系统会及时进入中断模式进行处理，从而保证实时性要求很高的事务能得到及时的处理。

PetOS内核框架如图1。

3 PetOS的实现

3.1 PETOS任务维护/调度模块

任务维护/调度模块是PetOS的核心模块 负责任务的管理和调度。

·TASK（任务）:

TASK是PetOS应用程序的逻辑实体，拥有独立的输入响应、消息响应和输出控制，是PetOS的调度实体。

PetOS任务具有如下5个状态：

·UNREGISTER   ：由于Task列表采用静态数组，此状态表示该数组项无效

·UNINIT：任务已经注册，但是尚未初始化，不可执行

·STOP：任务停止状态。不接受消息，不可执行。无数据

图2 PetOS 任务状态转换图

·RUN：任务运行状态。能接受消息，可以执行

·PAUSE：任务挂起状态：不能接受消息，不可执行。但保持数据。

任务在PetOS启动时被注册，并常驻在操作系统中。即操作系统初始化完毕并启动之后，操作系统调度的任务列表是固定的。操作系统启动后，任务只会在运行、暂停、挂起状态之前切换。

任务状态图如图2：

为了方便任务的管理与控制，每个TASK都会绑定TCB（task control block）。TCB类似于现代操作系统中进程的PCB，它记录了task的各种状态变量、控制变量以及标准接口的函数指针，便于PetOS和应用程序维护。

Event(事件消息):

Event是PetOS进程调度的粒度单位。

由于PetOS的每个任务不具备独立的代码/数据段/堆栈指针，我们无法在任意的位置暂停一个task而启动另一个。PetOS的解决策略是：将 task拆分成为一个个独立的由事件驱动的逻辑模块，每个task都有各自独立的事件队列。Task的每个逻辑功能都会被映射成一个事件，操作系统通过赋予某个task响应事件的权利来完成一次调度。而操作系统的多任务调度可以Task轮流响应事件来实现。

任务的调度:

图3调度算法流程图

在嵌入式系统中，很多应用要求执行的优先级绝对优先，比如USB文件传输的处理。为此，PetOS采用了多级任务机制，并赋予高优先级的任务更高的执行权限。调度时，PetOs将优先调度优先级高的任务。这种调度方式保证了高优先级任务的实时响应，但可能导致低优先级的任务永远无法被执行。为了缓解这种‘饿死’现象，PetOS提供了两种可选的配置：

·严格优先级调度模式：即，若高优先级的任务队列中存在还有事件未响应的任务，则无条件执行高优先级的任务。

·非严格优先级调度模式：即，当高优先级队列调度一轮过后，次优先级的任务队列中的第一个待执行任务可以得到1次调度。调度完成后继续轮询高优先级队列。

可以看到两者的区别在于：严格调度模式可以保证高优先级任务的绝对优先，但是低级任务可能出现‘饿死’的情况。而对于非严格调度模式，不论任务优先级有多低，总能以较低的频率执行。

调度算法的分析及优化:

在非严格模式下，设一级、二级、三级task队列的长度分别为N1，N2，N3。则二级队列中调度一个任务需要判断一级任务N1次；三级队列中调度一个任务需要在一级队列中判断N1×N2次，在二级队列中判断N2次。在一级二级任务都很少被执行，而三级队列中的任务消息粒度很小且执行频率很高时，任务调度所占用的系统消耗便会急剧上升。

一种解决方法是：PetOS给每个消息队列加入了32Bit消息标记位。其中的每一位对应一个该优先级中的任务。若消息标记变量的某一位为1，则代表该位对应的task存在尚未响应的事件；若为0，则表示该级队列所有任务的事件都已经处理完毕，可以调度次优先级的任务。

通过消息标记位策略，若一级二级任务都不存在需要被调度的任务，则三级任务被调度一次的代价只是查询一级、二级任务的消息标记位各一次，从而大大降低了系统的消耗。

3.2中断管理/定时函数管理

中断管理:

由于PetOS的实时性受到事件粒度大小的影响，系统需要提供一种更强有力的实时性保障：中断。PetOS中断处理模块主要完成中断源的判断、中断向量的维护以及中断响应函数的调度等工作。

PetOS支持64个中断源[3]，并对每个中断源支持不限数目的中断处理函数，因此该列表是一个双向链表，里面包涵了该中断号下的中断处理函数，定位后依次执行该链表中的函数。

采用链表方式维护中断处理函数可以更加灵活的维护中断函数列表，但是实际上，很多中断函数都是一次性的，比如USB连接响应函数在被调用后，需要将自己从该中断的函数列表内删除。而此时，中断处理函数正在使用该列表，这样就引起了中断函数链表的不一致性。

解决的方式是：

1）给所有函数句柄加入状态。

2）维护中断函数列表时，如果句柄处于闲置状态，则进行默认的操作；如果句柄处于IRQ状态被删除，则暂时不进行直接的删除操作，而是将句柄状态改成PETOS_IRQ_HANDLER_CALL_STATUS_DELETE。

3）当中断处理主函数调用完该函数后，若发现该函数的句柄状态已经改变，则可得知该函数已经在调用过程中将自己注销。IrqHandler会在此时重写中断维护模块API中注销函数，在这里将该函数句柄删除。

4）重新链接中断函数列表和定位tmpIrqHandler找到下一个中断处理函数句柄。

中断扩展模块－系统时钟模块和定时触发函数:

中断机制保证了PetOS对硬件请求的实时性响应，而对于软件请求的实时性则由PetOS系统时钟/定时触发函数模块完成。该模块主要完成了两部分工作：

·系统时钟模块：系统每隔固定的时间产生一个时间中断。利用前面的中断机制，我们可以模拟一个准实时的，不断执行的任务。具体方法为将这段代码注册为系统时钟的中断处理函数。

·定时触发函数模块：为了满足嵌入式电子产品应用程序的需要，基于系统时钟模块，PetOS供了定时触发函数功能。用户可以向系统注册一个定时触发函数，并指定其被调用的时间。操作系统通过预先注册好的一个系统时钟中断处理函数来检查是否有需要的定时触发函数到期，并执行调度。

PetOS的任务调度是以事件为单位，不可能出现两个任务同时访问同一段代码的情况。因此，大部分代码不需要考虑重入的问题。

4 PetOS的不足及改进方向

目前的调度算法还是存在任务优先级跨度太大的问题，高优先级的任务可能直接导至低优先级任务的“饿死”。

PetOS不可抢占的任务调度机制，各任务无独立栈导致调度不够灵活，如果一个任务的消息处理时间很长，则其他任务的消息响应时间也会很长，使得整个系统的实时性显得较差并且无法移植阻塞式的应到到该系统中。

PetOS并没有启用多态运行模式，而是简单的将OS core和其他应用程序的地址空间复用。这样虽然简化了系统结构，但是带来了OS core的地址空间可能被其他应用程序直接访问的隐患。

因此调度算法及内存管理将是PetOS改进的方向。

5 结束语

增加了优先级调度、任务管理、中断管理、系统时钟管理后，PetOS由一个只适用于简单应用的微型操作系统蜕变为可应用于复杂环境的小型操作系统。由于PetOS的模块化结构和开放性的代码，使得各方案的扩展性和可维护性大大加强，大大缩短了方案开发、产品维护的周期和成本。目前，基于ARM922硬件平台，PetOS已经实现了MP4/学习机等嵌入式消费类电子产品的方案，并已有成熟的产品上市，证明了PetOS的市场潜力。随着新的应用需求，PetOS会得到进一步完善，在嵌入式领域发挥更大的作用。

参考文献：

[1] UCLA Networked and Embedded Systems Lab. PALOS. http://sourceforge.net/projects/palos/ 2002

[2] JeanJ .Labrosse. uC /OS-11-源码公开的实时嵌人式操作系统[M]，中国电力出版社，2001

[3] 杜春雷．ARM体系结构与编程[M] 清华大学出版社， 2003

[4] 沈胜庆．嵌入式操作系统的内核研究[J]．微计算机信息，2006，2-2：72-74