对于RTOS，时间调配就是一切
最重要的是必须透彻理解应用的要求
很多人认为实时操作系统（RTOS）相当于软件中的赛车：小、快、高度协调。但这种比喻不够全面，没有充分说明RTOS使你的设计受益的情况。
RTOS使设计人员能够建立一个复杂的系统。这个系统能对任何时间要求苛刻的事件作出响应，在正确的时间做一个正确的动作。例如，要求系统必须在 5μs内对某种告警情况作出响应。一个好的RTOS能使你的系统始终满足时限的要求，即使在重负荷的情况下也一样。
优先级
在RTOS中，过程按优先级执行。时限紧迫的过程投入运行时，可以立即从低优先级的过程接管CPU。而且高优先级过程在结束前，能一直继续运行，除非它被一个更高优先级的过程所抢占。这种“抢占”
调度方式可以使对于时间要求严格的过程满足时限的要求，无论是有多少其他过程正在运行。
RTOS不仅要使任何应用程序和驱动程序符合这种优先级的安排，而且也包括所有的中断操作——响应中断的一小段代码。在任何复杂的系统中，都会有多个
中断同时发生。例如，在一个心脏监视设备中，当一个传感器记录病人的心跳变化时，或通过网络接收病人的测量数据时，护士可能会去点击鼠标。显然，一些中断
（如心率的变化）应立即得到关注，而其他的可以稍等一下或被抢占。对各种中断分配一个优先级，使之具有中断嵌套能力，可保证重要的中断放在第一位安排。
可靠性
RTOS应该好好利用存储器管理单元，这是一个大多数现代微处理器中都有的构成部件。以传统的“平铺”（
flat）体系结构为例，大多数“成品的”或“自建的”RTOS仍在使用这种体系结构。它把所有的模块放在同一个地址空间中，作为操作系统的内核（见图1），没有任何存储器的保护。结果任何模块，不管它是多么无关紧要，也能通过内核对存储器进行重写，导致整个系统的崩溃。
有少数的RTOS针对这个问题，使应用程序运行在分离的有存储器保护的地址空间。如果一个应用程序试图侵害存储器，MMU就会捕获这个错误，从而把这
个问题隔离开来。但不幸的是，这些操作系统仍和驱动程序、协议、文件系统绑在一起，并且其他系统可对此内核服务。从而使得这些模块中的任何一个都能导致内
核发生致命的错误。
其他的操作系统的体系结构，如QNX RTOS
的微核体系结构，则向前近了一步，可使任何系统级的软件部件在其各自的MMU所保护的地址空间运行（见图2）。用这种方法，出错的驱动程序和协议则不再成
为单个就起作用的失效点，而是可以在它们引起其他服务失效前，就使它们停止或重新启动，不必重新开机引导。
应用程序
除存储器保护外，提高可靠性的最好途径之一是使你的应用程序的部件分派到多个CPU，即使一个CPU失效，也不
会停止应用程序的工作。实际上，当实时应用任务增大时，你不得不把它分给多个CPU，因为这时可能需要比一个CPU能管理的更多的物理接口，或仅仅是更多的处理能力。
当然分布式应用有它自己要解决的问题，例如，对大多数的RTOS，你一般需增加为应用服务的专用的网络程序，使接在网络上的CPU能相互“对话”，进
行服务。此外对于大多数RTOS，驱动程序、协议和应用程序是与内核紧密相连的，要把它们从一个核搬移到另一个核，需要建立一个适合各个CPU的新的内核
的映像，并仔细地对它进行测试。
微核RTOS从两方面来解决这个问题。首先，使应用程序、协议和驱动程序全都与操作系统脱离，从而使它们从一个CPU
搬移另一个CPU时，可以不需要对内核重新配置。其次，在微核操作系统中应用程序间通讯的典型情况是通过传递消息进行的。如果实现得好，可不需要专用的网
络程序。例如，当应用A发送一个消息到应用B时，它不用去了解应用B是使用同一个CPU板，还是由网络连接的另一个CPU。结果任何CPU上的一个过程可
以对任何其他机器上的任何资源（一个盘、调制解调器或I/O口）进行显式的存取，这个网络就像单个计算机那样工作。
选择考虑
正确选择RTOS本身就是一件复杂的事情。显然, 应把RTOS的架构作为考虑的基础，但还要考虑其他的因素：
* 规模 选用RTOS要根据你的设计会有多大规模和设计的复杂程度来决定。例如，RTOS支持多少个MMU保护的过程，是几十个（如QNX
RTOS中的情况）还是几千个？支持的过程越多，设计的选项就越多，增加性能就更容易，一个软件模块中的错误对系统其他部分的影响或许可更小。
* 升级能力 在任何应用程序或驱动程序不工作时，能否进行替换和升级，还是得使整个系统复位?如果你的系统必须连续运行，这是一个关键的条件。
* 标准的API RTOS是否只能用个人所有的API，还是支持一个开放的API，如很多程序员熟悉的POSIX？另外，它是支持所有开放的API，还是支持一个小的子集?
* 工具 RTOS是否支持用一个工业标准的专业工具来构建模块和进行软件测试、系统分析、调试等等？还是只适用于你个人的工具箱，在移到另一个RTOS时，这个工具箱是不能使用的？
* 易扩展性
几乎任何的嵌入式操作系统要求有用户驱动程序和其他特殊的操作系统的扩展（如协议和文件系统）。这些是否必须写成核级的模块，按照对内核的要求调试。这需
要耗费重新构建内核的时间,并需聘用昂贵的核开发人员。还是写成存储器保护的在用户空间的程序就可以？这种程序可使用同样的源级工具和开发人员来建立通常
的应用程序。
* 开发模块 RTOS是否能在自身的开发宿主上进行驱动程序、应用程序和协议的测试（自主开发），还是必须首先把它们下载到目标系统上（交叉开发）？可自主开发的RTOS使你在目标板硬件准备好之前，就可编写和测试大部分的软件。
* GUI选项
RTOS是否支持图形库？它是否提供一个真正的视窗系统，可使多个本地用户和JAVA应用程序共享这个屏幕？能否很容易使GUI的显示和触摸界面用户化，
建立一个适合最终用户的接口？GUI是否支持统一的字符编码标准？能否处理实时的变化、快速的动画和三维的图形？能否动态地对任何一个GUI子系统进行替
换和升级？
* 处理器的独立性 RTOS是否能使为用户程序和器件驱动程序所编写的源代码，可以被多种处理器识别（如Power
PC、MIPS、SH-4、Xscale和X86）？如果可以的话，你就可在选定处理器之前，编写和测试大部分源代码。并且可使用不同的处理器实现不同的性能价格折中点。
* 均衡的多机处理（SMP） 如果RTOS支持SMP，则你可在两个或多个CPU上运行你的应用程序，就像在只有一个处理器的板上运行那样。你可以有效地使你的处理能力加倍，不需要增加支持芯片，也不需在底板上增加插槽，即可开始。
在RTOS的供应商向你详细介绍了操作系统的体系结构，并提供了对上述问题的回答后，你就可以更好地选择所需要的RTOS, 使它适合于现在的应用，且对将来也是合适的。
作者:Paul Leroux 更新日期:2005-04-17
来源:QNX软件系统公司
浏览次数:
相关文章
相关评论 发表评论
- No Comments