五种RTOS操作系统的介绍

只看该作者 · 2016-10-24 17:34

本帖最后由 jiang390625 于 2016-10-24 17:36 编辑

1.1 VxWorks

VxWorks是美国WindRiver公司的产品，是目前嵌入式系统领域中应用很广泛，市场占有率比较高的嵌入式操作系统。VxWorks实时操作系统由400多个相对独立、短小精悍的目标模块组成，用户可根据需要选择适当的模块来裁剪和配置系统;提供基于优先级的任务调度、任务间同步与通信、中断处理、定时器和内存管理等功能，内建符合POSIX(可移植操作系统接口)规范的内存管理，以及多处理器控制程序;并且具有简明易懂的用户接口，在核心方面甚至可以微缩到8 KB。

1.2 μC/OS-II

μC/OS-II是美国嵌入式系统专家Jean J.Labrosse用C语言编写的一个结构小巧、抢占式的多任务实时内核。μC/OS-II能管理64个任务，并提供任务调度与管理、内存管理、任务间同步与通信、时间管理和中断服务等功能，具有执行效率高、占用空间小、实时性能优良和可扩展性强等特点。

1.3 μClinux

μClinux是一种优秀的嵌入式Linux版本，其全称为micro-control Linux，从字面意思看是指微控制Linux。同标准的Linux相比，μClinux的内核非常小，但是它仍然继承了Linux操作系统的主要特性，包括良好的稳定性和移植性、强大的网络功能、出色的文件系统支持、标准丰富的API，以及TCP/IP网络协议等。因为没有MMU内存管理单元，所以其多任务的实现需要一定技巧。

1.4 eCos

eCos(embedded Configurable operating system)，即嵌入式可配置操作系统。它是一个源代码开放的可配置、可移植、面向深度嵌入式应用的实时操作系统。最大特点是配置灵活，采用模块化设计，核心部分由小的组件构成，包括内核、C语言库和底层运行包等。每个组件可提供大量的配置选项(实时内核也可作为可选配置)，使用eCos提供的配置工具可以很方便地配置，并通过不同的配置使得eCos能够满足不同的嵌入式应用要求。

1.5 FreeRTOS：

以前对FreeRTOS的印象还不错，就因为免费，最近上官网仔细看过以后发现它用的是修改版GPL2，商用确实是免费的，但是必须告知用户你的产品用了FreeRTOS，并且如果用户要求就必须提供源代码。

如果要不谈我用的什么系统，也不想提供源代码，就的付费给它，改授权变成OpenRTOS。

还有更好的呢!如果想要更多的功能，更全的协议栈，更完善完整的安全性，请付更多的钱得到SafeRTOS!看个API文档都要收钱，要其他模块也要收钱(FS，TCP)。要不就自己费点劲移植吧。另外，功能也比较简单，只能支持：队列，信号量和互斥。但是收费版SafeRTOS应该不错，只是不拿钱就见不着(流明的CM3部分型号内建了SafeRTOS的API，出厂就有可以直接用，这个不错。)

最小系统：ROM 6K RAM 2K

只看该作者 · 2016-10-24 17:36

一些内容补充，对比

FreeRTOS和OpenRTOS

FreeRTOS和OpenRTOS的共享相同的源码，只是 OpenRTOS 为 FreeRTOS 披上’commercial and legal wrapper’‘

用户从FreeRTOS更新到OpenRTOS主要有两个原因：

(1)为了克服FreeRTOS修改版的GPL许可证限制。

(2)为了获得额外的服务，如专业的技术支持，高质量的中间件，培训，咨询和相应的工具

FreeRTOS修改版的GPL许可证限制

修改版的GPL许可证有如下几个缺陷(There are several reasons why developers may find the FreeRTOS modified GPL licence restrictive.)

(1)公司可能有一个全面禁止在他们的项目中使用GPL授权的软件。

(2)他们可能需要IP赔偿。

(3)他们可能更愿意在他们的产品中，避免FreeRTOS的许可证要求承认他们使用FreeRTOS的。

一个OPENRTOS许可证删除了修改后的GPL的限制，提供知识产权保障，并允许开发者保持匿名。

FreeRTOS和SafeRTOS

SafeRTOS也是基于FreeRTOS的，但是和FreeRTOS不同，被安全方面的专家做了重新设计。

SAFERTOS was initially certified in 2007 by TüV SüD to IEC 61508-3 SIL 3, the highest level possible for a software only component.

Today SAFERTOS has grown to be a leading safety critical RTOS solution supporting a wide range of international design safety standards, including:

Industrial IEC 61508 (2010)
Railway EN 50128
Medical IEC 62304/FDA 510K
Nuclear IEC 61513, IEC 62138, ASME NQA-1 2008
Process IEC 61511
Automotive ISO 26262
Aerospace DO178B

只看该作者 · 2016-10-24 17:37

如何引入RTOS？

很多朋友和同事都问我，在实际中如何选择 RTOS。这个问题好难回答啊，非常复杂。实际中至少有三种情况：

1.有些地方根本不需要 RTOS，可能系统设计者是爱好 RTOS 的人，:-)，硬上了RTOS；

2.有些地方需要 RTOS, 但因为各种原因，没有使用 RTOS；

3.最糟糕的情况是，选择的错误的 RTOS 进行开发，要了开发团队的命……

只看该作者 · 2016-10-24 17:43

是否需要RTOS？
在选择之前可以问问以下几个问题：

