我正在启动一个使用LittleVGL作为其GUI库的项目。
我使用的是STM32H743，运行频率为480MHz。 （它的功能相当强大，但仅比内存和闪存少的一半快一半的东西贵$ 1/15％，这本身就需要额外成本的外部闪存。）
最坏情况下的屏幕绘制为10毫秒。当我使用ChromART / DMA2D实现LittleVGL的填充和填充钩子时，这种情况会变得更好。
如果延迟最多20毫秒，则该板的任何非GUI操作都不会受到影响。
如果屏幕绘制速度较慢，并且需要通过更紧急的操作来中断，那么显然需要RTOS。
当所有操作都比最紧急的截止日期快时，是否有理由使用RTOS而不是单个无限循环？
（（我不熟悉FreeRTOS，最重要的是，没有调试FreeRTOS项目的经验。）
我首先从问题栏中选择主要问题：
当所有操作都比最紧急的截止日期快时，是否有理由使用RTOS而不是单个无限循环？
是，有。最重要的是：RTOS是一种将复杂软件划分为易于维护（甚至微不足道！）的程序的方法。该分区考虑了CPU在当前软件上花费的时间。只要您的软件在同一CPU /控制器上执行多项无关的操作，就可以轻松应用它。我想将其与将大型的整体源代码分成小的模块和函数进行比较，这些模块和函数仅占用很小一部分的内存和程序代码。相比之下，每个RTOS任务都需要控制器固件来完成一件事情。
这是原因的琐碎部分，我可以自由回答一点点不精确的内容以突出重点。现在出于不太重要的原因：
使用RTOS，您还可以分割软件的各个部分，这些部分不是独立运行的，而是代表从输入数据（测量）到输出数据（设置值）的不同处理阶段。在一个现实的嵌入式系统上，您通常必须照顾到如此多的要求，以致于在一个主程序中实现所有这些操作最终会（或者在整个过程中崩溃）一些可以一次性写下来的程序代码，但几乎很难做到如果您在一周后返回代码，请进行维护（通过修复越来越小的错误，将软件扩展到一些新的想法和要求）。
对我来说，使用某些RTOS的主要动机（不一定是freertos，但这根本不是一个坏的开始），以便将整体软件分解为我可以处理的部分。
您的问题最初指向另一个方面：
我正在启动一个使用[...] GUI [...]的项目>
我使用的是STM32H743，运行频率为480MHz。 （它的功能相当强大，但仅比内存和闪存少的一半快一半的东西贵$ 1/15％，这本身就需要额外成本的外部闪存。）
最坏情况下的屏幕绘制为10毫秒。 [...]延迟最多20毫秒，所有操作都不会受到损害。
如果屏幕绘制速度较慢，并且需要通过更紧急的操作来中断，那么显然需要RTOS。
是的，使用RTOS的另一个原因是以或多或少的动态方式交错系统上的不同进程，以便每个任务在其截止日期之前完成。我没有调查您的具体案例的所有情况（请参见引文中的内容），但我坚信此论点不适用于您目前的情况。请注意以下几点：
您比较的是单片µC硬件的最终价格，可能是焊接到某些现成的评估板上。这是一个好主意，我对私人项目也是如此。但是，一旦您为商业产品制作了专业的嵌入式软件，就必须考虑多个控制器的价格（取决于您的行业分支，数十亿至数十亿美元），以及µC本身的价格，因为它已焊接到PCB上了。恰好适合您要编程的产品。然后可能会发生没有人会授予您STM32H7的事情，除非您确实证明这是实现所有软件要求所需的控制器类。
您仅向我们描述了由STM32驱动的屏幕/ GUI，但没有描述屏幕的用途。通常，设备用途意味着对与控制器I / O相关的外围设备的一些实时要求。然后，您可能被迫以少于10到20毫秒的延迟处理程序的某些部分。这将导致您首先使用中断，然后（除非您希望通过大量手动中断抑制来处理上下文之间的每个数据传输），而要使用RTOS。
[也许我是错的，并且您没有任何约束可以执行20毫秒以上的任何响应，或者有一天可以用便宜的STM32代替STM32H7。然后，剩下的唯一论据是处理复杂性。当然，您可以尝试继续进行主循环。只要要求足够简单，您就可以成功，只要您可以使用一种“千篇一律”的架构来处理所有需求。
对在早期评论中贡献了部分答案的人表示感谢：@Lundin，@Clifford