今天聊一下RTOS应用程序设计的五个实战技巧。
我在编写RTOS应用程序的过程中，经常会遇到这些困难，包括正确确定系统中有多少任务、如何设置优先级、协调任务行为、避免常见陷阱，有时只是为了让应用程序正常工作！
如今，近三分之二的嵌入式系统使用 RTOS，而且随着系统的时序要求变得越来越复杂，这个数字只会随着时间的推移而增加。在今天的文章中，我们将研究设计基于 RTOS 的应用程序的五个最佳实践技巧。
首先我们可以遵循的第一个最佳实践技巧就是，使他们的 RTOS 应用程序开发成功，是使用任务分解来获得应用程序中正确数量的任务。
有许多技术可用于分解任务，但我喜欢使用的一种对嵌入式开发人员很有效的方法是，使用由外向内（outside-in）的方法。在这种方法中，开发人员遵循七个简单的步骤：
在为恒温器等物联网传感器节点执行此过程时，最终可能会得到如下图所示：
在这种情况下，系统通常有六个任务，其中一个任务监督应用程序代码。（根据系统复杂性，可以进一步分解此任务）。
我观察到很多使用 RTOS 的开发人员从不花时间决定他们将如何安排他们的任务。他们通常假设 RTOS 会为他们做这件事，并且他们的任务会根据提供他们选择的任务优先级成功运行。
事实是，开发人员可以通过多种不同的方式来安排任务。
首先，开发人员可以使用任务响应时间来调度任务。在这些系统中，响应时间最短的任务应该被分配最高优先级。
其次，开发人员可以使用一个任务执行时间来调度任务。在这些系统中，执行时间最短的任务应该被分配最高优先级。
最后，开发人员可以使用任务周期来安排任务。在这些系统中，周期最短的任务优先级最高。
只有在你选择了调度方法之后，你才能正确设置任务优先级。（我看到很多开发人员只是猜测）。
大多数使用 RTOS 的嵌入式系统中使用的调度算法是基于周期的调度，也称为速率单调调度（Rate Monotonic Scheduling）。
多年来，人们对如何使用 RMS 正确安排任务进行了大量研究。通常，RMS 附带了开发人员需要牢记的几个假设。
首先，RMS 假设任务是周期性的并且它们也是独立的。这意味着，如果你有一个非周期性任务，在分析中我们会假设为它提供一些周期性时间。
接下来，RMS 假设 RTOS 使用抢占式调度。它还假设所有任务都相等并且最坏情况的执行时间是恒定的。
我经常发现 RMS 非常适合对我开发的 RTOS 应用程序架构是否有意义或者我是否在错误的方向进行完整性检查。
在使用由外向内（outside-in）的方法确定我在应用程序中需要的所有任务后，我通常会创建一个同步和数据流图。此图的目的是：
早些时候，我以连接互联网的恒温器为例。下面是我们可能为该应用程序制作的数据流和同步图。
如果没有这样的图表，开发团队必然会遇到开发和维护问题。
一旦创建了数据流图，就很容易开始对应用程序进行编码。
这无疑会在一段时间内顺利进行，但我发现如果开发人员不花时间预先仔细定义任务和消息接口，它可能会导致返工。
虽然数据流图通常显示数据如何通过应用程序传播，但它并不一定要求定义数据结构。
目标是预先检查每个消息队列，然后为这些消息构建结构。这很重要，因为它将定义消息的外观，而且还将有助于任何底层模块的接口的外观。例如，管理一系列阀门的任务可能需要包含以下内容的消息：
再说一次，它可能会期待：
归根结底，做事的方式总是不止一种，一种不一定比另一种更好。但是，在为支持任务执行的其他模块构建接口时，了解正在传递的消息将有所帮助。
实时操作系统比以往任何时候都更多地用于开发实时应用程序。
来源：小麦大叔
原文：https://great.blog.csdn.net/article/details/118736109
文章来源于网络，版权归原作者所有，如有侵权，请联系删除。
关注我【一起学嵌入式】，一起学习，一起成长。
觉得文章不错，点击“分享”、“赞”、“在看” 呗！
