|
- UID
- 872238
|
对许多嵌入式项目来说，系统设计师都倾向于选择实时操作系统(RTOS)。但RTOS总是必要的吗?答案是取决于具体的应用，因此了解我们要达到什么目标是决定RTOS是必要的还是花瓶的关键。
一般来说，在采用非实时操作系统(non-RTOS)的任何场合，也都可采用RTOS。但是，要找到一款具有完全相同应用编程接口(API)的匹配RTOS就相当困难了。因此，许多传统的操作系统(OS)在其内嵌入了一个RTOS。例如，Lynux-Works LynxOS和Bluecat Linux共享一个Linux API。LynxOS是一款硬RTOS，而Bluecat是Linux的一个衍生产品。
Linux继续在努力改善其实时性能，但其最长中断时延仍无法满足对RTOS来说至关重要的硬(hard)实时要求。这些问题最后都会归结为服务质量(QoS)。像RTLinux Free这样的平台补充了Linux，因为它们可提供硬实时级别的QoS。
要指出的很重要一点是：这类补充常常是在原始OS上集成一个RTOS编程环境。与传统台式或服务器OS相比，RTOS通常要小很多。RTOS常常针对更小和资源有限的MCU。例如，CMX的CMX-RTX和CMX-Tiny+可运行在8位MCU到64位处理器上。
8位处理器不断增加的计算能力和存储容量正使得RTOS对这些平台具有更大吸引力。但是，通常16位或以上平台才需要OS或RTOS，常见的RTOS选择有Express Logic的ThreadX、Wind River的VxWorks、Micrium的uCOS-II、以及Green Hills Software的velOSity。取决于需求，MontaVista的Linux可在几个微秒的水平上满足16位和32位平台的要求。
RTOS核心：调度和分割
大多数程序员不熟悉RTOS的限制和要求。大多数人通常因其性能选择RTOS。大多数RTOS产品代码少和速度快，现在RTOS还提升了一致性。RTOS除能很快完成任务外，还能保证很好地完成任务。
在许多应用中，一个迟到的结果可以是灾难性的。因此，人们宁愿在一个要求的时限内获得较差的结果。这些应用通常被称为硬实时系统。硬实时不是指系统响应有多快或多快一个系统能响应，而是指系统能多可靠地满足特定的要求。
一个硬实时系统可能有一个一分钟的固定周期时间，它要求的响应时间为一秒。理论上，这样的要求几乎所有的操作系统都能实现。但事实并非总是如此，正如任何一个人都能证明等待台式计算机应用在一分钟之内做出响应需要等多久。
硬实时系统通常具有更短的周期时间和更紧苛的响应要求。更快的处理器速度总是有帮助的，多内核平台也能改善响应速度。对开发人员来说，窍门在于把系统需求与硬件和软件匹配起来，然后才是RTOS在嵌入式应用中的重要性。
一个RTOS可以实现一系列调度策略，但应用经常会制约一个程序员的选择(见表)。非优先式调度(non-preemptive scheduling)的实现虽不重要，但在一些应用中很有用。另一方面，任务内的非优先式调度可在优先式系统的顶部实现。
不应该轻忽非优先式调度，特别在新型多内核处理器出现以后。这里，硬件可被调整到处理一个基于事件的操作，其中线程将等待外部事件的发生。对处理多线程的单核处理器来说，该方法一般不适用。但对有许多内核的多核系统说，典型情况是为一个外设指定一个核。所以，在等待事件发生期间，使该核空闲起来是有意义的。
其结果是，优先式、中断驱动的RTOS架构占据了业已部署的大部分平台。虽然借助硬件手段(多个寄存器组合、硬件调度、任务切换、以及分层中断优先级系统等)可显著缩短中断时延，但该时延永远是一个问题。
优先式处理会带来若干问题。它们大多是与时序关联的，如竞争条件、死循环、空耗等待和优先级转换，它们发生在低优先级任务A拥有更高优先级任务B的同步资源，而优先级比A高的任务C正在运行。
如果没有像优先级置顶(priority ceilings)这样的特性，任务C就可以阻止任务A和任务C运行。优先级置顶特性可以把任务A的优先级改变成与任务C的优先级一样，从而允许任务A运行并最终释放任务C所需的资源。至此，任务A的优先级复原，任务C就可以继续运行。
程序员必须解决的其它与时序相关的问题通常是难以定位和纠正的缺陷源。在定位这些缺陷时跟踪工具就变成了很有价值的手段，因为诸如受阻的任务等症候是这些问题的唯一表现形式 |
|
