μC/OS -III为缩短中断关闭时间作出的改进

2013-06-25 02:46谌普江龚光华宫辉邵贝贝
单片机与嵌入式系统应用 2013年1期
关键词:服务程序任务调度内核

谌普江,龚光华,宫辉,邵贝贝

(1.清华大学 工程物理系,北京 100084;2.清华大学 粒子技术与辐射成像教育部重点实验室;3.清华大学 飞思卡尔培训中心)

引 言

μC/OS-III是一款全新的实时内核,源于世界上流行的实时内核μC/OS-II。较μC/OS-II,μC/OS-III做了很多改进。其中,很重要的一点就是为了缩短中断关闭时间作出的改进。本文将深入分析为什么这些改进能够使得μC/OS-III的实时性能得到提升。

1 中断简介

所谓中断,其实就是一种硬件机制,用于通知CPU有一个异步事件发生了。由于μC/OS-III是面向以ARM Cortex为代表的高端32位CPU的,因此,本文将以ARM Cortex-M3为例来介绍一般CPU对中断的处理。

如图1所示,中断控制器NVIC和ARM Cortex-M3 CPU紧密合作完成中断的处理。中断控制器NVIC负责接收所有的中断请求。NVIC会把当前优先级最高的中断请求的服务地址传递给CPU。Cortex-M3CPU在确认中断后,会自动将R0~R2、R12~R15入栈保存[1],并跳转执行中断服务程序。中断服务程序执行完后,R0~R2、R12~R15会自动出栈。

图1 ARM Cortex M3中断处理示意图

通过对中断的处理,CPU能够在外部事件发生的时候立刻进行处理,从而满足系统的实时性要求。在一些特殊情况下,CPU需要通过特殊的指令来关中断。然而,需要引起特别注意的是,关中断会增加中断延迟时间,可能导致后续的中断请求丢失。嵌入式系统中断源众多,对实时性要求高,中断关闭的时间越短越好,中断处理程序运行时间越短越好。中断关闭时间的长短是实时内核最重要的一个指标。

2 μC/OS -III作出的改进

在μC/OS-III中,如果一个中断对应的事件不需要任务知道,不需要给任务发送信号或者消息,推荐用户把这个中断写成无需内核参与的中断;如果这个中断需要给任务发送信号或者消息,用户可以选择直接发布或者延迟发布这两种发布模式中的一种。

2.1 无需内核参与的中断

在很多情况下,中断需要做的处理非常简单,比如一些I/O中断,并不需要内核知道。这种情况下典型的无需内核参与的中断服务程序示意代码如下:

在无需内核参与的中断服务程序中(1)处不要开中断,因为开中断后,其他中断可能嵌套,也可能调用μC/OS-III的内核函数,导致调度回到高优先级任务继续执行。而内核并不知道有这个中断,所以这个中断的完成时间将会变得特别长。

笔者建议,I/O中断处理程序最好使用这种方式。另外,在ARM Cortex-M3中,因为R0~R2是自动入栈和出栈的,简单的I/O处理中断尽量只使用R0~R2,这样可以省掉中断服务程序中保存和恢复寄存器的步骤,缩短了中断服务程序的运行时间。

2.2 需要内核参与的中断

一个中断对应的事件正好是一个任务正在等待的事件,这意味着这个中断需要向对应的任务发送信号或者消息。μC/OS-III由中断向任务发送信号或者消息有两种模式。这两种模式分别为直接发布(Direct Post)和延迟发布(Deferred Post)模式。所谓直接发布,是指在中断服务函数中调用各种post函数时,会立即完成post操作;而延迟发布,是指在中断服务函数中调用各种post函数时,不会立即完成post操作,该操作会被缓存起来。

在分析μC/OS-III的这两种发布模式之前,先看看μC/OS-III中典型的需要内核参与的中断服务程序的结构。需要内核参与的中断服务程序[1]示意性代码如下:

2.2.1 直接发布

μC/OS-II中使用的是直接发布模式,μC/OS-III中保留了这个模式。

图2为直接发布模式的示意图,当一个外设产生中断,并向CPU发出中断请求,然后CPU执行中断服务程序。这个需要内核参与的中断服务程序在示意性代码标志(1)这个步骤中,将会调用 OSSemPost()、OSTaskSem-Post()、OSFlagPost()、OSQPost()和 OSTaskQPost()这5个发布函数其中的一个给任务发消息或信号,并且这些post操作会被立即执行,使得正在等待这个中断发生的任务进入就绪状态。

图2 直接发布示意图

在需要内核参与的中断服务程序示意性代码标志(2)中,调用OSIntExit(),OSIntExit()中会调用 OSIntCtxSw()进行任务调度。然后系统将执行更高优先级的任务或者之前被中断的任务。

在直接发布模式下,中断服务程序会直接执行post操作。而这些post操作会访问μC/OS-III中的很多临界段代码,因此μC/OS-III必须通过关中断来保护系统中会被上述post操作所访问到的临界段代码,这样无疑会增加中断关闭的时间。中断关闭时间的增加会导致实时内核的实时性能降低。

2.2.2 延迟发布

在详细研究延迟发布模式之前,必须先了解μC/OSIII中两个新的概念。

(1)中断队列

中断队列类似于一个堆栈,它专门用来保存发布函数调用操作以及与这个调用相关的参数。

(2)中断队列处理任务

中断队列处理任务是μC/OS-III中一个新的内部任务,它具有最高的优先级(优先级0)。这个任务专门用来处理中断队列。

图3为延迟发布模式的示意图,一个外设产生中断,并向CPU发出中断请求,然后CPU执行中断服务程序。

图3 延迟发布模式示意图

