虽然 RTOS 变得非常流行，但团队选择 RTOS 的方式也受到额外关注。对于大多数团队来说，当他们选择RTOS 时，考虑的一个标准是成本。但作为嵌入式开发人员，我们应该评估几个不同的标准，不仅要使用数据，还要遵循确保成功和可重复性的流程。

　　在这篇文章中，我们将研究在为应用程序选择 RTOS 时考虑的七个标准。

　　1.) 安全

　　对于任何将要连接到互联网的设备，选择一个已经通过安全认证并且专为安全而构建的 RTOS 是必须的。RTOS 的安全认证相对较新，但对于任何希望确保其系统中的每个组件的设计都考虑到安全性的团队来说，这将是一个重要标准。一个直接的例子是验证 RTOS 是否具有至少一级的 Arm 平台安全架构 (PSA) 认证。

　　2.) 生态系统

　　围绕 RTOS 拥有强大的生态系统对于确保成功至关重要。例如，开发人员应该关注并提出以下问题：1.这个 RTOS 在业界被高度采用吗?2.它是否支持主要的硬件架构?3.它有一个充满活力的社区吗?

　　一个强大的生态系统将确保 RTOS 不仅在很长一段时间内得到使用和支持，而且还可能决定团队是否能够快速获得社区的支持。

　　3.) 特点

　　RTOS 上可用的功能会产生很大的不同，不仅会影响调试所花费的时间，还会影响软件架构。嵌入式开发人员需要查看其 RTOS 中可用的功能并验证它：

　　支持静态内存分配

　　具有实时追踪功能

　　与目标内存保护单元 (MPU) 集成

　　4.) 供应商

　　供应商，即创建和维护 RTOS 的公司，也应该仔细考虑。快速的网络搜索将显示存在 100 多个 RTOS，其中许多不再受支持或使用。团队需要仔细查看 RTOS 供应商并问自己：1.这家公司经营了多久，五年后他们还会经营吗?2.他们会快速响应支持票和问题吗?3.他们是否提供高质量的代码和文档？

　　没有什么比选择 RTOS 并让你自己的设备解决问题或问题更糟糕的了。RTOS 供应商应被视为对产品成功至关重要的战略合作伙伴。

　　5.) 中间件

　　RTOS 在某种程度上为应用软件提供了基础。该基础是产品开发难题的一部分。这个难题还包括其他组件，例如低级驱动程序、文件系统、图形用户界面、TCP/IP 堆栈、加密引擎等等。开发人员应评估与其 RTOS 直接兼容的中间件。

　　现在，你可能会认为可以将任何中间件与任何 RTOS 一起使用，并且兼容性不是问题。确实如此，但如果你选择一个经过验证并支持中间件且已提供示例的 RTOS – 开发将会更快、更顺畅。你甚至可能会很幸运地发现 RTOS 和中间件是使用相同的编码标准编写的，并且具有一致的外观和感觉。

　　6.) 性能

　　这是嵌入式开发人员将关注的明显标准之一。性能包括以下标准：内存占用;ROM 占用空间;可靠性和确定性。

　　在某种程度上，RTOS 之间的性能开始成为一个争论点。如果你正在以 200 MHz 或更高的频率运行现代处理器，那么在这里或那里丢失几个时钟周期并不重要。但是，如果你使用的是运行在 100 MHz 以下的更传统的微控制器，则每个时钟周期都会计算在内。重要的是要考虑你的应用程序并确定性能是否是一个问题。

　　7.) 成本

　　是的，成本！每个管理者和 bean 计数器列表中最重要的一个因素！RTOS 的成本很重要，但是当你将其与开发和维护的劳动力进行比较时，即使是大多数需要版税的商业 RTOS 也几乎没有小数点。

　　结论

　　更重要的是评估所有这些标准并选择最能满足应用程序和嵌入式开发团队需求的 RTOS。RTOS 的成本可能是免费的，但又可能不是，只有仔细评估所有标准，开发团队才能做出正确的选择。