如今，业界充斥着关于开源软件和 Linux 的大量炒作。这些讨论的重点是 Linux 如何代表着对微软桌面霸主地位的第一个主要威胁。然而，开源软件也正在进入嵌入式实时市场。去年，Cygnus Solutions 推出了一项名为 eCos（嵌入式 Cygnus 操作系统）的新计划。eCos 以开源和免版税两种形式提供。如今，eCos 已被超过 10,000 名开发人员下载。为什么 Cygnus 没有选择 Linux 作为其开源实时替代方案？本文将比较和对比这两种替代方案，并解释为什么每种方案都可以在您的实时解决方案中占有一席之地。

要了解 Cygnus 为什么开发自己的实时操作系统 (RTOS)，您必须了解市场上的产品以及 Cygnus 希望通过其 RTOS 从事的工作类型。

Cygnus 成立于 1989 年，有效地开创了开源商业模式。虽然 Linux 今天是开源的典范，但 Linus Torvalds 实际上受到了早期开源项目的启发，尤其是 GNU C 编译器 (gcc)。自由软件基金会 (FSF) 的 Richard Stallman 于 1987 年年中首次发布了 GNU C 编译器，当时的科研人员 Michael Tiemann 很快采用了它。Tiemann 对 GNU C 编译器的贡献，包括移植到多个 RISC 和 CISC 微处理器、完整的本机代码 C++ 前端以及用于指令调度和分支调度的优化过程，对代码开发和支持的需求超过了他（或任何其他 gcc 黑客）在业余时间可以提供的。Tiemann 认为这种需求并非偶然，而是根深蒂固的经济原则的结果，因此创立了 Cygnus 以证明这一点。（请参阅 Michael Tiemann 在 O'Reilly 1999 年出版的《开源：来自开源革命的声音》中的“Cygnus Solutions 的未来”。）

Cygnus 几乎从一开始就涉足实时业务。当 GNU C 编译器因运行时速度和紧凑代码而获得声誉时，它引起了实时开发人员的注意。这些精明的开发人员利用开源集市独有的自由，要求并贡献了对编译器的进一步增强，使其成为更好的选择。Cygnus、他们的客户和网络社区都看到了集市的力量。

早期，Cygnus 认为配置工具是使单个源代码库能够支持许多微处理器的关键技术之一。他们创建了“configure”脚本（著名的“configure; make”过程的一半，用于构建 FSF 和 Linux 应用程序和实用程序），为真正的多平台解决方案打开了大门。许多依赖嵌入式处理器项目的公司都在处理器之间快速转移，以获得新功能或在更小的封装中获得相同的功能。因此，GNU C 编译器今天支持大约 50 个处理器，并且有 125 种主机-目标组合可用于交叉编译。两年后，Cygnus 可能会看到它将使用 gcc 支持的处理器发生 90% 的更替。他们一年可能会编写 24 个新的处理器端口，对于一家甚至不拥有其支持的产品的公司来说，这是一个巨大的产量。

与此同时，Cygnus 孜孜不倦地寻求客户的需求和愿望清单。他们必须了解他们为什么获得或失去销售额。到 1995 年，他们知道他们的客户需要标准化的运行时支持，该支持与主机上的 GNU gcc 编译器、gdb 调试器和工具完全集成。运行时支持需要包括 C 库、硬件抽象层 (HAL)、调试器支持和各种 RTOS 功能。与 gcc 一样，可移植性是一个关键要素，因为它必须适用于各种架构和评估板。

在进军 RTOS 业务时，Cygnus 必须考虑自身的优势和劣势。从 1995 年种类繁多的专有闭源 RTOS（超过 120 个）来看，任何人都可以通过专有 RTOS 赚钱。至少，许多人会这样认为。实际上，RTOS 就像一家餐厅，除非您确切知道自己在做什么，否则这真的是一种快速破产的好方法。

Cygnus 需要的是一个开源 RTOS。许多产品实际上非常接近。通常，用户可以访问源代码，但供应商拥有它，并且您在购买产品后才能看到源代码。购买的一部分是不披露协议，该协议阻止您与其他相同产品的用户交易改进。这些约束与开源模式格格不入。

许多 Linux 变体提供实时功能，所有这些都是开源的。可能最著名的是 Victor Yodaiken 的 RTLinux。Linux Embedded 网站上列出了更多。任何 RTOS 都必须是高度可配置的，因为嵌入式项目在非常不同的硬件上运行，几乎总是定制硬件。如果您认为 PC 差异很大，那么您还没有看过嵌入式项目。

