实时操作体系 (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 的依靠。 |
