Embedded 为什么我会考虑使用RTOS做我的嵌入式项目？

首先，我的问题的背景和具体内容如下：

我在平台上工作的公司目前是Microchip PIC32系列，使用MPLAB IDE作为我们的开发环境。在此之前，我们还为同一应用程序的微芯片dsPIC和TI MSP系列编写了固件。 固件非常简单，因为代码分为三个主要模块：设备控制、数据采样和用户通信（通常是用户PC）。设备控制通过GPIO总线和至少一个需要SPI或I2C控制的部分的组合来实现。数据采样采用中断驱动，使用定时器模块保持采样频率，并使用更多SPI/I2C和GPIO总线控制采样硬件（即ADC）。目前，用户通信是使用微芯片应用程序框架通过USB实现的

---

现在，问题是：考虑到我上面所说的，我会考虑在什么情况下为我的项目使用RTOS？目前，我认为这些可能的触发点是使用RTOS的原因：

• 代码复杂性？代码库架构/组织仍然很小，我可以将所有细节都记在脑子里
• 多任务处理/线程化？通过中断对模块执行进行时间切片现在就足以进行多任务处理
• 测试？目前，除了硬件冒烟测试之外，我们没有做太多的正式测试或验证（我希望在不久的将来纠正这一点）
• 通信？我们目前使用一种自定义数据包格式和一种协议，该协议几乎只执行启动、停止和发送数据命令，数据为二进制blob
• 项目范围？在不久的将来，我们可能会获得一个项目，将我们的设备集成到一个更大的系统中，以实现该系统的大规模生产。目前，我们所有的项目都是实验原型，快速周转大约一个月，一次生产一到两个单元

---

你认为我应该考虑哪些方面呢？在您的经验中，是什么说服（或强迫）您考虑使用RTOS而不只是在基础运行时运行代码？我们也非常感谢为RTOS设计/编程的其他资源的指针。

代码重用--如果您使用RTOS API编写驱动程序/协议处理程序，它们可能会更容易插入到未来的项目中

---

调试——一些IDE（如IAR Embedded Workbench）有插件，可以显示运行进程的实时数据，如任务CPU利用率和堆栈利用率

如果您有任何实时限制，通常需要使用RTOS。如果没有实时约束，一个普通的操作系统就足够了。RTO/OS提供消息队列和任务分配等运行时基础设施。如果您只是在寻找能够降低复杂性、提供低级别支持和帮助进行测试的代码，以下一些库可能可以：

• 标准C/C++库
• 增强库
• 可通过芯片制造商提供的库，该芯片可提供特定于硬件的支持
• 商业图书馆
• 开源库

---

使用RTOS的原因有很多。它们是多种多样的&它们在多大程度上适用于你的情况很难说。（注意：我倾向于这样想：RTOS意味着硬实时，这意味着抢占式内核…）
• 速率单调分析（RMA）-如果要使用以确保满足计时截止日期，必须使用先发制人的调度程序

• 满足实时截止日期即使不使用RMA，通过基于优先级的先发制人RTO，您的调度程序也可以帮助确保满足截止日期。自相矛盾的是，由于内核中的中断通常被屏蔽，RTOS通常会增加

• 管理复杂性——毫无疑问，RTOS（或大多数操作系统风格）可以帮助解决这一问题。通过允许将项目分解为独立的线程或进程，并使用操作系统服务（如消息队列、互斥体、信号量、事件标志等）进行通信和同步，您的项目（以我的经验和观点）变得更易于管理。我倾向于从事更大的项目，大多数人都理解保护共享资源的概念，所以很多新手犯的错误不会发生。但是要注意，一旦您采用多线程方法，事情可能会变得更加复杂，直到您将注意力集中在问题上

• 使用第三方软件包-许多RTO提供其他软件组件，如协议栈、文件系统、设备驱动程序、GUI软件包、引导加载程序和其他中间件，这些组件可以帮助您更快地构建应用程序，使您更像一个“集成商”，而不是DIY商店

• 测试-是的，可以肯定地说，您可以将每个控制线程视为具有定义良好的接口的可测试组件，特别是如果使用一致的方法（例如始终在消息队列的单个位置阻塞）。当然，这不能替代单元、集成、系统等测试

• 健壮性/容错性-RTO还可以为处理器的MMU提供支持（在您的PIC案例中，我认为这不适用）。这允许每个线程（或进程）在自己的受保护空间中运行；线程/进程不能“浸入”彼此的内存并踩踏它。甚至设备区域（MMIO）也可能禁止某些（或所有）线程使用。严格地说，利用处理器的MMU（或MPU）不需要RTOS，但这两个处理器可以很好地协同工作

通常，当我可以使用RTOS（或某种类型的抢占式m