新闻中心

EEPW首页 > 嵌入式系统 > 设计应用 > μC/OS-II的实时系统加速模块设计

μC/OS-II的实时系统加速模块设计

作者:时间:2013-10-15来源:网络收藏


当有更高优先级的任务进入就绪态时,就会产生RTA中断。硬件实现上,当进入就绪态的上个时钟周期的最高优先级和本时刻的最高优先级不同时,便产生中断信号。在μC/OS-II中,每个TimeTick时刻都会发生中断,这就需要更频繁地保存CPU寄存器,相比本文提出的方法,浪费了更多的CPU时间。

1.2 TimeTick信号的产生

RTA的运行需要一个可配置的Timer来为其产生TimeTick信号。在本文中,通过对OR1200进行改造,利用其内部的Timer产生中断信号作为RTA任务调度的标准时钟节拍,而将RTA的中断信号连接到原来Timer在CPU的接口处。这样,CPU通过Wishbone总线可对Timer进行读写,且RTA产生的中断不会占用可编程中断控制器PIC(Programmable Interrupt Controller)。改造后的框图如图2所示。


1.3 软件实现

因为任务数据结构的改变,源码中所有涉及到任务数据结构的函数都要进行修改。由于任务调度和时间处理由RTA模块执行,原先执行TimeTick的中断函数要作相应修改,在中断时,只需读取RTA中HighestPrio寄存器,然后做上下文切换,运行该优先级的任务即可。

2 实验结果

本实验使用的CPU为OR1200,CPU和所有的外设都通过Wishbone总线连接,系统时钟为25 MHz。在Altera的Cyclone II FPGA平台上,使用Quartus8.1工具对RTA进行布局布线,其共占用4 197个逻辑单元LE(Logic Element)。

任务响应时间是RTOS性能的一个重要指标,其定义为:从任务中断产生的时刻起,到恢复任务执行之间的时间。试验中,利用自定义的Timer作为测量标尺,在2个测试点各读取一次,相减后的数值再乘以此Timer的周期,便得到该段测试时间。图3是有硬件加速和无硬件加速的任务响应时间的测试结果,单位是系统时钟周期。

从图中3可以看出,在无硬件支持的RTOS中,随着任务数的增加,任务响应时间也随之呈线性增加。其原因是,程序顺序执行,在无硬件加速的情况下,RTOS内核在每个TimeTick中断都要对任务的延时域进行顺序更新。随着任务的增加,延时域的处理时间也增长。有硬件加速支持时,任务响应时间缩短,而且与正在运行的任务数量没有关系。这是因为所有任务的延时域都同时更新,在一个时钟周期内即可全部完成。所以使用RTA模块后,降低了系统本身占用CPU的时间,提高了系统的可预测性。可见,在添加RTA模块后RTOS的性能得到了提高。

本文将μC/OS-II系统中调用频繁的任务调度和时间管理采用硬件实现,达到了降低系统负载、稳定任务响应时间、提高系统可预测性的目的。实验结果表明,使用本硬件,任务中断响应时间可降低85.8%。


上一页 1 2 下一页

评论


相关推荐

技术专区

关闭