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

Question

首先是背景，我的问题的细节如下:

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

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

代码复杂度？ 代码库架构/组织仍然足够小，我可以将所有细节都牢记在心。

多任务/线程？ 现在，通过中断对模块执行进行时间切片就足够了多任务处理。

测试？ 目前我们在硬件冒烟测试之后没有做太多的正式测试或验证(我希望在不久的将来纠正)。

沟通？ 我们目前使用自定义数据包格式和协议(protocol)，该协议(protocol)几乎只执行 START、STOP、SEND DATA 命令，数据为二进制 blob。

项目范围？ 在不久的将来，我们有可能获得一个项目，将我们的设备集成到一个更大的系统中，目标是将该系统投入批量生产。目前我们所有的项目都是实验原型(prototype)，大约一个月的快速周转，一次生产一两个单元。

您认为我还应该考虑哪些其他问题？根据您的经验，是什么说服(或迫使)您考虑使用 RTOS 而不是仅在基本运行时上运行代码？也非常感谢有关为 RTOS 设计/编程的其他资源的指针。

Answer 1

您可能想要使用 RTOS 的原因有很多。它们是多种多样的，它们适用于您的情况的程度很难说。 (注意:我倾向于这样认为:RTOS 意味着硬实时，这意味着抢占式内核......)

速率单调分析 (RMA) - 如果你想使用 Rate Monotonic Analysis为确保满足您的时间期限，您必须使用抢先调度程序

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

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

使用第三方包 - 许多 RTOS 提供其他软件组件，例如协议(protocol)栈、文件系统、设备驱动程序、GUI 包、引导加载程序和其他中间件，通过成为几乎更多的“集成商”而不是 DIY 商店来帮助您更快地构建应用程序。

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

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

一般来说，当我可以使用 RTOS(或某种类型的抢占式多任务程序)进行开发时，结果往往会更干净、更模块化、更规范、更易于维护。当我有选择时，我使用一个。

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

最后，即使您没有征求建议...除了众多商业 RTOS，还有免费产品( FreeRTOS 是最受欢迎的产品之一)和 Quantum Platform是一个基于 active objects 概念的事件驱动框架其中包括一个抢占式内核。有 plenty of choices ，但我发现拥有源代码(即使 RTOS 不是免费的)是有利的，尤其是。调试时。