要获得任何价值的答案都需要有人客观地评估所有这些问题，而这不太可能。
受欢迎程度和适用性不一定是一回事。您应该选择具有您的应用程序所需功能、可与您的开发工具配合使用并且许可模式和成本满足您的需求和预算的 RTOS。
您使用的工具链是一个明确的考虑因素 - 内核感知调试和启动项目都有助于成功的开发。一些调试器/RTOS 组合甚至可能允许线程级断点和调试。
Keil 的 MDK-ARM 包括一个简单的 RTOS，它具有基于优先级的抢占式调度和进程间通信以及一系列中间件，例如文件系统，以及 TCP/IP、CAN 和 USB 堆栈，无需额外费用（除非你想要源代码）。
IAR 提供integrations with a number of RTOS products 与 EWB 一起使用。他们的ARM EWB page 列出了具有内置和供应商插件支持的 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，并且具有合理的性能水平（虽然我提到了不同的上下文切换时间，但在 72MHz 时范围在 5 到 15 us 之间在 STM32F1xx 上）。因此，我会关注诸如成熟度（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 库在 main() 中初始化，而 C++ 调用静态全局对象的构造函数在调用 main() 之前。一些 RTOS 调用在 RTOS 初始化之前无效是很常见的，这可能会导致问题 - 特别是因为它在 RTOS 之间有所不同。一种解决方案是修改您的 C 运行时启动代码，以便在建立基本 C 运行时环境之后在静态构造函数和 main() 之前调用 RTOS 初始化。另一种解决方案是避免在静态对象中调用 RTOS。