一“RTOS” to Rule them All

总是有选择的余地,但是就实时操作系统(RTOS)而言,太多了!如果您曾经花时间在网上搜索,就会发现有一百多种不同的RTOS!有些是通用的,有些则尝试根据行业来区分,例如物联网。其他人则声称它们更好,因为它们是商业产品,而开源者则声称它们是免费的,并且与商业产品一样好。向任何三位工程师询问有关他们的RTOS选择的信息,您可能会发现他们都有不同的偏爱。

我一直是《指环王》的忠实粉丝,只用一个指环就可以统治所有人。如果只有一个RTOS会不会很好?答案实际上是不!嵌入式系统空间太多样化而无法创建一个可以满足每个人需求的RTOS。使用安全性至关重要的软件的人们会希望使用鲁棒的,严格的确定性,而商业开发人员会对满足实时的软性需求感到满意,并将鲁棒的确定性视为过大的杀伤力。永远不会有一个单独的RTOS来统治它们,但是如果RTOS本身更像是电源环,而操作系统抽象层(OSAL)就是一个环,那该怎么办?

 

Ruling the 实时操作系统 through OSALs

OSAL是一个非常有用的工具,开发人员可以利用它来提取他们选择的特定RTOS。 OSAL本质上是一个通用接口,可用于与任何数量的现有RTOS进行交互并控制它们。如果一个开发人员喜欢FreeRTOS,他们只需将FreeRTOS API与OSAL包装在一起即可。如果另一个开发人员想要使用ThreadX或uC OS III或某些其他RTOS,则只需将RTOS调用与OSAL接口包装在一起即可。

使用OSAL实际上有很多优点。首先,OSAL允许开发人员将其应用程序代码与RTOS分离。有这么多的选择,还有很多过时的样式,团队不应该围绕RTOS编写应用程序。 实时操作系统只是一个组件或工具,在应用程序中对RTOS的依赖性越小越好!一个完美的例子可能是在概念验证期间使用一个RTOS,因为它是免费的,而在开发和生产期间可以使用安全认证的版本。有了OSAL,就无需重写应用程序代码,只需将OSAL接口重定向到另一个RTOS并重新编译即可。

其次,OSAL允许开发人员构建软件而无需关心使用了什么RTOS。软件架构师希望使用抽象的细节,以便他们可以专注于体系结构和应用程序业务规则。因此,复杂的RTOS详细信息被推到了OSAL之后,成为了应用程序架构师不需要考虑的实现细节。 (是的,这确实限制了RTOS特定功能的使用,但是对于可伸缩和灵活的体系结构设计,我们将这些细节推送给实现者)。

最后,由于RTOS位于OSAL之后,因此可以更轻松地测试和模拟该软件。当RTOS与应用程序紧密耦合时,开发人员需要弄清楚如何使RTOS在连续集成服务器上运行以及如何使其在仿真和集成测试中正常运行。使用OSAL,可以更轻松地模拟行为,这可以帮助节省时间,但更重要的是,可以防止开发人员的压力水平达到临界值。

 

结论

嵌入式系统行业的每个人都不会仅使用一个RTOS。我们可以期望的最好结果是,对于嵌入式系统行业的开发人员而言,采用单个OSAL作为任何嵌入式应用程序的标准接口。那里有潜在的OSAL,例如面向Arm用户的CMSIS-RTOS v2和其他一些特定于微控制器供应商的OSAL。我还没有感觉到开发团队会按应有的方式采用它们。

OSAL的优势在于,它允许开发人员编写应用程序而无需立即选择他们将使用的RTOS。他们可以模拟通用RTOS的行为并编写其应用程序代码,甚至在对其进行测试的同时将要使用的特定RTOS推迟到项目的实施阶段。 OSAL是我们最接近拥有一个RTOS来统治它们的地方。

5 thoughts 上 “一个“ 实时操作系统”来统治所有人”

  1. 如果你’ve used ST’s CubeMX配置工具并将FreeRTOS添加到您的项目中,它实际上使用了OSAL,特别是如上所述的CMSIS-OS或CMSIS-RTOS。它’虽然我是一个很好的配置工具’我不确定将FreeRTOS换成下面的另一个RTOS是多么容易。但是,如果您具有正确的包装器代码,它应该是可行的。

  2. 尽管要考虑这种方法有一些缺点。
    立即想到的是:
    –性能:任何适应层都会对性能产生影响
    –功能:OSAL本质上将是所有受支持的RTOS通用功能的子集
    –明晰。这在某种程度上是前一个的结果。 OSAL通常将覆盖所有常见的目标…。至少是足够接近的那个。以我的经验,使用这种方法时,当真正质疑服务/ API时,常常会发现很难获得明确的答案,并且有时会发现API的功能因OSAL背后的操作系统而略有不同。

    总而言之,有一种OSAL替代方案:选择遵循标准化API(例如ARINC653)的RTOS

    1. 感谢您的评论。尽管我同意我的观点’我还要指出,今天’在硬件和编译器的支持下,对性能的影响很小甚至不存在。我确实发现RTOS很少’遵循标准化API。我真的希望他们会! (此外,您还会100%地关注功能和清晰度。不幸的是,有时这是’为灵活性和可扩展性付费)。再次感谢!

  3. 我不’不要使用RTOS。似乎没有必要。一世 ’在不需要RTOS的情况下,我们已经看到了更多的错误代码。现代ARM MCU’具有优先级设置的向量中断。如果你知道你’这样做,可以将时间紧迫的代码放入高优先级的ISR中,并且后台任务可以在main()中运行。在关键点切换GPIO引脚,并用示波器监视它们。将所有变量保持全局(gasp!),调试很容易。

    但是,如果速度和确定性不那么重要(与大多数嵌入式项目一样),我将使用microPython(尽管使用microPython可以得到一定程度的确定性)。这为我节省了数小时的编程时间。

    此外,如果我确实需要一个真正的OS,例如用于联网或GUI,我’将使用基于Linux的嵌入式系统。他们’重新变得非常便宜。查看洋葱Omega2约10美元。 (//onion.io/omega2/ 或sparkfun.com)

    1. 感谢您的评论。我大都同意,尽管我个人越来越放弃裸机方法,直接进入RTOS。我确实看到了很多拙劣的RTOS实施,但我认为与RTOS本身相比,教育和经验更多的是问题。多谢分享您的经验!

发表评论

您的电子邮件地址不会被公开。 必需的地方已做标记 *

该网站使用Akismet减少垃圾邮件。 了解如何处理您的评论数据.