为什么我会考虑将RTOS用于我的嵌入式项目？

Question

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

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

---

现在问题是：鉴于我上面所描述的内容，我会考虑在什么时候为我的项目使用RTOS？目前我正在考虑将这些可能的触发点作为使用RTOS的理由：

• 代码复杂性？ 代码库架构/组织仍然足够小，我可以将所有细节保存在我的脑海中。
• 多任务处理/线程处理？ 通过中断对模块执行进行时间分片就足以实现多任务处理。
• 测试？ 目前我们在硬件烟雾测试之后没有进行太多正式测试或验证（我希望在不久的将来能够纠正）。
• 通信？ 我们目前使用自定义数据包格式和协议，该协议几乎只执行START，STOP，SEND DATA命令，数据为二进制blob。
• 项目范围？ 在不久的将来，我们可能会有一个项目将我们的设备集成到一个更大的系统中，目标是系统到批量生产。目前我们所有的项目都是实验原型，快速周转约一个月，一次生产一个或两个单位。

您认为我应该考虑哪些其他方面？根据您的经验，您认为（或强迫）您考虑使用RTOS而不是仅仅在基本运行时运行代码？关于为RTOS设计/编程的其他资源的指针也非常受欢迎。

Answer 1

您可能希望使用RTOS的原因有很多。它们多种多样。他们适用于你的情况的程度很难说。 （注意：我倾向于这样思考：RTOS 暗示硬实时，暗示抢先内核......）

• 费率单调分析（RMA） - 如果您想使用Rate Monotonic Analysis确保您的时间期限得到满足，则必须使用先发制人的调度程序

• 满足实时截止日期 - 即使不使用RMA，也可以使用基于优先级的先发制人RTOS，您的日程安排程序可以帮助确保满足最后期限。矛盾的是，由于内核中interrupt latency通常会屏蔽中断，RTOS通常会增加critical sections

• 管理复杂性 - 当然，RTOS（或大多数操作系统版本）都可以提供帮助。通过允许将项目分解为独立的线程或进程，并使用诸如消息队列，互斥体，信号量，事件标志等的OS服务来进行通信。同步，您的项目（根据我的经验和意见）变得更易于管理。我倾向于从事大型项目，大多数人都了解保护共享资源的概念，所以很多新手的错误都不会发生。但要注意，一旦你采用多线程方法，事情就会变得更加复杂，直到你解决问题为止。

• 使用第三方软件包 - 许多RTOS提供其他软件组件，例如协议堆栈，文件系统，设备驱动程序，GUI软件包，引导加载程序以及其他可帮助您构建的中间件通过变得更像“积分器”而不是DIY商店，应用程序更快。

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

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

通常，当我可以使用RTOS（或某种类型的抢先式多任务程序）进行开发时，结果往往更清晰，更模块化，更良好，更易于维护。当我有选择时，我会使用一个。

请注意，多线程开发有一点学习曲线。如果您不熟悉RTOS /多线程开发，可能会对Choosing an RTOS，The Perils of Preemption和An Introduction to Preemptive Multitasking上的一些文章感兴趣。

最后，即使您没有提出建议......除了众多商业RTOS之外，还有免费产品（FreeRTOS是最受欢迎的产品之一）和{{3} }是一个基于Quantum Platform概念的事件驱动框架，它包含一个抢占式内核。有active objects，但我发现拥有源代码（即使RTOS不是免费的）也是有利的，尤其是。在调试时。

Answer 2

RTOS，首先允许您将并行流组织到任务集中，并在它们之间进行明确定义的同步。

IMO，非RTOS设计仅适用于单流架构，其中所有程序都是一个无限循环。如果您需要多流程 - 许多任务，并行运行 - 您最好使用RTOS。如果没有RTOS，您将被迫在内部实施此功能，重新发明轮子。

Answer 3

代码重用 - 如果您使用RTOS API对驱动程序/协议处理程序进行编码，则可以更轻松地插入到未来的项目中

调试 - 某些IDE（例如IAR Embedded Workbench）具有插件，可显示有关正在运行的进程的实时数据，例如任务CPU利用率和堆栈利用率

Answer 4

如果您有任何实时约束，通常您希望使用RTOS。如果您没有实时约束，则常规操作系统可能就足够了。 RTOS的/ OS提供了一个运行时基础设施，如消息队列和任务。如果您只是在寻找可以降低复杂性的代码，提供低级别的支持并帮助进行测试，那么以下某些库可能会这样做：

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

Answer 5

除了前面提到的要点之外，如果您需要支持

，使用RTOS也可能很有用

• 标准存储设备（SD，Compact Flash，磁盘驱动器......）
• 标准通信硬件（以太网，USB，Firewire，RS232，I2C，SPI，......）
• 标准通信协议（TCP-IP，...）

大多数RTOS提供这些功能或可扩展以支持它们