决定是在实时操作系统 (RTOS) 下运行固件还是开发裸机解决方案对于嵌入式系统的成功至关重要，然而，决定走哪个方向可能很困难。以下是每个嵌入式研发人员在做出决定之前应考虑的五个因素。

  决定 RTOS 和裸机调度程序的重要的因素是系统要不要抢占。如果抢占是必需的，那么 RTOS 就是是正确的选择! 暂停任务和执行更高优先级任务的能力是 RTOS 的主要优势之一。如果任务的优先级设置得当，可以大幅度提高系统的实时性。在裸机级别，研发人员可能会认为能够最终靠使用中断和设置中断优先级来获得抢占行为。在某一些程度上这是正确的，但这样的中断应该是快速、短暂的。尝试使用中断来抢占当前正在运行的函数可能会影响系统的实时性能。

  如今，许多研发人员的第一反应是直接用RTOS，同时尝试选择具有最少 RAM 和闪存集的部件。但是他们在这样做的时候很少或者根本不了解最终软件的内存占用。结果是“不适合该区域”的错误迟早会发生。许多RTOS默认将每个任务或线，这是堆栈深度而不是大小的指标。在32位机器上，默认情况下，每个任务的内存大小可能高达2kB!显然，这个数量嵌入式研发人员可以根据应用程序做调整，但默认值确实开始提供一些关于使用RTOS所需的最小RAM数量的信息。

  还应考虑RTOS的闪存使用。典型的RTOS至少能够正常的使用6kb到8 kB的闪存。这听起来占用空间很小，除非所选MCU中只有16 kB的闪存空间。当考虑使用RTOS时，一个好的经验法则是，系统至少应该包含32 kB的闪存和4 kB的RAM。

  可用的中间件可能是决定是不是使用RTOS的一个主要的因素。许多RTOS都有中间件堆栈，如文件系统、USB或TCP/IP，可以轻松集成到RTOS中。将这些堆栈集成到裸机系统中会很耗时并且容易出错，尽管它们很简单并能直接与RTOS集成。嵌入式研发人员应该考虑应用程序在大多数情况下要什么样的中间件堆栈，以及使用哪种解决方案他们会“玩得更好”。

  RTOS的使用不能保证可移植性或代码重用，裸机解决方案也不能。然而，基于RTOS的固件解决方案的设计确实倾向于产生具有明确定义的任务并能使其自身被重用的固件。裸机固件可以被编写成可移植和可重用的，但这通常感觉需要更加多的努力，而且不是自然而然的。

  RTOS或裸机解决方案的选择可能基于研发人员的经验。缺乏 RTOS 经验有几率会使开发周期痛苦且漏洞百出。RTOS设置起来很快，但调试起来可能很耗时。抽象层会使窥视操作系统的真实行为变得困难。一个没有RTOS经验的嵌入式开发团队最好使用裸机解决方案，并在较小的项目中测试驱动RTOS以获得必要的经验。