开发 RTOS 应用软件架构

实时操作系统 (RTOS) 正在进入几乎所有物联网设备，RTOS 管理低级资源和复杂时序要求的能力使其非常适合这些应用程序，尽管嵌入式开发人员为如何设计包含 RTOS 的软件架构而苦苦挣扎并不少见。在今天的文章中，我们将探讨开发基于 RTOS 的强大且灵活的软件架构的几个技巧。

提示 #1 – 打破应用程序对 RTOS 的依赖

在基于 RTOS 的软件架构中经常看到的一个问题是开发人员选择他们的 RTOS，然后围绕它构建他们的整个软件架构。虽然这似乎不是一个坏主意，但维护或将该代码移植到可能使用不同 RTOS 的其他应用程序可能会变得相当头疼。想想看，没有 RTOS 开发人员遵循的 RTOS 接口标准（尽管 Arm 确实有 CMSIS-RTOSv2）。相反，大约有 100 个不同的 RTOS，每个都有自己的 API。切换 RTOS 需要找到并更改每个 RTOS API 调用，这可能很耗时。

设计架构的更好方法是使应用程序与 RTOS 无关。由于大多数 RTOS 都提供类似的功能，因此将 RTOS 置于操作系统抽象层 (OSAL) 之后，可以推迟对特定 RTOS 的选择，同时减少应用程序 RTOS 依赖性并提高架构的灵活性。

提示 #2 – 使用由外而内的技术来定义初始任务

定义任务的由外而内的方法是一种允许嵌入式开发人员查看系统，然后从用户与之交互的物理特征开始分解它，然后向内处理与应用程序相关的任务的方法。例如，你可以想象一个连接互联网的恒温器，它具有以下功能：液晶显示器、触摸屏、LED背光、无线上网、内存存储、温度、湿度和电流等传感器接口、扇子、蓝牙。

如你所见，这些设备大多是外向的、面向用户的和基于硬件的设备，但由此产生的任务可能会被组织成以下任务：输入处理、网络管理、印刷、控制器、内存管理。

请记住，这是一种帮助你决定需要哪些任务的技术，通常有不止一种方法可以构建同样有效的任务。（而且有一些只会导致比它们的价值更多的麻烦）。

提示 #3 – 使用速率单调调度 (RMS) 来定义任务优先级

一旦在架构中定义了任务，使用速率单调调度来确定任务设计是否朝着正确的方向发展是很有用的。假设你有十几个任务，问题真的变成了：“我真的可以成功地安排所有这些任务并确保没有错过最后期限吗？”。RMS 旨在帮助嵌入式开发人员回答这个问题。

创建一个任务表，包含想要跟踪的有关任务的所有参数。例如，包括以下数据：

任务优先级（即使我可能还没有分配）

任务堆栈大小（或深度取决于 RTOS）

任务估计执行时间（以毫秒为单位）

任务周期（以毫秒为单位）

任务CPU利用率（执行时间/周期）

创建表后，我们将每个任务的利用率相加，然后根据系统中的任务数确保 CPU 利用率小于下表中的值：

如果我们的系统有五个任务，我们希望我们的 CPU 利用率总和小于 0.743，以确保我们的任务可以被调度。（请记住，RMS 有很多假设，但它是一个很好的健全性检查）。

提示 #4 – 创建数据流图

数据流图通常提供数据如何流经应用程序的单个高级应用程序图片。使用 RTOS 时，该图显示：

数据产生的地方

数据如何从产生的地方转移到消费的地方

数据存储在哪里

如何访问数据

该图通常也有助于嵌入式开发人员了解系统中的主要 RTOS 组件。例如，图表通常会显示：

任务

队列

信号量

受互斥锁保护的共享数据

中断服务程序

事件标志

在布置框架代码以测试架构时，该图可以提供极大的帮助。

提示 #5 – 预先定义任务和消息接口

一旦创建了数据流图就可以深入研究并开始编写应用程序，这无疑会在一段时间内顺利进行，但如果开发人员不花时间仔细定义任务和消息接口，可能会导致返工。虽然数据流程图通常显示数据是如何通过应用程序传播的，但它并不一定需要定义数据结构。

然后，目标是预先检查每个消息队列，然后为这些消息构建结构。这很重要，因为它将定义消息的外观，但也将有助于任何底层模块的接口外观。例如，管理一系列阀门的任务可能需要包含以下内容的消息：

阀门 ID

阀门状态

阀门所需的准时

定义阀门状态的面罩

准时列表

归根结底，做事的方法总是不止一种，一种不一定比另一种更好。但是，在为支持任务执行的其他模块构建接口时，了解正在传递的消息将有所帮助。

结论

开发 RTOS 软件架构是了解将要构建的应用程序及其主要组件的好方法。我们在今天的文章中探讨了几个技巧，这些技巧不仅可以帮助嵌入式开发人员创建基于 RTOS 的更清晰、更灵活的应用程序，还可以帮助他们传达应用程序的设计意图，快速开始他们的应用程序开发，同时最大限度地减少对 RTOS 的依赖。