我正在寻找 Arm M/R 系列的 RTOS（用 C++ 开发）？有人可以为 ARM Cortex-M 或 R 系列推荐好的 RTOS 吗？谢谢你。
问问题
4115 次
1 回答
8
获得任何价值的答案都需要有人客观地评估所有这些，而这是不太可能的。
流行度和适合度不一定是一回事。您应该选择具有您的应用程序需要的功能、可与您的开发工具配合使用并且许可模型和成本满足您的需求和预算的 RTOS。
您使用的工具链是一个明确的考虑因素——内核感知调试和启动项目都有助于成功的开发。一些调试器/RTOS 组合甚至可能允许线程级断点和调试。
Keil 的 MDK-ARM 包括一个简单的 RTOS，具有基于优先级的抢占式调度和进程间通信以及一系列中间件，例如文件系统，以及 TCP/IP、CAN 和 USB 堆栈，无需额外费用（除非您想要源代码）。
IAR 提供与许多用于 EWB 的 RTOS 产品的集成。他们的ARM EWB 页面列出了具有内置和供应商插件支持的 RTOS。
我个人使用过 Keil RTX，但改用 Segger embOS，因为当时 RTX 在 Cortex-M 上还不够成熟，给我带来了一些问题。然而，RTX 的测量上下文切换时间比 embOS 快。值得注意的是，IAR 的 EWB 与 embOS 集成，因此如果您尚未投资工具链，这可能是更简单的途径。我还在 Cortex M 上评估了 FreeRTOS（与 OpenRTOS 相同，但具有不同的许可和支持模型），但发现它的 API 不如 embOS 复杂和完整，并且上下文切换时间明显更慢。
embOS 具有与 RTX 类似的中间件支持，但需要额外付费。然而，我设法挂接了另一个开源文件系统和处理器供应商提供的 USB 堆栈，在 embOS 和 RTX 中都没有任何问题，因此中间件支持可能并非在所有情况下都至关重要。
其他选项是 Micro C/OS-II。它再次获得中间件支持，但需要额外付费。它的调度程序比大多数其他调度程序更原始，要求每个线程都有不同的优先级，并且不支持循环/时间片调度，这对于非实时后台任务通常很有用。它主要通过详细描述内核实现的相关书籍而流行。较新的 Micro C/OS-III 克服了调度程序的限制。
另一方面，eCos 是一个完整的 RTOS 解决方案，具有高端功能，使其适用于您可能选择 Linux 但需要实时支持和占用空间小的许多应用程序。
关键是您可能会认为 RTOS 支持抢占式调度和 IPC，并且具有合理的性能水平（尽管我提到了不同的上下文切换时间，但在 STM32F1xx 上，72MHz 时的范围在 5 到 15us 之间）。因此，我会关注诸如成熟度（RTOS 可用于您的目标的时间——您甚至可以查看发行说明以了解它达到成熟度的速度以及可能存在哪些问题）、工具集成、API 是否适合您需要一个预期的软件架构、来自供应商或第三方的中间件支持以及许可（您负担得起，并且您能以您想要的方式合法地部署它吗？）。
关于使用 C++，大多数 RTOS 都提供了 C API（甚至是用 C++ 编写的 eCos）。这并不是一个真正的问题，因为 C 代码可以在二进制级别与 C++ 互操作，但是您可以有效地利用 C++ 的强大功能来降低 RTOS 选择的关键性。我所做的是定义了一个 C++ RTOS 类库，它提供了一个通用 API，提供了所需的设施；例如，我有诸如cTask, cMutex, cInterrupt, cTimer,之类的课程cSemaphore等。应用程序代码写入此 API，并为任意数量的 RTOS 实现类库。这样，由于类库充当抽象层，因此可以将应用程序代码移植到许多目标和 RTOS 的很少或没有变化。我已经成功地为 Windriver VxWorks、Segger embOS、Keil RTX，甚至 Linux 和 Windows 实现了这个类库，用于仿真和原型设计。
一些供应商确实为其 RTOS 提供了 C++ 包装器，例如 Accelerated Technology 的Neucleus C++ for Neucleus RTOS，但这并不一定提供您可能需要在不更改应用程序代码的情况下更改 RTOS 的抽象。
在 RTOS 中进行 C++ 开发需要注意的一件事是，大多数 RTOS 库都是在C++ 在调用main()之前main()为静态全局对象调用构造函数时初始化的。一些 RTOS 调用在 RTOS 初始化之前无效是很常见的，这可能会导致问题 - 特别是因为它在 RTOS 之间有所不同。一种解决方案是修改您的 C 运行时启动代码，以便在静态构造函数之前调用 RTOS 初始化，但在建立基本 C 运行时环境之后。另一种解决方案是简单地避免在静态对象中调用 RTOS。main()
于 2012-08-05T13:39:46.917 回答