问需要在STM32上使用实时操作系统吗？

EN

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

是否有理由使用实时操作系统，而不是单一的无限循环，当所有操作都比最紧急的截止日期更快的时候？

是的，有。最重要的是: RTOS是将复杂的软件分割成简单(甚至是琐碎)的一种方式！来维持。此分区考虑CPU在当前软件上花费的时间。当您的软件在同一个CPU/控制器上做几件不相关的事情时，您可以很小地应用它。我想将这与将一个大的单块源代码分解成小模块和函数进行比较，这些模块和函数处理内存和程序代码的一小部分。相反，每个RTOS任务都负责由控制器固件完成的一件事情。

这就是原因中微不足道的部分，我自由地回答了一些不精确的问题，强调了要点。现在，出于不那么琐碎的原因：

使用RTOS，您还可以将不独立运行但表示从输入数据(度量值)到输出数据(设置值)的不同处理阶段的软件分割。在一个现实的嵌入式系统中，您通常需要处理太多的需求，以至于在一个主循环中实现所有这些需求，最终都会在一些程序代码中(或者沿途崩溃)，您可以只写一次，但是如果您在一周后返回到代码中(通过修复越来越小的but，将软件扩展到一些新的想法和要求)，那么您很难维护这些代码。

对我来说，使用一些RTOS的主要动机(它不一定是freertos，但这一点一点也不坏)，以便将一个完整的软件分解成我的头脑能够处理的部分。

你的问题最初指向一个不同的方面：

我要开始一个使用.桂..。

我使用的是STM32H743，运行频率为480。(这款手机的耗电量相当大，但仅比速度快、内存和闪存少的东西贵1/15%，后者本身就需要额外的外部闪存。)

最坏情况下的屏幕绘制是10毫秒。..。没有一个..。如果延迟至多20毫秒，操作就会受到影响。

如果屏幕绘制速度较慢，并且需要被更紧急的操作所中断，则显然需要一个RTOS。

您是对的，使用RTOS的另一个原因是以或多或少的动态方式将系统上的不同进程交织在一起，这样每个任务都能在其截止日期之前完成。我没有调查你具体案例的所有情况(见引文中我的精辟之处)，但我确信这个论点不适用于你目前的情况。只是对这个观点提出几个注意事项：

• 您比较单个C硬件的终端价格，可能是焊接到一些现成的标准板上。这是个好主意，我对私人项目也是这样做的。但是，一旦您为商业产品制作了专业的嵌入式软件，您就必须考虑多个控制器的价格(取决于您的行业分支，大约有数百亿美元)，以及C本身的价格，因为它被焊接到一个正好适合您正在编程的产品的PCB上。然后可能会发生这样的情况:没有人会给你一个STM32H7--除非你真的证明这是实现所有软件需求所需要的控制器类。

• --您只向我们描述了由STM32驱动的屏幕/GUI，而没有描述屏幕的用途。通常，设备的用途意味着与控制器的I/O相关联的外围设备上的一些实时需求，然后，您可能被迫以10-20 ms以下的延迟处理程序的某些部分。这导致您首先使用中断，然后(除非您希望处理大量手动中断抑制的上下文之间的每一次数据传输)使用RTOS.

。

也许我错了，而且你没有任何限制去执行任何超过20 ms的反应，或者在某一天用更便宜的STM32取代STM32。那么，剩下的唯一论据就是处理复杂性。当然，您可以尝试继续使用主循环。只要需求足够简单，你就能用一种“全神贯注”的架构来处理所有的事情，你就会成功。

感谢那些在早些时候的评论中贡献了部分答案的人：@Lundin，@Clifford