与直接发布模式不同的是,这个中断服务程序调用发布函数给任务发布消息或信号时,系统不会立即执行这些post操作,而是将这些post函数的调用以及相应的参数写入中断队列中,并且使中断队列处理任务进入就绪态。

举例说明,μC/OS-III中,中断服务程序给任务发送信号量时,调用OSSemPost()函数。在OSSemPost()函数中,系统先判断是什么发布模式。如果是延迟发布模式,则调用OS_IntQPost(),OS_IntQPost()用来将 OSSem-Post()函数的调用和相应的参数写入中断队列并使得中断处理任务进入就绪态;如果是直接发布模式,则调用OS_SemPost(),这个函数用来执行信号量的post操作。OSSemPost()函数的部分源码如下:

然后,中断服务程序执行 OSIntExit(),OSIntExit()中调用OSIntCtxSw()执行任务调度。由于中断队列处理任务优先级最高,μC/OS-III将执行中断队列处理任务。该任务从中断队列中提取出发布函数调用信息,此时仍需要关闭中断,以防止中断服务程序同时对中断队列进行访问。中断队列处理任务提取出发布函数调用的信息后重新开中断,并且锁定任务调度器,然后进行发布函数调用,相当于发布函数调用一直在任务级代码中进行。

这个中断队列处理任务将中断队列一一处理完后,将自身挂起,并重新启动任务调度来运行当前处于最高优先级的就绪任务。

由于延迟发布模式下,μC/OS-III的中断服务程序不会直接进行post操作。所以μC/OS-III中那些能够被post操作所访问的临界段代码不需要进行关闭中断的操作,只需要禁止任务调度就行。这将使得系统关中断时间大大缩短。

延迟发布模式下,用最高优先级的中断队列处理任务来处理需要做任务调度的中断,在保护了临界段代码的同时,又保持了中断的快速响应和处理。中断服务程序不需要进行post操作,从而缩短了中断服务程序的时间。

2.2.3 模式选择

直接发布模式和延迟发布模式最主要的区别在于中断关闭时间。延迟发布模式很大程度上缩短了中断关闭时间和中断程序的运行时间,但是却增加了任务的延时。

应用中如果存在要求响应非常迅速的中断源,用户应该选择延迟发布模式,因为用直接发布模式很有可能无法处理。

另外,由于μC/OS-III中,相同优先级下的多任务、事件标志组、等待多个内核对象、调用广播方式发布这4个特性都会导致临界段代码变长。如果应用中用到了这些特性,应该使用延迟发布模式。

如果应用中不存在要求响应非常迅速的中断源,也没有用到以上几种特性,用户可以使用直接发布模式,即μC/OS-II模式,否则还是建议用户尽量使用延迟发布模式。

选择μC/OS-III的发布模式非常简单,只需要在OS_cfg.h中设置OS_CFG_ISR_POST_DEFERRED_EN的值即可,对应用程序和中断服务程序,代码不需要做任何改动:置0,为直接发布模式;置1,为延迟发布模式。

2.2.4 实验结果比较

笔者在PK10N512VLL100上移植了μC/OS-III,这是Freescale公司的一款基于ARM Cortex-M4核的微控制器。通过一些简单的小实验来分析直接发布模式以及延迟发布模式下,中断关闭时间的对比。实验中通过启动系统的统计任务stat_task,然后读取系统的全局变量OSIntDisTimeMax来获取系统的最大中断关闭时间。

整个实验用控制LED的闪烁任务来实现4种不同的实验条件。第1种,只有一个初始化任务,用来初始化硬件和控制LED的闪烁;第2种,有一个初始化任务(初始化硬件)和两个优先级一样的用户任务(分别控制两个不同的LED周期闪烁);第3种,有一个初始化任务(初始化硬件)和4个优先级一样的用户任务(分别控制4个不同的LED周期闪烁),并且没用到广播消息的功能;第4种,有一个初始化任务(初始化硬件)和4个优先级一样的用户任务(分别控制4个不同的LED周期闪烁),并且实验中用到了广播消息的功能(初始化任务向4个优先级一样的用户任务广播消息)。

表1是实验结果,表中的最大中断关闭时间的单位为系统的时钟周期数,实验中系统的时钟为100MHz。

从以上实验结果可以看出,4种实验条件下,延迟发布模式的最大中断关闭时间基本保持恒定。而直接发布模式下,系统的任务越多,功能越复杂,最大中断关闭时间也越来越长。并且,在相同条件下,直接发布模式的最大中断关闭时间比延迟发布模式大很多。

表1 实验结果

结 语

相对于μC/OS-II,μC/OS-III在缩短中断关闭时间方面作出了突出的改进。首先,用户可以根据中断的类型使用无需内核参与的中断服务程序和需要内核参与的中断服务程序,尽最大可能减少中断程序的运行时间。另外,新增了由中断给任务发送信号或消息的延迟发布模式。该模式有效地缩短了中断关闭的时间和中断程序的运行时间,提高了系统的实时性。

[1]Joseph Yiu.ARM Cortex-M3权威指南[M].宋岩,译.北京:北京航空航天大学出版社,2009.

[2]Labrosse Jean J.μC/OS-III the Real Time Kernel[M].Weston:Micriμm Press,2011.

猜你喜欢
服务程序任务调度内核
多内核操作系统综述①
强化『高新』内核 打造农业『硅谷』
SylixOS系统的中断嵌套机制研究与实现
基于C#的进程守护程序的设计
UDP穿透NAT技术实现数据唤醒车联网T-Box设备的方案
基于改进NSGA-Ⅱ算法的协同制造任务调度研究
基于嵌入式Linux内核的自恢复设计
Linux内核mmap保护机制研究
基于时间负载均衡蚁群算法的云任务调度优化
云计算环境中任务调度策略