我正在寻找Arm M / R系列的RTOS（用C ++开发）？ 有人可以推荐ARM Cortex-M或R系列的优秀RTOS吗？ 谢谢。
答案 0 :(得分：7)
获得任何价值的答案需要有人客观地评估所有价值，这是不可能的。
人气和适用性不一定是一回事。您应该选择具有您的应用程序所需功能的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运行时启动代码，以便在静态构造函数和main（）之前调用RTOS初始化，但是在建立基本C运行时环境之后。另一种解决方案是简单地避免在静态对象中进行RTOS调用。