需要在 STM32 上安装 RTOS？

Question

我正在启动一个使用 LittleVGL 作为其 GUI 库的项目。

我使用的是 STM32H743，运行频率为 480MHz。 （它的功率相当大，但只比 RAM 和闪存少一半快的东西贵 1/15%，后者本身需要额外成本的外部闪存。）

最坏情况下的屏幕绘制是 10 毫秒。 当我使用 ChromART/DMA2D 实现 LittleVGL 的块传输和填充钩子时，这会变得更好。

如果延迟达 20 毫秒，任何电路板的非 GUI 操作都不会受到影响。

如果屏幕绘制速度较慢，并且需要被更紧急的操作中断，那么对 RTOS 的需求将是显而易见的。

当所有操作都快于最紧急的最后期限时，是否有理由使用 RTOS 而不是单个无限循环？

（我不熟悉 FreeRTOS，最重要的是，我没有调试 FreeRTOS 项目的经验。）

Answer 1

我首先从问题块中挑选出主要问题：

当所有操作都快于最紧急的最后期限时，是否有理由使用 RTOS 而不是单个无限循环？

是的，有。 最重要的是：RTOS 是一种将复杂软件划分为易于（甚至微不足道！）维护的部分的方法。 这种划分考虑了 CPU 在当前软件上花费的时间。 每当您的软件在同一个 CPU/控制器上执行几个不相关的事情时，您就可以轻松应用它。 我想将这与将一个大的单体源代码分割成小的模块和函数进行比较，这些模块和函数负责处理内存和程序代码的一小部分。 相比之下，每个 RTOS 任务只负责控制器固件要做的一件事。

这是原因的微不足道的部分，我自由地回答有点不准确以突出要点。 现在是不太重要的原因：

使用 RTOS，您还可以拆分不独立运行但代表从输入数据（测量）到输出数据（设定值）的不同处理阶段的软件部分。 在现实的嵌入式系统中，您通常需要处理如此多的需求，以至于在单个主循环中实现所有需求最终会（或沿途崩溃）在某些您可以写一次但几乎无法写下的程序代码中如果您在一个多星期后返回代码，请维护（通过修复越来越小的错误，通过将软件扩展到一些新的想法和要求）。

对我来说，主要动机是使用一些 RTOS（它不一定是 freertos，但那并不是一个糟糕的开始）以便将一个整体软件分解成我的头脑能够处理的部分。

您的问题最初指向不同的方面：

我正在启动一个使用 [...] GUI [...] 的项目

我使用的是 STM32H743，运行频率为 480MHz。 （它的功率相当大，但只比 RAM 和闪存少一半快的东西贵 1/15%，后者本身需要额外成本的外部闪存。）

最坏情况下的屏幕绘制是 10 毫秒。 [...] 如果最多延迟 20 毫秒，所有 [...] 操作都不会受到影响。

如果屏幕绘制速度较慢，并且需要被更紧急的操作中断，那么对 RTOS 的需求将是显而易见的。

您是对的，使用 RTOS 的另一个原因是以或多或少的动态方式交错系统上的不同进程，以便每个任务在截止日期之前完成。 我没有调查你的具体案例的所有情况（见引文中的省略号），但我确信这个论点不适用于你目前的情况。 对于这个观点，只有一些警告：

• 您比较了单个 µC 硬件的最终价格，这些硬件可能焊接到一些现成的评估板上。 这是个好主意，我正在为私人项目做同样的事情。 但是一旦你为商业产品制作专业的嵌入式软件，你就必须考虑多个控制器的价格（取决于你的行业分支，几百到几十亿），以及 µC 本身的价格，因为它是焊接到 PCB 上的只适合您正在编程的产品。 然后可能会发生，除非您确实证明这是实现所有软件要求所需的控制器类，否则没有人会授予您 STM32H7 之类的东西。

• 您只向我们描述了STM32驱动的屏幕/GUI，没有描述屏幕的用途。 通常，设备用途意味着对与控制器 I/O 相关的外围设备有一些实时要求。 然后，您可能会被迫以少于 10-20 毫秒的延迟来处理程序的某些部分。 这导致您首先使用中断，然后（除非您想处理具有大量手动中断抑制的上下文之间的每个数据传输）使用 RTOS。

也许我错了，你没有任何限制来执行超过 20 毫秒的任何反应，或者有一天用更便宜的 STM32 替换 STM32H7。 然后，剩下的唯一争论是处理复杂性。 当然，您可以尝试继续使用主循环。 只要需求足够简单，以至于您可以使用一种“全脑”架构来处理所有需求，您就会成功。

感谢那些在早期评论中贡献部分答案的人：@Lundin、@Clifford