μC/OS-II的实时性能分析

摘要：简单介绍一种公开源代码的实时操作系统μC/OS-II，并对它的实时性能进行简单的测试。通过改变测试条件，如改变中断的类型或中断发生时系统的状态等，分析μC/OS-II在中断时的中断响应时间与各种条件之间的关系，从而为分析或改善实时操作系统的中断响应时间提供理论依据。
关键词：RTOS μC/OS-II 中断响应时间 实时性能
引 言
1 嵌入式实时操作系统和μC/OS-II
　　嵌入式操作系统EOS(Embedded Operating System)主要负责嵌入式系统的全部软、硬件资源的分配、调度、控制、协调并发活动;它必须体现其所在系统的特征，能够通过装卸某些模块来达到系统所要求的功能[1]。
　　μC/OS-II是专门为计算机的嵌入式应用而设计的实时操作系统，是基于静态优先级的占先式（preemptive）多任务实时内核。采用μC/OS-II作为测试的目标，一方面是因为它已经通过了很多严格的测试，被确认是一个安全的、高效的实时操作系统；另一个重要的原因，是因为它免费提供了内核的源代码，通过修改相关的源代码，就可以比较容易地构造自己所需要的测试环境，实现自己需要的功能。
2 实时操作系统和系统实时性能指标
　　实时系统对逻辑和时序的要求非常严格，如果逻辑和时序出现偏差将会引起严重后果。实时系统有两种类型：软实时系统和硬实时系统。软实时系统仅要求事件响应是实时的，并不要求限定某一任务必须在多长时间内完成；而在硬实时系统中，不仅要求任务响应要实时，而且要求在规定的时间内完成事件的处理。通常，大多数实时系统是两者的结合。
　　事实上，没有一个绝对的数字可以说明什么是硬实时，什么是软实时。它们之间的界限是十分模糊的。这与选择什么样的CPU，它的主频、内存等参数有一定的关系[1]。另外，因为应用的场合对系统实时性能要求的不同而有不同的定义。因此，在现有的固定的软、硬件平台上，如何测试并找出决定系统实时性能的关键参数，并给出优化的措施和试验数据，就成为一个具有普遍意义并且值得深入探讨的课题。本文就是基于此目的进行讨论的。
　　因为采用实时操作系统的意义就在于能够及时处理各种突发的事件，即处理各种中断，因而衡量嵌入式实时操作系统的最主要、最具有代表性的性能指标参数无疑应该是中断响应时间了。中断响应时间通常被定义为：
　　中断响应时间=中断延迟时间+保存CPU状态的时间+该内核的ISR进入函数的执行时间[2]。
　　中断延迟时间=MAX(关中断的最长时间，最长指令时间) + 开始执行ISR的第一条指令的时间[2]。
　　通俗点定义就是：从中断发生起，到执行中断处理程序的第一条指令所用的时间。由于实时操作系统更多考虑的是最坏的情况，而不是平均的情况，因此指令执行的时间就按照最长的指令执行时间来计算，所以中断延迟时间，通常是由关中断的最长时间来决定的。当FIQ（快速中断）使能时，最坏情况下FIQ的中断延迟时间由以下几个部分构成：
　　t同步——请求通过同步器的最长时间，约4个处理器周期。
　　t最长指令时间——最长指令完成的时间。最长指令是加载包括PC的所有寄存器的LDM指令，在零等待状态的系统中，约为20个周期。
　　t异常——数据异常进入时间，为3个周期。
　　tFIQ——FIQ进入时间， 2个周期。
　　最大的FIQ中断延迟时间约为29个时钟周期。在系统使用40 MHz处理器时钟时，约为0.7 μs。
　　对于最大的IRQ延迟，其计算与FIQ类似。若必须允许FIQ有更高的优先级，那么进入IRQ处理程序的延迟时间是随机的[3]。
3 试验原理和测试方法
　　首先需要启动并开始运行μC/OS-II，因为试验需要使用的计时函数是系统函数。进行堆栈和中断向量等系统初始化后，首先要创建一个任务，用以产生中断。这样OS启动后，中断服务程序可以在任务中调用或者切换，中断源可以设置为外部中断或由任务产生。在主程序的临界段循环查询中断状态（VICRawIntr;中断状态寄存器），一旦发现有中断标识，则立即启动计数器，并使能该中断，跳出临界段（在进入临界段之前要关中断(OS_ENTER_CRITICAL())，而跳出临界段代码进入中断服务子程序后，保存全部CPU寄存器后清除中断源，并立即开中断(OS_EXIT_CRITICAL())，然后停止计时并执行中断处理代码）。由于是在检测到中断标识后才跳出临界段，所以一跳出临界段就会立即发生中断，进行中断处理。保存了CPU寄存器后进入中断服务的第一条指令就是保存计数器值。由于在跳出临界段时才启动的计数器，而在进入中断服务时立即保存了计数值，所以这个计数值就是所需要的中断响应时间。
　　如果要试验不同优先级的中断响应时间，可以设几个不同优先级的中断服务程序，在高优先级程序的出口计数器清零；而在下一个中断开始时保存计数值，从而测试中断优先级对中断响应时间的影响。
　　如果要测试不同类型的中断响应时间，可以在程序中，分别使用不同类型的中断（向量中断，非向量中断，快速中断）来测试中断类型对中断响应时间的影响。原则上快速中断（FIQ）要求具有最高的优先级，而且快速中断的处理与操作系统基本无关，中断服务子程序可以自行编写（在不调用μC/OS-II的系统服务程序的情况下），没有特别的要求。向量中断则不能如此。因为虽然ADS可以使用_irq关键字来声明一个函数是用来处理中断的，从而可以避免在程序中使用汇编代码，但是在μC/OS-II中不能这样处理。因为使用C语言无法确保堆栈的结构，而RTOS必须使堆栈保持一定的结构。这只有汇编语言可以做到。这部分的代码在文件VECTORS.S中（为了简化用户编写中断服务子程序，这段汇编代码已经被编写成一个宏HANDLER）[4]。具体可见参考文献[4]的P358~P359中所列的程序清单6.5中的汇编代码，即中断服务子程序必须按照 μC/OS-II的中断服务程序的要求编写，格式如下[4]：
保存全部CPU寄存器;(1)
调用OSIntEnter或OSIntNesting直接加1；(2)
清除中断源(3)
重新开中断(4)
执行用户代码做中断服务;(5)
调用OSIntExit()；(6)
恢复所有CPU寄存器；（7）
执行中断返回指令；（8）
　　如果要测试存储器加速模块对中断响应时间的影响，可以在关闭、部分使能和完全使能3种设置下分别测试同一个中断的响应时间，从而得出中断响应时间与存储器加速模块设置之间的关系。