开发 RTOS 应用软件框架
发布时间：2022-02-27 22:45:18 所属栏目：动态 来源：互联网
导读：实时操作系统 (RTOS) 正在进入几乎所有物联网设备，RTOS 管理低级资源和复杂时序要求的能力使其非常适合这些应用程序，尽管嵌入式开发人员为如何设计包含 RTOS 的软件架构而苦苦挣扎并不少见。在今天的文章中，我们将探讨开发基于 RTOS 的强大且灵活的软件架
|
实时操作系统 (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 – 使用速率单调调度 (RMS) 来定义任务优先级 一旦在架构中定义了任务，使用速率单调调度来确定任务设计是否朝着正确的方向发展是很有用的。假设你有十几个任务，问题真的变成了：“我真的可以成功地安排所有这些任务并确保没有错过最后期限吗？”。RMS 旨在帮助嵌入式开发人员回答这个问题。 创建一个任务表，包含想要跟踪的有关任务的所有参数。例如，包括以下数据： 任务优先级（即使我可能还没有分配） 任务堆栈大小（或深度取决于 RTOS） 任务估计执行时间（以毫秒为单位） 任务周期（以毫秒为单位） 任务CPU利用率（执行时间/周期） 创建表后，我们将每个任务的利用率相加，然后根据系统中的任务数确保 CPU 利用率小于下表中的值： 如果我们的系统有五个任务，我们希望我们的 CPU 利用率总和小于 0.743，以确保我们的任务可以被调度。（请记住，RMS 有很多假设，但它是一个很好的健全性检查）。 （编辑：ASP站长） 【免责声明】本站内容转载自互联网，其相关言论仅代表作者个人观点绝非权威，不代表本站立场。如您发现内容存在版权问题，请提交相关链接至邮箱：bqsm@foxmail.com，我们将及时予以处理。 |
相关内容
未处理完善
-
无相关信息
最新更新