举例来说，Linux 可能支持无限数量的某种资源——例如，互斥锁或计时器——或者它可能提供固定但非常大的数量。它必须提供这种灵活性，因为设计人员不知道用户将运行哪些应用程序。这种灵活性是有代价的：支持它的资源（例如内存）或生成新资源的代。嵌入式项目设计人员确切知道项目需要多少东西，因此他可以在编译之前选择该数量。嵌入式项目将运行时灵活性换取编译时灵活性，并获得简单性和可靠性。因此，除了开源之外，Cygnus 还需要一个易于配置的 RTOS。

提供实时功能与提供功能齐全的 RTOS 不同。要了解原因，让我们看一下实时编程和项目。

Cygnus 产品营销总监 Dean Koester 认为存在各种各样的实时应用程序。它们在整个频谱中根据其要求而变化。我们将通过检查两端来研究 Koester 的频谱，并了解为什么 RTLinux 和 eCos 会落在频谱中的位置。与此同时，我们将研究其中一些要求的经济影响。

“实时”一词已成为流行语，例如“实时股票报价”。如果纽约证券交易所的行情落后一个小时，那么您的报价就不是实时的，就是这样。根据 Koester 的说法，实时意味着每次都在按时完成工作。不是有时，或大部分时间，而是每次。这意味着您的主要关注点不是平均响应时间，而是最坏情况下的响应时间。

举一个简单的例子：一个处理器根据一个模数转换器的输入控制一个伺服系统。处理器读取 A/D 转换器并相应地调整伺服系统。根据数据绘制漂亮的图片或将其洗牌到日志文件中是次要的。

Linux，正如 Linus Torvalds 和他的内核黑客团队所提供的那样，根本不是一个实时操作系统，也从未打算成为一个实时操作系统。它旨在提供最佳平均响应时间。当 Linux 负载过重时，它会优雅地降低所有任务的性能。这对于实时计算是不可接受的。数据采集和控制功能必须每次都按时响应。它们不能降低性能，无论是否优雅。

RTLinux 对此的响应是编写一个最小的 RTOS，然后在最小的 RTOS 下将 Linux 作为后台任务运行。只要实时功能正在完成，并且有剩余资源，就允许 Linux 运行分配给它的任何任务。典型的 RTLinux 应用程序运行一个或两个实时任务。它们收集数据并将其塞入 FIFO。所有处理都在后台完成，使用 Linux 和随附的所有简洁的编程工具。

这使得 RTLinux 适用于我们可能称之为“桌面实时”的场景：数据收集，其中即使您在应用程序中不使用 Linux，也可以接受数百兆字节的 Linux 等开销。这意味着应用程序中，典型的台式计算机及其键盘、视频显示器（甚至运行 X）和其他无关进程是可接受的开销。这里的极端情况是一个学生项目，该项目收集一些模拟数据流并使用它们来控制某些设备。

虽然 RTLinux 非常适合桌面实时，但它绝不仅限于桌面。在精简的 PC 硬件上运行的 RTLinux 应用程序可以嵌入到产品中。

RTLinux 还为实时编程提供了非常快速的开发。数据收集驱动程序是一个 Linux 模块，这意味着您可以删除它、重新编译它并在不重新启动的情况下重新插入它。所有收集后数据消息传递都是使用我们都知道和喜爱的久经考验的工具完成的，例如 Perl 和 Ghostscript。

此外，RTLinux 还提供非常廉价的研发经济性。如果您有一台安装了 Linux 的台式计算机，那么您已经拥有了实施最小 RTLinux 项目的大部分资本成本。如果体积和空间是限制因素，您可以花钱购买定制的 PC 兼容硬件。许多 RTLinux 项目都会这样做。

然而，Cygnus 追求的不是“桌面实时”。“嵌入式”一词最初意味着将微处理器放入某些产品中，使其不明显是计算机在那里。一个典型的例子是复印机。即使是简单的家用复印机也有一些微控制器在运行它。但它看起来不像计算机：没有 QWERTY 键盘、没有显示器、没有 GUI。嵌入式应用程序的关键在于绝对不能接受任何不必要的开销。

有两种经典的嵌入式项目范例。第一种是批量生产的产品，将生产数万甚至数百万件。由于涉及生产运行，预先花费数十万美元将单个单元的成本降低十分是经济的。汽车制动控制器是一个典型的应用。

另一个经典的嵌入式项目是客户是欧洲航天局 (ESA) 或国防部，并且花费大量资金来减轻一克重量被认为是经济的。例如，喷气推进实验室的火星探路者号或旅行者号飞船符合这种范例。

Cygnus 认为，从头开始构建用于嵌入式应用程序的 RTOS 比从 Linux 中剥离不必要的组件以生成适用于嵌入式项目的 RTOS 更简单。eCos 旨在缩减到只有几千字节的代码，如果您只需要 HAL 和 C 库。尝试将 Linux 剥离到如此远的程度会产生您无法识别为 Linux 的东西。

