首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

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

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

一种解决方法是: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改进的方向。
返回列表