我们在编写RTOS应用程序的过程中,经常会遇到这些困难,包括正确 确定 系统中有多少任务 、 如何设置优先级 、 协调任务行为 、 避免常见陷阱 ,有时只是为了让应用程序正常工作,而忽略一些问题。 如今,近三分之二的嵌入式系统使用 RTOS,而且随着系统的时序要求变得越来越复杂,这个数字只会随着时间的推移而增加。在今天的文章中,我们将研究设计基于 RTOS 的应用程序的五个最佳实践技巧。 首先我们可以遵循的第一个最佳实践技巧就是使他们的 RTOS 应用程序开发成功,是使用 任务分解来获得应用程序中正确数量的任务 。 有许多技术可用于分解任务,但我喜欢使用的一种对嵌入式开发人员很有效的方法是使用由外向内(outside-in)的方法。在这种方法中,开发人员遵循七个简单的步骤: 在为恒温器等物联网传感器节点执行此过程时,最终可能会得到如下图所示: 在这种情况下,系统通常有六个任务,其中一个任务监督应用程序代码。(根据系统复杂性,可以进一步分解此任务)。 我观察到很多使用 RTOS 的开发人员从不花时间决定他们将如何安排他们的任务。 他们通常假设 RTOS 会为他们做这件事,并且他们的任务会根据提供他们选择的任务优先级成功运行。 事实是,开发人员可以通过多种不同的方式来安排任务。 首先, 开发人员可以使用任务响应时间来调度任务。在这些系统中,响应时间最短的任务应该被分配最高优先级。其次, 开发人员可以使用一个任务执行时间来调度任务。在这些系统中,执行时间最短的任务应该被分配最高优先级。 最后, 开发人员可以使用任务周期来安排任务。在这些系统中,周期最短的任务优先级最高。 只有在您选择了调度方法之后,您才能正确设置您的任务优先级。(我看到很多开发人员只是猜测)。 大多数使用 RTOS 的嵌入式系统中使用的调度算法是基于周期的调度,也称为速率单调调度(Rate Monotonic Scheduling)。 多年来,人们对如何使用 RMS 正确安排任务进行了大量研究。通常,RMS 附带了开发人员需要牢记的几个假设。 首先,RMS 假设任务是周期性的并且它们也是独立的。这意味着,如果您有一个非周期性任务,在分析中我们会假设为它提供一些周期性时间。 接下来,RMS 假设 RTOS 使用抢占式调度。它还假设所有任务都相等并且最坏情况的执行时间是恒定的。 我经常发现 RMS 非常适合对我开发的 RTOS 应用程序架构是否有意义或者我是否在错误的方向进行完整性检查。 例如,我可以假设具有以下任务的系统的行为方式并确定它是否可以成功调度其任务: 对于使用 RMS 的系统,对于具有无限数量任务的系统,所有这些任务的 CPU 使用率必须低于 69.3%。对于上述系统,我们可以看到总利用率为 52%,这意味着它们应该是可调度的。 在使用由外向内(outside-in)的方法确定我在应用程序中需要的所有任务后,我通常会创建一个同步和数据流图。 此图的目的是: 早些时候,我以连接互联网的恒温器为例。下面是我们可能为该应用程序制作的数据流和同步图。 如你所见,此图不仅可以帮助我们了解数据如何在系统中移动,还可以帮助我们了解应用程序中所需的 RTOS 组件,例如: 如果没有这样的图表,开发团队必然会遇到开发和维护问题。 一旦创建了数据流图,就很容易开始对应用程序进行编码。 这无疑会在一段时间内顺利进行,但我发现如果开发人员不花时间预先仔细定义任务和消息接口,它可能会导致返工。 虽然数据流图通常显示数据如何通过应用程序传播,但它并不一定要求定义数据结构。 目标是预先检查每个消息队列,然后为这些消息构建结构。这很重要,因为它将定义消息的外观,而且还将有助于任何底层模块的接口的外观。 例如, 管理一系列阀门的任务可能需要包含以下内容的消息: 归根结底,做事的方式总是不止一种,一种不一定比另一种更好。但是,在为支持任务执行的其他模块构建接口时,了解正在传递的消息将有所帮助。 实时操作系统比以往任何时候都更多地用于开发实时应用程序。 我们在今天的文章中探讨了几个技巧,这些技巧不仅可以帮助读者创建更清晰、更灵活的 RTOS 应用程序,还可以帮助他们传达应用程序的设计意图。希望这些技巧可以帮助你们快速开始应用程序的开发。 来源 | 小麦大叔 ▼
更多精彩干货, 点击下方关注查看
▼
关注『面包板社区』, 后台回复 "关键词" ,领取 300 G 学习资料包 ( 如: 电源、电机、嵌入式、信号系统、模电、华为、电子学、电路、c语言...)
#推荐阅读#
【完全吃透】征服傅里叶变换
SMT贴片元件基础知识
弃卒保帅:反思华为服务器的出售事件
拆开步进电机来仔细讲一讲
X电容和Y电容的区别
你真的吃透了电阻的用法吗?
点击阅读原文, 下载 《FreeRTOS源码详解与应用开发全部资料》