适用于嵌入到生命攸关的应用（例如汽车刹车或心脏起搏器）中的 RTOS 必须是可证明的可靠。计划高产量运行的应用程序也必须高度可靠，因为更换成本远高于确保产品可靠性的成本。

可靠性的一个关键组成部分是简单性：RTOS 越简单，您证明其可靠性的速度就越快，因为需要测试的交互越少。因此，您可能在通过 RTLinux 进行快速原型设计中获得的上市时间，可能会在证明您的产品可靠性方面失去。

如果应用程序要在电池或任何其他功率受限的环境（太阳能电池板、放射性同位素动力发电机等）中运行，则会考虑许多因素。显而易见的是硬件必须能够在功率有限的情况下运行。一般来说，处理器功能越强大，功耗就越高。RTOS 施加的开销越大，处理器必须越强大才能完成其工作。这转化为更短的电池寿命，这转化为恼怒的客户和销售损失。

大多数电池供电设备都具有极端的尺寸和重量限制。手机就是一个很好的例子。如果您的“功能齐全”的 RTOS 具有较大的 ROM 或 RAM 占用空间，那么您将为该占用空间付出代价，不仅是内存成本，还有电池寿命。同样，如果您的 RTOS 效率不高，并且比另一个 RTOS 需要更多周期才能完成相同的工作，那么即使它满足您的实时约束，它仍然可能会超出您的功率预算。

不太明显的是电源故障的影响。例如，如果用户刚刚在她的手机中输入了一个新的电话号码，并且电池没电了，如果新号码没有保存，她会很恼火。您无法承受电源故障导致的文件损坏。这意味着设计人员在按下最后一位数字的时间和将数据保存到永久存储之间有一个很短的时间窗口。

Linux 以其对非易失性存储的惰性写入以及文件系统中的多用户开销，被 Cygnus 认为不可接受。电池供电的应用程序需要从头开始设计的 RTOS，以实现速度、效率和完全的可靠性。

驱动几乎所有实时项目的一件事是上市时间（即使是学生项目也受成绩时间驱动）。Cygnus 提供了两个将吸引嵌入式处理器工程师的功能。

首先是易于配置。从 GNU 编译器中吸取教训后，Cygnus 提供了编译时配置工具，允许用户选择要包含或排除的组件。此外，组件本身是可配置的，您可以完全访问每个组件的源代码，并可以自定义它以适合您的应用程序。

eCos 在全球范围内实现了 Linux 通过其驱动程序实现的模块化。Linux 受管理问题和最小化接口的驱动而走向模块化。eCos 受客户对可配置性的渴望的驱动而走向更大的模块化。碰巧的是，两者都将可移植性作为副产品获得，而 eCos 将从其模块化实现的去中心化管理中获益。这种去中心化对于开源产品的成功至关重要；RTOS 供应商使其难以访问其源代码，但他们错过了这一点。（请参阅 Linus Torvalds 在 O'Reilly 1999 年出版的《开源：来自开源革命的声音》中的“Linux Edge”。）

eCos 目前在 Linux 上使用脚本配置，并通过 Microsoft Windows 的 GUI 程序配置。

图 1。

一些旨在面向消费市场的 RTOS 确实提供了添加应用程序框架（如 Java 虚拟机）的功能。同样，开源和集市也来救援：第三方虚拟机已被移植到 eCos，这允许动态添加和删除应用程序。

Cygnus 提供的另一个功能是其客户支持。当上市时间是一个重要因素时，快速、专业的支持至关重要且物有所值。Cygnus 支持 gcc 的经验将在这里派上用场。

这并不是说您必须购买 Cygnus 的支持才能使用 eCos。Cygnus 为 eCos 用户提供了一个电子邮件列表，不收取任何费用。它还在万维网上发布源代码。如果您想通过查看代码来支持自己，您也可以这样做。

Koester 认为 eCos 和 RTLinux 实际上并不竞争。RTLinux 的市场是桌面实时和其他高端应用程序，在这些应用程序中，开销较小或根本不是一个因素。Cygnus 的 eCos 的市场是嵌入式处理器市场，其中开销是一个主要因素。

eCos 和 RTLinux 都有自己的位置，Koester 说，它们可以共存。对于许多实时应用程序，RTLinux 是过度的，以牺牲功率、价格和产品性能为代价。eCos 可以被推向实时频谱的更高端，但代价是失去了使 RTLinux 如此有吸引力的标准桌面应用程序。

虽然 Linux 和 eCos 在它们旨在服务的市场中非常不同，但实际上它们在基本概念上是相似的。每个都是单内核。两者都使用模块化，并且两者都是可移植的，因为两者都体现了硬件层的某种抽象。

Koester 说，最终，是消费者需求驱动了 RTOS 需求。消费者需求千差万别，因此任何数量的开源 RTOS 都有空间。

资源