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