RTOS设计已经成为许多嵌入式应用的关键。超过50%的嵌入式应用使用RTOS，随着如此多的设备开始连接和使用机器学习，这些数字只会增加。嵌入式开发人员在设计基于RTOS的应用程序时有许多考虑因素。在今天的文章中，我们讨论五个RTOS设计的最佳实践。

1. 数据决定设计

好的软件设计是由数据驱动的，换句话说，数据决定设计。大多数系统是实时系统，其中事件生成数据。反过来，这些数据必须以各种方式流经应用程序，被处理，然后被存储或输出。

当您开始设计RTOS，甚至任何嵌入式应用程序时，您应该首先确定应用程序中的所有数据源。首先，创建一个列表；接下来，在图表中画一个方块，标记数据源；最后，将数据源映射到它们的最终目的地，并标记数据是如何转换和处理的，以及哪些应用程序区域使用这些数据。当完成时，任务、数据存储、同步机制等。自然会从数据流中出来。

2. 使用 RMS 验证你的设计

RMS，即最著名的单调速率调度，是一种分析技术，设计人员可以使用它来测试他们关于系统中的任务是否可以成功调度的假设。RMS模型有很多种。最基本的模型假设是：

任务是周期性的

任务是独立的

使用抢占式调度

每个任务都有一个恒定的最坏情况执行时间

所有任务都同样重要

非周期性任务仅限于启动和故障恢复

乍一看，这些假设中的一些在现实世界中似乎非常不现实，但大多数设计都可以使用它们进行分解和验证。(更复杂的模型改善了这些假设)。示例分析如下：

3. 任务分解从外向内开始

将应用程序分解成任务是一项挑战，嵌入式开发人员经常会问自己以下问题：

我的任务太多了吗？

我没有足够的任务吗？

可以安排所有这些任务吗？

这些任务应该合并还是分开？

开始分解应用程序的最佳方式是从外到内。首先，检查硬件设备和系统的输入输出。检查数据和数据生成速率。输入/输出和硬件及其数据流将有助于识别系统中的主要任务。例如，您可能会得到一个如下所示的简单图表：

上图确定了五个主要任务，后面是一个可以进一步分解的应用程序块。

4. 使用 OSAL 解耦 RTOS

许多公司围绕他们的RTOS构建他们的整个应用程序。RTOS应该是应用程序的一个组件，而不是应用程序的基础。问题是开发商无法控制RTOS。如果RTOS发生变化，应用程序将无法免受这些变化的影响。如果RTOS突然不可用或被别人买走，换一个不同的RTOS可能会像重写大多数应用程序一样痛苦。

这里的最佳实践是使用操作系统抽象层(OSAL)。它可以非常优雅地集成到软件架构中，如下图所示：

请注意，RTOS只是应用程序堆栈中间的另一个组件。如果我们想换出新的RTOS，我们需要做的就是将OSAL映射更改为新的RTOS。应用程序不知道发生了什么变化！

OSAL本质上充当了一个依赖屏障，将使用通用操作系统调用。例如，每个RTOS都有一个信号量、互斥量等。OSAL为常见的RTOS函数提供了一个通用API。如果需要一些特定于操作系统的功能，这些功能通常不在OSAL中，如CMSIS-RTOS2，那么嵌入式开发人员应该为OSAL编写自己的扩展。这将继续限制应用程序对RTOS的耦合和依赖。毕竟你永远不知道什么时候会改变。

5. 不要将信号量用作互斥体

互斥和信号量是为不同的目的而设计的。互斥锁旨在提供对资源的互斥访问。信号量是为任务通知和协调而设计的。

设计人员和开发人员经常使用二进制信号量作为互斥体。互斥锁可以锁定/解锁资源。您可以给出或获取二进制信号量，从而产生看起来很像锁定/解锁的状态。然而，两者之间有一个重要的区别。互斥有一个特性叫做优先级继承。在优先级反转的情况下，优先级继承可以提高任务的优先级，将优先级反转的影响降到最低。

信号量不支持优先级继承，因此当用作互斥体时，会导致优先级反转和其他设计问题。请确保您理解这些差异，并且永远不要使用信号量来保护数据访问。使用正确的工具，即互斥。

结论

RTOS设计正在成为或已经成为嵌入式开发人员需要执行的常见活动，许多困难可以通过我们刚刚学习的RTOS设计的五个最佳实践来缓解。认真学习这些方法，可以避免很多麻烦。

了解更多