2.32    时钟节拍(Clock Tick)

    时钟节拍是特定的周期性中断。这个中断可以看作是系统心脏的脉动。中断之间的时间间隔取决于不同的应用，一般在10mS到200mS之间。时钟的节拍式中断使得内核可以将任务延时若干个整数时钟节拍，以及当任务等待事件发生时，提供等待超时的依据。时钟节拍率越快，系统的额外开销就越大。

    各种实时内核都有将任务延时若干个时钟节拍的功能。然而这并不意味着延时的精度是1个时钟节拍，只是在每个时钟节拍中断到来时对任务延时做一次裁决而已。

    图2.25到图2.27示意任务将自身延迟一个时钟节拍的时序。阴影部分是各部分程序的执行时间。请注意，相应的程序运行时间是长短不一的，这反映了程序中含有循环和条件转移语句(即if/else, switch, ? : 等语句)的典型情况。时间节拍中断服务子程序的运行时间也是不一样的。尽管在图中画得有所夸大。

    第一种情况如图2.25所示，优先级高的任务和中断服务超前于要求延时一个时钟节拍的任务运行。可以看出，虽然该任务想要延时20mS，但由于其优先级的缘故，实际上每次延时多少是变化的，这就引起了任务执行时间的抖动。

    第二种情况，如图2.26所示，所有高优先级的任务和中断服务的执行时间略微小于一个时钟节拍。如果任务将自己延时一个时钟节拍的请求刚好发生在下一个时钟节拍之前，这个任务的再次执行几乎是立即开始的。因此，如果要求任务的延迟至少为一个时钟节拍的话，则要多定义一个延时时钟节拍。换句话说，如果想要将一个任务至少延迟5个时钟节拍的话，得在程序中延时6个时钟节拍。

图2.25将任务延迟一个时钟节拍(第一种情况)

图2.26将任务延迟一个时钟节拍(第二种情况)

图2.27将任务延迟一个时钟节拍(第三种情况)

第三种情况，如图2.27所示，所有高优先级的任务加上中断服务的执行时间长于一个时钟节拍。在这种情况下，拟延迟一个时钟节拍的任务实际上在两个时钟节拍后开始运行，引起了延迟时间超差。这在某些应用中或许是可以的，而在多数情况下是不可接受的。

    上述情况在所有的实时内核中都会出现，这与CPU负荷有关，也可能与系统设计不正确有关。以下是这类问题可能的解决方案：

l          增加微处理器的时钟频率

l          增加时钟节拍的频率

l          重新安排任务的优先级

l          避免使用浮点运算(如果非使用不可，尽量用单精度数)

l          使用能较好地优化程序代码的编译器

l          时间要求苛刻的代码用汇编语言写

l          如果可能，用同一家族的更快的微处理器做系统升级。如从8086向80186升级，从68000向68020升级等

l           

不管怎么样，抖动总是存在的。

2.33    对存储器的需求

       如果设计是前后台系统，对存储器容量的需求仅仅取决于应用程序代码。而使用多任务内核时的情况则很不一样。内核本身需要额外的代码空间(ROM)。内核的大小取决于多种因素，取决于内核的特性，从1K到100K字节都是可能的。8位CPU用的最小内核只提供任务调度、任务切换、信号量处理、延时及超时服务约需要1K到3K代码空间。代码空间总需求量由表达式[2.12]给出。

[2.12]  总代码量 = 应用程序代码 + 内核代码

       因为每个任务都是独立运行的，必须给每个任务提供单独的栈空间(RAM)。应用程序设计人员决定分配给每个任务多少栈空间时，应该尽可能使之接近实际需求量 (有时，这是相当困难的一件事)。栈空间的大小不仅仅要计算任务本身的需求 (局部变量、函数调用等等)，还需要计算最多中断嵌套层数(保存寄存器、中断服务程序中的局部变量等)。根据不同的目标微处理器和内核的类型，任务栈和系统栈可以是分开的。系统栈专门用于处理中断级代码。这样做有许多好处，每个任务需要的栈空间可以大大减少。内核的另一个应该具有的性能是，每个任务所需的栈空间大小可以分别定义(µC/OS－II可以做到)。相反，有些内核要求每个任务所需的栈空间都相同。所有内核都需要额外的栈空间以保证内部变量、数据结构、队列等。如果内核不支持单独的中断用栈，总的RAM需求由表达式[2.13]给出。

[2.13] RAM总需求 = 应用程序的RAM需求 + (任务栈需求 + 最大中断嵌套栈需求) * 任务数

       如果内核支持中断用栈分离，总RAM需求量由表达式[2.14]给出

[2.14]=RAM总需求 = 应用程序的RAM需求 + 内核数据区的RAM需求 + 各任务栈需求之总和 + 最多中断嵌套之栈需求

除非有特别大的RAM空间可以所用，对栈空间的分配与使用要非常小心。为减少应用程序需要的RAM空间，对每个任务栈空间的使用都要非常小心，特别要注意以下几点：

l          定义函数和中断服务子程序中的局部变量，特别是定义大型数组和数据结构

l          函数(即子程序)的嵌套

l          中断嵌套

l          库函数需要的栈空间

l          多变元的函数调用

       综上所述，多任务系统比前后台系统需要更多的代码空间(ROM)和数据空间(RAM)。额外的代码空间取决于内核的大小，而RAM的用量取决于系统中的任务数。

2.34    使用实时内核的优缺点

实时内核也称为实时操作系统或RTOS。它的使用使得实时应用程序的设计和扩展变得容易，不需要大的改动就可以增加新的功能。通过将应用程序分割成若干独立的任务，RTOS使得应用程序的设计过程大为减化。使用可剥夺性内核时，所有时间要求苛刻的事件都得到了尽可能快捷、有效的处理。通过有效的服务，如信号量、邮箱、队列、延时、超时等，RTOS使得资源得到更好的利用。

       如果应用项目对额外的需求可以承受，应该考虑使用实时内核。这些额外的需求是：内核的价格，额外的ROM/RAM开销，2到4百分点的CPU额外负荷。

       还没有提到的一个因素是使用实时内核增加的价格成本。在一些应用中，价格就是一切，以至于对使用RTOS连想都不敢想。

当今有80个以上的RTOS商家，生产面向8位、16位、32位、甚至是64位的微处理器的RTOS产品。一些软件包是完整的操作系统，不仅包括实时内核，还包括输入输出管理、视窗系统(用于显示)、文件系统、网络、语言接口库、调试软件、交叉平台编译(Cross-Platform compilers)。RTOS的价格从70美元到30,000美元。RTOS制造商还可能索取每个目标系统的版权使用费。就像从RTOS商家那买一个芯片安装到每一个产品上，然后一同出售。RTOS商家称之为硅片软件(Silicon Software)。每个产品的版权费从5美元到250美元不等。同如今的其它软件包一样，还得考虑软件维护费，这部分开销为每年还得花100到5,000美元！

2.35    实时系统小结

       三种类型的实时系统归纳于表2.2中，这三种实时系统是：前后台系统，不可剥夺型内核和可剥夺型内核。