很难作决定是买一个实时操作系统，还是自己动手做。如果要买的话,决定买哪一种、从哪家供应商买仍然充满变数。 

嵌入式软件工程师总是几乎完全从零开始开发应用程序。为什么会那样？如果从我们的朋友——硬件工程师那里取点儿经的话可能大有裨益。他们开始做一项新设计时，总是选择现成的集成电路，只有到最后不得已时才自己设计逻辑电路。因此，对我们来说，重用他人的工作成果以达到目标的第一步就是要选择一种实时操作系统（RTOS）。然而当你选择RTOS时很有一些需要考虑的问题，一个清晰的思路无疑有助于成功地作出决定。 

实时操作系统对我来说真的必要吗？ 
Do I really need a real-time operating system? 

在一头扎进如何选择一个实时操作系统的讨论之前，大多数人应该问问自己：为什么需要实时操作系统？是否所有的嵌入式软件系统在实时操作系统的支持下工作得最好？当然不是。有很多简单的产品，不够大也不够复杂，根本负担不起额外的开销。 

有关是否使用RTOS的争论非常类似于是否使用高级语言的争论。正象高级语言一样，RTOS使你可以更快地开发产品。它可能要求一些额外的开销，但是随着技术的进步，这种开销在变小。 

正如有的应用仍推崇汇编语言，也存在这样一些应用，它们很简单，仅需求很少的一点操作系统服务。在这种情况下，更简单的结构——比如轮转调度之类以状态机为基础的函数——可能就足够了。难道你能指望在你的面包机里安装一个实时操作系统吗？除此之外，你应该考虑RTOS。 

自建还是购买？ 
Build vs. buy 

在“嵌入式”世界里，就一个工作组该购买还是自建实时操作系统展开了生动的讨论。不幸的是，我们非常缺乏有效的统计数据。我认为在大多数情况下，购买RTOS是较好的选择。我这样说的时候，请注意我与RTOS工业界的任何公司没有任何私人或者职务关系。 

关于购买RTOS的争论还有一个小小的轶闻。以前我曾在一个为医疗设备开发嵌入式软件的项目组工作。我们使用的是CMX公司的CMX-RTX。在嵌入式开发者一系列可能的选择中，这个RTOS的特征是很典型的。随OS还提供了11,000行的源代码。想想吧，用CMX公司卖得的两千美元你能定义、设计、实现并测试完成如此的产品吗？我看不大可能。 

然而，坚持从零开始自建RTOS的人仍与购买现成专用RTOS的拥护者争论不休。在性能绝对至关重要的场合，写自己的实时操作系统可能允许你花费巨大代价换取有限的百分之几的速度提升。 

另外，特定的工业（比如医疗设备、安全系统等）对软件有特定的规则或标准要求。在某些情况下，现成的操作系统满足不了这些要求。这时也只能选择自建。 

最后，在嵌入式系统中，为了使用专用代码而安装的基础系统相当大。把老代码剥离出来移植到新的操作系统上难说是个明智的主意。而将产品移植到一种新的微处理器上是说得通的。如果该专用RTOS尚未被移植到新的微处理器上，这可能是考虑使用现成RTOS的一个好时机。 

工具的相互关系 
Tool interrelationships 

一个工程师选择实时操作系统时如果不考虑其余与之相关的工具是不行的。微处理器、在线仿真器（ICE）、编译器、汇编器、连接器、调试器以及模拟器——都这样或那样地影响着操作系统。 

有些在线仿真器供应商提供其ICE与实时操作系统接口的软件。检查一下你的ICE是否能与你的RTOS协同工作，这在调试那些最隐蔽的小错误（bugs）时是很有用的。然而，重要的是要了解在线仿真器的操作对性能的影响。有时当ICE执行操作时增加了额外的开销，比如中断某行源代码在某个任务中的执行。 