1.系统对一些事件的响应延迟时间有要求吗？该时限在微秒级。

2.系统对一些事件的处理有时限要求？该时限接近 CPU 全速处理该事件一次需要的时间，相差不过毫秒级别。

3.系统中这些事件的处理代码复杂吗(平均每个事件的处理代码不超过100行标准C代码，无函数调用)？这种事件超过5个以上？

4.系统有RAM、ROM的限制，使得大多数操作系统如 Linux、uClinux、WinCE 无**常工作吗？

5.系统有一定的规模，超过 2W 行标准C/C++代码吗？系统中有多个逻辑事务，逻辑事务之间有同步或数据交换吗？

6.产品或系统生命周期长，有后续升级、发展的要求吗?

7.团队对选择的 RTOS 了解吗？有 RTOS 实施方面的专家吗？

如果上面有超过 2 个问题回答是的朋友们注意了，您很可能需要 RTOS 进行您系统的开发。如果超过 4 个问题回答是的朋友，您必须使用 RTOS 了。

只看该作者 · 2016-10-24 17:44

如何选择RTOS?

当您决定使用 RTOS，下面的问题就是选择什么 RTOS 了。市面上的RTOS实在是太多，各种各样的都有，我们选择一个RTOS的时候，可能要权衡以下因素：

1.成本

2.可靠性

3.实时性

4.工具链

5.模块丰富

6.RTOS 内核 RAM、ROM 占用量

7.支持

成本主要是 RTOS 的版费、学习成本。这个差别可大了，有些操作系统，如商业的VxWorks、QNX、Lynx、uC/OS，贵啊，但拍了银子，人家肯定会教您上手的。但很多操作系统，如 FreeRTOS、 RTEMS、ecos、RT-Thread，商业使用几乎是没有成本的，也没有任何的版权问题。撇开这些商业收费的 RTOS 不谈，就谈这些开源免费的 RTOS，成本主要是学习成本了。如RTEMS这种操作系统就不太好学，资料少，本身的复杂度也高;如 FreeRTOS，小巧，研究的人也多，本身代码也不复杂，学习曲线不陡峭，很容易爬上去。

可靠性是靠时间沉淀的。市场上不乏一些后起之秀，如rt-thread，相比 rtems 这种鼻祖类的 rtos，还稍显稚嫩。这并不意味这我们什么都选择 rtems，那 rt-thread 怎么发展?对于小型的项目，可以试一试。大型项目，为了减少技术上的风险，还是谨慎为妙。

实时性，这个应该是 RTOS 的看家本领，我初学 rtos 的时候，好喜欢看牛人搞得 RTOS 对比表格。上下文切换时间啊，中断响应时延啊……总喜欢挑那些时间最小的系统……但后来我知道了，事实上不是几个对比表格就能说清楚问题的。下面会详细说到这些问题。

工具链，它往往决定我们开发的效率，和最终产品交付的质量。有一些 RTOS 没那么幸运，没有让你选择工具链的权利，就算有，也需要付出很大的代价。如 RTEMS 采用GNU的工具链，gnu 的工具链不好用，我就尝试过把 rtems 移到 iar ewarm 下。后来，搞到一半的时候，不得不放弃，付出的精力已经超出了我的承受范围。但 freeRTOS、uC/OS 这类小 RTOS，只要编译器支持编译可重入代码就可以，这条只有老掉牙的编译器不行。所以基本上是个C编译器都可以做Free RTOS、uC/OS的编译。

模块丰富，有没有TCP/IP协议栈、文件系统、CAN协议栈、图形界面等。当然这个都不是必须的，对于简单的产品，可能这些模块都用不到。对于复杂的系统，这些集成好的模块，会大大节省开发时间。自己也可以移植相关的模块，可能会有几个切实的问题不好解决：模块因为不符合 rtos 的设计思想，会对整体的实时性造成损害;也可能因为模块使用的库，和 rtos 使用的库相冲突……

内核 RAM、ROM 的占用量实际上要求 Rtos 高度可裁剪。不是所有内核裁剪到最后都能满足要求，RTOS 都有个最低的 RAM、ROM 要求，只剩一些最基本的服务。每加一个特性会增加一些资源，可以查阅相关资料得到这方面信息，确定系统资源可以保证顺畅的使用该 RTOS。

支持，如果是商业系统，那不用担心，既然付了银子，人家肯定保证实施过程的顺畅。如果是开源系统，开发团队没有像样的 rtos 专家可不行。虽然 rtos 系统都是相通的，了解另外一个 rtos 很快，但有时候也不尽然。RTEMS 这么复杂的 RTOS 搞懂了，去弄 freeRTOS、uC/OS、rt-Thread 小麻雀，自然没问题;要是弄 QNX、VxWorks、Lynx，还是要费点功夫。 RTOS 在开发过程中会遇到很多问题，比如栈的估算、任务优先级的设计、内存的设计、实时性的设计等，都是很不好弄的问题。最好团队内有相关 RTOS 的专家，要是学习的话无所谓，研发产品和系统的话，那就是大问题了。

只看该作者 · 2016-10-25 15:58

关注一下,正好考虑要用os

只看该作者 · 2016-10-28 13:06

最近关注到北京一位先生也自己开发了一个RTOS，不错

只看该作者 · 2016-10-28 13:57

关注下

五种RTOS操作系统的介绍

相关下载

相关帖子

技术新星奖章