返回列表 发帖

[原创经验] 从FreeRTOS和uCos等OS的发展看RTOS工具化的趋势

[原创经验] 从FreeRTOS和uCos等OS的发展看RTOS工具化的趋势

从FreeRTOS和uCos等OS的发展看RTOS工具化的趋势

注:登录网站查看帖子效果更佳。


作者:osboy


微信:vincentwan003


QQ:82475491


嵌入式开发联盟MCUOS.COM



有段时间没有关注FreeRTOS和uCosII这类嵌入式操作系统了,更别提eCos这个OS了,当年我刚毕业就搞这些东西,现在想想已经很多年了。因为现在的工作又回到了嵌入式相关的业务,所以放假几天在重新收拾mcuos网站之后,又关注了一下曾经的这两大嵌入式RTOS,当然现在流行的国产OS我还没过多关注,我觉得RTOS甚至是OS都大同小异,玩不出太多的花样,大家无非就是在生态,简单易用和所谓的软硬结合性能上下点功夫而已,所以其他的OS我暂时不做研究,本文可能会有一些涉及到Autosar的东西先不从技术上铺开,仅仅是对当前RTOS的趋势的思考。

AUTOSAR OS:因为最近在研究autosar OS所以对这个OS的复杂的工具链感触颇深,用户可以通过开发工具例如vector developer,配合着metalab的simiulink建模工具就可以实现用户不需要手动编写代码,直接工具模型化自动生成用户程序代码。用户的应用代码可以实现跨多个基础软件厂家提供的OS,使用户方便移植代码到别的vendor的autosar平台上。打的是安全,易用,开发方便的牌,因为没有手动代码了,所以引入不了BUG了,当然这是理想情况。刚才讲的是客户应用的工具化情况,Autosar平台厂家还提供了对基础软件的配置使客户方便的对OS层面的软件进行OS的工具化配置,这里我就想到了我15年前用过的eCos这个操作系统,那时候他就是提供windows工具并且可以用工具对OS进行配置,大家还记得我2006年的第一篇ecos的帖子吗,那时候这个工具很难用,配置出来的东西总会有问题,需要手动调,不过这个工具化的理念是很超前的。回到autosar基础软件的工具配置上来,他也提供了一整套基于autosar方法论的配置和代码生成工具,技术上先不展开了,反正理念是这样的,就是客户用啥组件就配置啥组件。
UCosIII:当我搞过了手机平台linux的驱动开发,搞完了云计算的虚拟化KVM开发,搞完了x86的CPU驱动开发之后,我又回到了嵌入式行业搞autosar开发,当我发现autosar的工具的重要性之后,于是我自然而然的类比到了是不是现在其他的RTOS也都开始工具化了呢?于是开始着手研究之前开发过的几个OS,首先说uCos,2017年3月14号,Micrium正式发布uCOS及其所有中间件的的傻瓜式图形化配置平台Platform Builder,后来不知为何Micrium将其下架了。但是从网上的资料图片可以看出,他也在试图走工具化的道路。

FreeRTOS:而FreeRTOS的工具化,首先STM CubeMx 映入我的眼帘,下面首先看一下我在网上摘录的两张图片,就知道了,STM为了推广他的芯片,做了个配置和代码生成工具,嘿,现在芯片厂家都开始走简单易用的工具之路了。想当年我搞嵌入式ARM7,ARM9的时候,就是提供一堆软件包,工程师自己动手敲代码的需要,那个时候的确是给了工程师好多自己动手的机会,现在不需要了。






大致的意思就是在上面的工具界面劈里啪啦的设置一顿OS和驱动之后,这个工具会自动生成基于STM32特定平台的FreeRTOS代码,如下图:





熟悉RTOS编程的人一看就知道了,这个就是main函数,在里工具自动为你创建好了main函数框架,有一个默认的任务,如果你想实现自己的应用,那么自己添加task,然后实现你的程序逻辑就是了,到了这个里我发现,他这个理念跟autosar的工具理念差不多啊,只不过autosar的工具更复杂一些,并且可以结合simulink实现用户应用的行为建模并且自动生成应用的任务逻辑,而这个CubeMx 工具显得更简单些,更傻瓜些,而autosar的分层更细致,工具的分层也更精深一些而已。

CMSIS-RTOS2CMSIS-RTOS API Version 2(CMSIS-RTOS2) 是基于 Arm® Cortex®-M 处理器的通用 RTOS 接口。它为需要 RTOS 功能的软件提供了一个标准化的 API ,并为用户和软件行业带来了重大的好处:

CMSIS-RTOS2提供了许多应用程序所需的基本功能。

CMIS-RSOT2的统一特征集减少了学习的工作量并简化了软件组件的共享。

使用 CMSIS-RTOS2 的中间件组件是 RTOS 不可知的,并且更容易适应。

CMSIS-RTOS2的标准项目模板可以免费提供 CMSIS-RTOS2 的实现。

以上斜体为摘抄,听上去好牛逼的样子,我简单看了看他的实现,大致就是他不是个OS,仅仅是给市面上的RTOS一个封装,比如他封装了自己的RTXOS, 封装了FreeRTOS,就是ARM认为现在RTOS种类太多了,你们每个RTOS都可以在我的ARM上跑一跑,搞的好乱,现在我要统一一下接口,以后客户的应用就是不管RTOS了,都被我的CMSIS给封装了。看下图的意思就知道了。




这就是ARM的优势之处,因为core是他家的,所以上面的软件,很容易就被ARM大一统了吧,我记得之前ARM的软件可没这么强势,那时候我的arm编译器工具链都是自己编译出来的,有个ADS 2.0也是超贵的那种,现在keil什么的也被他买了,在软件上ARM也开始想统一用他的了,不得不说,现在留给工程师动手的机会真是越来越少了。他的工具界面大致是这个样子:







RT-Thread: 最后还是提一下osboy的同事开发的这套RTOS,现在已经很成功了,商业化额,最近听说搞了个env工具,官网上的介绍如下:






综上可见,OS的工具可视化开发已经成为了一个趋势,这个趋势的主要诱因就是方便人用啊,人们总是追求简单高效的工作方式,说白了就是用很好的工作量赚更多的钱。Osboy个人觉得工具的易用性和OS的生态的确是各个厂家争夺客户的主要竞争力点,但是当每个厂家都是在搞生态,都是在搞工具的时候,那如何体现差异化的竞争力?

1.那就是软件硬件的深度结合技术。

2. 就是工具再更上一个层次,搞模型化开发,彻底抛弃手动代码,这个目前只看到autosar SWC应用开发支持,其他的RTOS还没看见这个思路。

这么一来,大一统的vendor肯定最终是ARM公司啊, 当然某些能做芯片和软件的大公司也会有机会的,但是毕竟核心竞争力芯片的core在ARM手中,最终的竞争力点还是要放到core的竞争上来。


本文PDF版本阅读请下载:



阅读密码:mcuos.com

附件: 您需要登录才可以下载或查看附件。没有帐号?注册(需要真实email认证,请填写有效邮箱地址)
讨厌没有结论的帖子, 讨厌不结贴的会员。
请不要在短消息里问技术性问题.
请不要把你的问题作为附件上传.
我的邮箱:shenghuo456@163.com
QQ:82475491(很少用了)
微信:vincentwan003(天天在)

返回列表