对给定微处理器家族上的某种操作系统来说，很可能OS供应商只支持所有可用编译工具（包括编译器、汇编器和连接器）的一个子集。应该确认供应商支持你所用的。你应该避免我们项目组当初选择一种现成的实时操作系统所碰到的灾难。OS供应商将我们选择的RTOS以源代码的形式提供给了我们，但是我们没有考虑到的一个问题是这种RTOS与我们使用的编译器不能合作。经过六周的艰苦努力，负责修改RTOS源代码的工程师终于完成了任务。 

选择准则 
Selection criteria 

除了开发工具箱中其他工具的影响之外，如果你能很好地组织在调查研究RTOS期间所搜集的信息，作出选择就会容易一些。首先列一份可供选择的RTOS清单。到选择RTOS时，你可能已经选定了微处理器。据此你可以立即划掉不支持你的MCU的RTOS从而得到较短的清单。如果你选择了无所不在的68000或者x86系列，则需要更多的准则来帮助你作出选择。 

有了一个短的清单之后，艰难的工作才真正开始。首先，要决定对你的应用来说哪条准则是真正重要的。本文讨论了选择时要考虑的几条重要特征，然而每一个应用开发都有差异，需要认真考察到底什么是最重要的。应该根据各项选择准则列一个表，针对每个项目评价每种RTOS。甚至在填完了整张表格之后，模模糊糊的仍然不知该选哪一个，这种事情确实很难干脆果断。参与选择过程的每个人应该对这个表格展开讨论。讨论之后拿出决定或者拿出作决定的计划。 

在选择RTOS的过程中有两个基本的因素。第一组基本准则围绕着一个特定产品的细节。你现在正在使用的工具哪些要与RTOS一起继续使用？把所有的决定建立在如此简单、短视的判断上不可能最好。开阔视野，将眼光扩展到公司的整个产品线。这样的话，你需要考察RTOS与整个产品线的兼容性。该RTOS在将来的几年中仍会有所发展吗？该RTOS与你期望选用的其他微处理器兼容吗？ 

第二，你可以创建一个实现极少特性的框架，但这样做有点违背购买现成RTOS的目的。当深入RTOS的结构之后，一系列问题始终困扰着开发者。这些问题包括：该RTOS可以动态地创建和删除任务吗？一个任务能同时等待多个事件吗？任务有多少优先级？很难预料在整个应用的设计过程中需要RTOS的哪些服务。一般来说，很多特性可以实现你想要的大多数功能。如果有困难，要积极地资讯供应商的技术支持和应用工程师。如果你有使用其他RTOS的经验，现在要用一种新的OS，试着在新的RTOS中找找那些你熟悉的特性。因为不同的供应商往往用不同的方式解决同一个问题。最好选择其中与你过去熟悉的方式接近的那种。 

内核要求的最小存储器大小 
Footprint 

实时操作系统可以装入小得令人惊讶的内存中。尽管如此，当供应商给出一个内核要求的最小存储器大小时，很重要的一点是要了解这个内核中包括了什么。最小的内核经常是仅仅支持很少的特性，而典型的配置可能产生大得多的内核。如果你的设计非常在乎RAM或ROM的大小，一定要澄清这个问题。有时供应商可以提供一份详细的列表，说明了创建包含不同服务的内核分别需要多大的RAM和ROM。 

性能 
Performance 

对所有的项目来说，性能无不是个大问题。但是要了解RTOS对系统的影响却不那么容易。当你比较供应商提供的benchmark时你要明白他们是要测试什么。供应商使用的是什么评估板？微处理器的时钟频率是多少？使用的什么存储系统？存储器访问使用了几个等待周期？只有弄清楚了这些你才能作出公平的对比。 

有几种性能建模工具可以帮助你建立系统性能模型，供应商是Tri-Pacific Software和CARDtools Systems之类。随着设计的深入还要继续细化性能模型。 

软件组件和设备驱动程序 
Software components and device drivers 

