33

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

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

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

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

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

4

5 回答 5

34

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

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

  • 满足实时期限- 即使不使用 RMA，使用基于优先级的抢先式 RTOS，您的调度程序也可以帮助确保满足期限。矛盾的是，由于内核中通常屏蔽中断的关键部分，RTOS 通常会增加中断延迟

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

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

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

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

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

请注意，多线程开发有一些学习曲线。如果您是 RTOS/多线程开发的新手，您可能会对一些关于选择 RTOS、抢占的风险和抢占式多任务简介的文章感兴趣。

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

于 2010-09-01T00:56:04.070 回答
6

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

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

于 2010-09-02T14:20:53.713 回答
3

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

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

于 2010-08-31T17:04:15.537 回答
2

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

  • 标准 C/C++ 库
  • 提升库
  • 可通过芯片制造商获得的可提供硬件特定支持的库
  • 商业图书馆
  • 开源库
于 2010-08-31T17:55:35.003 回答
1

除了前面提到的几点，如果您需要支持，使用 RTOS 也可能很有用

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

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

于 2010-09-02T14:37:14.690 回答