怎样选择实时操作系统.docxVIP

如何选择实时操作系统 很难作决定是买一个实时操作系统，还是自己动手做。如果要买的话，决定买哪一种、从哪家供应商买仍然充满变数。 嵌入式软件工程师总是几乎完全从零开始开发应用程序。为什么会那样？如果从我们的朋友——硬件工程师那里取点儿经的话可能大有裨益。他们开始做一项新设计时，总是选择现成的集成电路，只有到最后不得已时才自己设计逻辑电路。因此，对我们来说，重用他人的工作成果以达到目标的第一步就是要选择一种实时操作系统（RTOS）。然而当你选择RTOS时很有一些需要考虑的问题，一个清晰的思路无疑有助于成功地作出决定。 实时操作系统对我来说真的必要吗？ 在一头扎进如何选择一个实时操作系统的讨论之前，大多数人应该问问自己：为什么需要实时操作系统？是否所有的嵌入式软件系统在实时操作系统的支持下工作得最好？当然不是。有很多简单的产品，不够大也不够复杂，根本负担不起额外的开销。 有关是否使用RTOS的争论非常类似于是否使用高级语言的争论。正象高级语言一样，RTOS使你可以更快地开发产品。它可能要求一些额外的开销，但是随着技术的进步，这种开销在变小。 正如有的应用仍推崇汇编语言，也存在这样一些应用，它们很简单，仅需求很少的一点操作系统服务。在这种情况下，更简单的结构——比如轮转调度之类以状态机为基础的函数——可能就足够了。难道你能指望在你的面包机里安装一个实时操作系统吗？除此之外，你应该考虑RTO S。 自建还是购买？ 在“嵌入式”世界里，就一个工作组该购买还是自建实时操作系统展开了生动的讨论。不幸的是，我们非常缺乏有效的统计数据。我认为在大多数情况下，购买RTOS是较好的选择。我这样说的时候，请注意我与R TOS工业界的任何公司没有任何私人或者职务关系。 关于购买RTOS的争论还有一个小小的轶闻。以前我曾在一个为医疗设备开发嵌入式软件的项目组工作。我们使用的是CMX公司的CMX-RTX。在嵌入式开发者一系列可能的选择中，这个RTOS的特征是很典型的。随OS还提供了11,000行的源代码。想想吧，用CMX公司卖得的两千美元你能定义、设计、实现并测试完成如此的产品吗？我看不大可能。 然而，坚持从零开始自建RTOS的人仍与购买现成专用RTOS的拥护者争论不休。在性能绝对至关重要的场合，写自己的实时操作系统可能允许你花费巨大代价换取有限的百分之几的速度提升。 另外，特定的工业（比如医疗设备、安全系统等）对软件有特定的规则或标准要求。在某些情况下，现成的操作系统满足不了这些要求。这时也只能选择自建。 最后，在嵌入式系统中，为了使用专用代码而安装的基础系统相当大。把老代码剥离出来移植到新的操作系统上难说是个明智的主意。而将产品移植到一种新的微处理器上是说得通的。如果该专用RTOS尚未被移植到新的微处理器上，这可能是考虑使用现成RTOS的一个好时机。 工具的相互关系 一个工程师选择实时操作系统时如果不考虑其余与之相关的工具是不行的。微处理器、在线仿真器（ICE）、编译器、汇编器、连接器、调试器以及模拟器——都这样或那样地影响着操作系统。 有些在线仿真器供应商提供其ICE与实时操作系统接口的软件。检查一下你的ICE是否能与你的RTOS协同工作，这在调试那些最隐蔽的小错误（bugs）时是很有用的。然而，重要的是要了解在线仿真器的操作对性能的影响。有时当ICE执行操作时增加了额外的开销，比如中断某行源代码在某个任务中的执行。 对给定微处理器家族上的某种操作系统来说，很可能OS供应商只支持所有可用编译工具（包括编译器、汇编器和连接器）的一个子集。应该确认供应商支持你所用的。你应该避免我们项目组当初选择一种现成的实时操作系统所碰到的灾难。OS供应商将我们选择的RTOS以源代码的形式提供给了我们，但是我们没有考虑到的一个问题是这种RTOS与我们使用的编译器不能合作。经过六周的艰苦努力，负责修改RTOS源代码的工程师终于完成了任务。 选择准则 除了开发工具箱中其他工具的影响之外，如果你能很好地组织在调查研究RTOS期间所搜集的信息，作出选择就会容易一些。首先列一份可供选择的RTOS清单。到选择RTOS时，你可能已经选定了微处理器。据此你可以立即划掉不支持你的MCU的RTOS从而得到较短的清单。如果你选择了无所不在的68000或者x86系列，则需要更多的准则来帮助你作出选择。 有了一个短的清单之后，艰难的工作才真正开始。首先，要决定对你的应用来说哪条准则是真正重要的。本文讨论了选择时要考虑的几条重要特征，然而每一个应用开发都有差异，需要认真考察到底什么是最重要的。应该根据各项选择准则列一个表，针对每个项目评价每种RTOS。甚至在填完了整张表格之后，模模糊糊的仍然不知该选哪一个，这种事情确实很难干脆果断。参与选择过程的每个人应该对这