在1998年11月的嵌入式系统会议上，Wind River Systems的合伙创始人之一Jerry Fiddler描绘了将来十年嵌入式系统的图景——网络化的、无所不在的普通设备。到处都会有计算机，但计算机的外表不再是一成不变的。为了使美景成真，嵌入式系统应该通过各种标准加大开发需求的互操作性，开发者可能要依赖于他人开发的组件。假如你的应用需要通信协议、服务、库或者其他组件（如TCP/IP、HTTP、ftp、telnet、SNMP、CORBA和图形），现看看哪里可以获得它们。类似的，在设计中用到现成的板卡或IC时，要确定是否可以得到设备驱动程序。 

有些操作系统供应商提供这些特性或驱动程序的方式不同，可能作为操作系统的一部分，也可能作为可选配件。另外，这些服务也可以从第三方供应商获得。与供应商交涉时，要弄清楚你的RTOS里集成了哪些组件。 

调试工具 
Debugging tools 

RTOS供应商可能有有助于找到错误的调试工具，这些错误（比如死锁、忘了放信号灯等等）用其他源码级调试器更难于发现。许多工具允许开发者在任务之间相互传递信号灯时、在任务切换时和发生中断时进行Watch（以增加CPU开销为代价）。 

少数供应商提供给用户的是集成开发环境。对主机-目标式调试器来说，应用在RAM中运行是它工作得很好。如果你希望从ROM运行代码，看看这种调试服务还有多大用处。 

标准兼容性 
Standards compatibility 

你正在考察的RTOS支持一般的标准吗？例如，RTOS服务有一个POSIX标准。即使大多数开发者不需要POSIX，这也可以作为一个考虑因素。如果你在开发安全性敏感的系统，应该考虑一下该行业所要求的安全标准。有些RTOS供应商已经开始认证他们的产品。 

技术支持 
Technical support 

购买了RTOS之后，你还需要技术支持。RTOS供应商提供多种支持渠道，其中都有电话和/或电子支持。但是要确认在你购买之后这种支持能持续多久。最好能感受一下供应商技术支持的质量如何。如果你对RTOS完全是新手，供应商的培训就很有用了。这种培训一般是上门服务。如果供应商能提供高质量的附带几个好实例的文档，那么对培训的要求就可以降低一些了。 

源代码还是目标代码？ 
Source vs. object code 

有些供应商当你购买了一个开发许可时会提供给你全部源代码。而其他的仅提供目标代码。第一次使用没有源代码的RTOS可能会令人不安。其实这两种方式都能开发出优秀的产品。如果你对RTOS的源代码大动手脚而不仅仅是作简单的修改，赶快住手，拿起电话叫技术支持吧。若对RTOS作重大的改动，岂不是违背了购买他人现成实时操作系统的初衷？ 

对那些没有源代码的来说，也不必担心无法配置内核。供应商会在头文件中给出必要的常量使开发者可以根据需要微调内核。 

许可 
Licensing 

购买某些高级的RTOS属于重大的商业事务，有许多费用要考虑。典型情况是开发工具的费用由实时操作系统供应商来承担，并为RTOS发放许可证以开发产品。有的供应商一次性地收取一大笔费用，而有的供应商的收费遍及每用户、每平台、每产品、每位置。我干过的项目经历了这两个极端。不过说不上这两种方式哪种更好，只要你明白为什么掏钱就行了。 

声誉 
Reputation 

还有一点是要了解该RTOS供应商的声誉。这也许有些困难，这里有一些建议也许有所帮助。 

首先，打电话了解他们。然而供应商肯定怕给你坏印象，因此与真正的用户交流才能得到对该操作系统质量的较好的认识。下面是一个你应该问的问题清单：
技术支持如何？ 
问题得到解答要多长时间？ 
使操作系统运转起来要多长时间？ 
你觉得对OS的投资有价值吗？ 

其次，对该公司作一番调查。下面是一个有助于你评价该公司的问题清单： 
稳定的商务活动开始多久了？ 
公司有多少职员？ 
供应商的网站上有有价值的信息吗？ 
这种RTOS在哪个行业表现最好？ 
该操作系统为哪些特殊的应用领域做过优化（如安全系统、VME卡、嵌入式PC等）？ 
公司的质量系统状况如何？ 
公司通过了ISO 9001认证吗？