RTOS与Bare Metal在MCU编程方面的优势？

请注意：这个问题专门提到了两个RTOS，但更为通用，以前曾为嵌入式RTOS编写过C代码并且直接在MCU上运行其软件的任何人都可以回答。

我有兴趣了解有关嵌入式RTOS的更多信息并为其编写应用程序。我目前正在查看Embox和RIOT，因为它们是开源的，现代的，活跃的并且似乎有出色的文档。我的目标分为两个阶段：第一阶段是弄清楚如何将这些OS编译并刷新到MCU（可能是AVR或ARM）。然后，第2阶段将编写一个简单的C程序（基本上是一个无头的守护程序），该程序会随着时间的流逝而发展为“业余应用程序”。然后，我将该程序刷新/部署到同一MCU，从而成功部署了一个由Embox / RIOT和位于其之上的应用程序组成的应用程序堆栈。

在走上任何最终导致死胡同的道路之前，我偶然发现了这篇文章，很好地解释了为什么用C /汇编器编写并闪存到MCU的实时应用程序真正不需要它们下面的RTOS。 。

所以现在我真的很困惑，并且质疑我对计算理论的一些基本理解。我想我想首先决定是否使用Embox / RIOT，或者：

• 保持进度，并在两个OS +应用程序的MCU上使用“应用程序堆栈”；要么
• 请留意本文的警告，并选择运行我的应用程序“裸机”的MCU

显然，前者需要做更多的工作，因此最好还是有一个很好的理由/选择那条路线。因此，我想问：这些（和类似的）嵌入式RTOS为MCU / C应用程序开发人员提供的真正好处是什么？使用RTOS，我的C应用程序可以从哪些特定功能中受益（也许不重新发明轮子？）？抛弃RTOS并裸机失去了什么？

我在这里要求具体的例子，而不是当您进入RTOS的Wikipedia条目时获得的媒体宣传；-)

单片机程序由许多任务组成。假设您要制作一个计算机控制的望远镜支架。任务将是：

• 从USB串行缓冲区中检索输入的新字节。
• 检查我们是否已收到完整的命令。
• 如果是这样，请执行该命令。
• 读取传感器的当前望远镜位置。
• 设置适当的输出以控制电机的下一步。

这是一组相当典型的任务，用于您将要使用微控制器的事情，并且非常容易通过无限循环进行管理，例如：

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

如果继续添加和添加功能，最终会遇到一些您要为其创建抽象的常见问题，例如：

• 缓冲区溢出，因此您要确保任务可以在溢出之前中断其他任务。
• 您想通过在不需要任何东西时休眠来节省电池。
• 您要确保所有任务都能得到公正的对待。如果readSensors花费的时间太长，您希望能够中断它并稍后再返回。
• 您希望能够仅重置一项任务而不影响其他任务。
• 您希望一个任务中发生内存泄漏或其他错误，而不执行其他任务。
• 您希望能够为不同的任务赋予不同的优先级。
• 您希望能够将不受信任的任务沙盒化。
• 您希望能够以不同的速率执行任务。也许您的传感器每秒只能读取10次，但是您想每秒执行100次电机步进。

这些项目中的一两个可以相对容易地手动处理。如果您经常遇到足够多的此类问题，以至于可以将它们普遍化为库，那么您基本上已经重新发明了RTOS。如果您程序的任务管理足够复杂，那么即使您不使用现成的RTOS，您最终也将最终做出糟糕的尝试。

但是，以我的经验，想要RTOS的生产线与想要微处理器而不是微控制器的生产线非常接近。如果您预计固件会变得如此复杂，通常最好从一开始就走微处理器路线。

我为ARM Cortex-M0编写了自己的协作式多线程库。

仅仅花了几页代码，而其第一个版本的编写和调试时间却不超过一天。

自行开发的最大优点是您知道代码，可以将其移植到RTOS可能不支持的芯片上。另外，您花更少的时间思考诸如“我尝试同时使用功能A和B会崩溃吗？”之类的问题。自编写代码以来，您就知道答案了。

线程化是您从RTOS获得的主要东西，事实证明，实现自己并不是什么大问题。您很少需要RTOS的许多功能。但是，如果您发现要求很严格，但事实确实如此，则可以使用RTOS。