我的经验法则是，如果产品需要以下一项或多项，则应考虑操作系统：TCP/IP 堆栈（或其他复杂的网络堆栈）、复杂的 GUI（可能带有 GUI 对象，例如窗口和事件） ) 或文件系统。

如果您做过一些裸机编码，那么您可能熟悉超级循环程序架构。如果产品的固件要求足够简单，可以使用可维护的超级循环来实现（并且希望在某种程度上可扩展），那么您可能不需要操作系统。

随着软件需求的增加，超级循环变得更加复杂。当软件需求太多以至于超级循环变得过于复杂或无法满足系统的实时要求时，是时候考虑另一种架构了。

RTOS 架构允许您将软件需求划分为任务。如果处理得当，这将简化每项任务的实施。通过任务优先级，RTOS 可以更轻松地满足实时要求。然而，RTOS 并不是万能的。RTOS 增加了整个系统的复杂性，并为您带来了新类型的错误（例如死锁）。作为 RTOS 的替代方案，您可能会考虑使用基于事件的状态机架构（例如QP）。

如果您的产品具有网络、复杂的 GUI 和文件系统，那么您可能应该考虑使用全功能操作系统，例如 VxWorks、Windows 或 Linux。全功能操作系统将包括低级细节的驱动程序，让您专注于您的应用程序。

这实际上取决于您对“嵌入式系统”的定义。可能有人会声称，如果它不是裸机编程，它就不是嵌入式的（这排除了你的问题），但我不同意这一点——我认为任何设计为只执行一个功能的系统，即，仅运行一个特定的“应用程序”，可以称为嵌入式系统。

也就是说，应该很容易想象会从完整操作系统的服务中受益的情况。例如，在我工作的地方，经常会发现人们在运行在 windows 之上的仪器设计套件之上构建测试设备。这些系统被配置为启动到测试站配置并锁定一般用途（以防止站损坏），因此可以说是嵌入式系统。

然而，仅仅购买现成的 I/O 模块，将它们插入机架式 PC，并在 GUI 中进行配置，可能无法成为某些嵌入式系统设计。对于不那么现成的情况，请考虑使用带有 FPGA 的自定义过程控制器，您想要对其进行一些花哨的数据记录。您可以嵌入软核处理器系统（带有现有的 BSP）并运行实时 linux 以运行网络堆栈（用于您的日志记录和 NTP 等）并在逻辑中执行其他所有操作。

我的（非常模糊的）经验法则是，如果您需要多个控制线程（例如至少一个涉及协议或状态机的设备以及其他要做的事情），那么一些 OSish 软件将使您的生活更轻松

一个老问题，但无论如何我都会发表评论。

即使您没有网络堆栈或类似的东西，在您需要任务调度程序的地方，因为您的嵌入式应用程序中有足够的进程，您可能会考虑使用 RTOS。编写一个简单的基于计时器的协作多任务调度程序并不难，但要确保卡住的进程不会阻塞应用程序的其余部分，这样可能需要一段时间才能正确处理。您需要实施具有某种规定的优先级系统，以在进程尚未完成时将其推倒在队列中。

RTOS 还为您提供诸如内存保护之类的东西，这使得跟踪 C 代码中的一些常见错误变得更加容易，但简单的微控制器可能根本无法处理复杂的内存保护。例如，MSP430 允许您在高级别的地方分离代码和数据，但没有细粒度的内存访问控制。