选择在嵌入式应用中使用的实时操作系统(RTOS)似乎是一个很小的决定。毕竟，所有实时操作系统不都是一样的吗？随便选一个，丢进项目里，有什么不好？事实证明，目前有超过100种不同的RTOS可供嵌入式开发人员在其产品中使用。既有小型的开源解决方案，也有大型的安全关键型认证解决方案。选择哪一种方案会极大地影响系统的性能、成本以及是否能取得长期有效的成果。在今天的文章中，我将分享一些为您的应用选择合适RTOS的注意事项。剧透警告：这不是一个万能的方案！
如果测量多个RTOS的实时性能，您可能会惊讶地发现没有两个RTOS的性能是相同的。事实上，如果仔细观察，就会发现RTOS之间的性能特征可能存在巨大差异。例如，下面的图1是我几年前测量的两个RTOS之间的比较。每个测量值都是RTOS在30秒时间内执行的迭代次数。数字越高，迭代次数越多，RTOS的性能也就越高。
图1–两种RTOS在不同功能领域的性能特征。(来源：Beningo Embedded Group)。
花点时间仔细看看这些数据。您就会发现，在大多数类别中，一种RTOS的性能比另一种至少要好300%！这意味着一个RTOS可以在三分之一的时间内执行与另一个RTOS相同的功能！同时也意味着执行RTOS内核的时间更少，而运行应用代码或让系统进入低功耗睡眠模式的时间更多。
虽然许多团队忽视了RTOS的性能，并且使用的RTOS可能会占用不必要周期，但这并不是唯一需要考虑的细节。仅使用性能数据来选择RTOS也会出现问题。例如，旨在提供安全执行环境的RTOS的性能可能会低于不提供安全执行环境的解决方案。验证输入、切换到安全执行环境等可能需要额外的时钟周期。在选择RTOS时，必须全面考虑整个RTOS功能集。
这些功能可能包括内存管理、安全性、低功耗等。例如，我们倾向于在嵌入式系统中静态分配内存，以避免堆碎片(heap fragmentation)和非确定性内存分配等问题。但是，如果使用的是资源有限的处理器，则可能需要在运行时动态分配和释放内存。在这种情况下，就需要找到一种支持内存块池的RTOS。块池是一项允许确定性动态内存分配的功能！
我经常建议团队创建一个他们需要RTOS支持的关键功能列表。在选择RTOS时，可以使用这些功能和重要性权重来帮助他们分析RTOS是否符合他们的需求。
每个项目对其RTOS都有自己的特定需求和标准。然而，有一个重要的考虑因素是如何在硬件之外处理RTOS。我的意思是，现代嵌入式软件开发周期不仅仅依赖于其目标硬件来编写软件。硬件通常要到开发周期后期才能获得。相反，您必须决定是否抽象化RTOS，以便可以将其替换出来并在主机上运行，或者在您的RTOS需要支持的目标上运行，如Win32、MacOS和Linux。
我知道这听起来可能很奇怪。但是，您的应用代码必须在多个环境中运行才能成功编写出可持续部署的可测试、可扩展的软件。您可以在硬件上运行应用来测试，但这比仅在托管环境中运行需要更多的工作。如今，没有理由不对硬件进行抽象化，并在硬件可用之前验证应用的代码是否能正确运行。事实上，如果能够成功利用测试驱动开发等现代技术，那么在主机上进行测试将缩短调试时间，甚至无需调试。
当选择RTOS时，您需要考虑很多因素。在选择RTOS系统时，我会从几个大类入手：
这些类别可以进一步细分为选择标准。例如，在"供应商"类别下，您可能需要考虑以下内容：
每个类别都会有一个类似这样的标准列表，它可以帮助您了解RTOS中的需求，并帮助您确定这些标准的重要性。例如，在工程团队类别下，可能会看到“最大限度地促进专业成长”之类的内容。虽然所选RTOS能帮助工程团队的工程师和个人成长是件好事，但这可能不如RTOS的许可条款重要。在选择中应用加权系统是一个好主意，这样次要的问题就不会成为主要的决定因素。
正如您在这篇文章中所看到的，选择RTOS不仅仅是选择今年最流行的版本。各种RTOS之间的差异可能是惊人的。面对超过100种RTOS，要想从中选出几种，就不能仅仅选择供应商目前支持的任何一种。(尽管他们提供的可能正是您需要的解决方案)。作为工程师，我们应该对所使用的RTOS做出工程决策！这包括制定标准、检查数据以及做出明智的工程决策。任何其他方式，都不是工程师所该做的，那些只是抽签看运气！
(原文刊登于EDN姊妹网站Embedded，参考链接：Selecting the right RTOS for your application，由Ricardo Xie编译。)
最前沿的电子设计资讯
