RTOS的ABC讨论（转） - Raw-OS论坛 -
中国电子技术论坛 -
最好最受欢迎电子论坛!
后使用快捷导航没有帐号？
Hot [直播]
RTOS的ABC讨论（转）
14:20:19　　
作者：wateras1
学习和应用 RTOS 好多年了。对RTOS的发展和应用有一些粗浅的想法。尤其认识了RAW OS(一款新的RTOS)的作者后，就更多的想法。就写在这里，让大家拍砖吧。
我心里一直对这几个问题耿耿于怀。
<font color="#、什么行业在什么情况下应用RTOS?
<font color="#、RTOS能解决什么样的问题？解决不了什么样的问题？
RTOS，稍微知道点技术的人都知道是Real-Time Operating System，意为实时操作系统，但“实时”这两个字却并不好理解。有硬实时和软实时之分。硬实时，可以理解为一个计算过程不仅仅依赖于计算结果的正确性，还依赖于结果的返回时间。操作系统可以保证这个时间的正确性。软实时，这个时间就不怎么太保证，偶尔的会超出，仅仅有统计上的意义。不严谨的说是这个意思。
因为要实时，所以调度算法不能使用普通的调度算法，调度算法有很多种；RTOS使用单调速率调度算法(RMS, Rate-Monotonic Scheduling)。当然，调度算法还有其他的种类，比如说最早截止时间优先算法(EDF)和最短空闲时间优先算法(LLF)，不过这些算法都是实验室里的算法。现在是这样，恐怕以后也是这样。还是RMS独领RTOS。RMS有一些假设，在这个假设的前提下，任务的执行时间不能超过70%，否则处理器调度不过来这些任务。但是这个假设比较的严格，适当的放宽后可以达到80%甚至85%。有兴趣的朋友可以读读相关的论文。
[1] Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment, C.L.Liu
[2] Scheduling hard real-time systems: a review, A. Burns
[3] The Rate Monotonic Scheduling Algorithm: Exact Characterization And Average Case Behavior, John Lehoczky, Lui Sha, Ye Ding
看了之后，不禁佩服这些先哲，早已把这些问题看得这么透。我们只需要应用就好了。
市面上有许多RTOS操作系统，threadx, freeRtos, uC/OS-II, rtems, QNX, LynxOS, VxWorks, raw OS, ecos, NuttX……太多了。我们用了实时操作系统以为自己的应用就装进了保险箱，可是，Liu早就在1873年告诉我们，RMS算法是个静态的调度算法，也就是说，在应用运行之前，必须对应用做合理的分析。使得RMS可以调度该任务集，这样才能保证是实时的。换句话说，就是要分析一下，咱写的任务能不能让CPU调度过来，还要合理分配优先级。RTOS只是为我们提供好一个基石，而我们在这个基石上要构建我们的应用，还需要进一步的详尽的设计来保证RMS的正常工作。
什么行业什么情况下应用rtos呢？这个问题困扰了我很久，我之所以进入Rtos这个领域，完全是因为rtos操作系统经常与嵌入式三个字挂着钩。工作就与MCU打交道，久了自然就与rtos熟悉了。环顾四周，一般都是做一些单片机应用的公司用rtos。因为rtos已经移植好了，选了它，可以不用费心去写驱动，不用花力气去搞编译脚本，不用去费力气去调试底层。应用随便往上一放就好，可以说不费吹灰之力。 我身边大多数的公司都是这样，他们应用了rtos，甚至不知道硬实时和软实时的区别，甚至不知道硬实时对任务集调度时间有要求(不能超过70%)。 这类应用就是图方便，实惠，免费。
再有就是军事部门用的系统，我有朋友在中科院做高速并行计算平台，用VxWorks。通过分析，大多数时候，这种应用要得仅仅是性能，而不是实时。因为足够的快就行了。如何足够的快，首先要微内核，在然后就是内核可剥夺。可以说，RMS算法的副产品性能恐怕才是他们真正需要的。
我们的嫦娥，神9上天了，听说里面用得rtems只剩下“芯”了。我一个从事这方面的朋友对我说，因为你不熟悉，上天的东西没你想的那么先进。其实东西很老旧的，都是40MHz、50MHz的星载处理器(其实就是咱们用的powerpc和sparc等cpu防辐射加强版)。要得就是可靠性。我一想是啊，上了天了，坏了不能再发个飞船去修啊。那还不如重新搞个新的上天呢。rtos的可靠性，稳定性；由于硬实时的一个最大的好处，就是行为可预测，加上RTOS的实现的简洁，大量的测试。rtos的可靠性和稳定性是非linux和windows这样的桌面级操作系统能比的。(Ps, linux新内核也在弄rtos的部分，可以关注啊)
和Raw OS的作者聊起，他说 RTOS 做通用的控制。加上我的一点点行业经验，RTOS的应用领域包括部分的工业控制和一些医疗、航空航天电子，极小部分的消费类电子。绝大部分需要实时性的项目，其实里面真正需要实时的任务也不过就那么几个(一般不超过3个)。并不是每个任务都需要实时，那是不切实际的。
大部分RTOS为了所谓的快速，使用了平面的内存结构，放弃使用MMU的机会。也就是实地址和虚地址是一样的。实现从外存加载应用程序无法实现现代操作系统意义上的进程、线程的概念。这个特性重要不重要呢？实际上我觉得还是非常重要的，因为它能拓展RTOS应用领域，从而使RTOS有更加旺盛的生命力。但我并不主张，什么应用都用MMU，微内核对成本的节约，有时候是立竿见影的。只是，消费类电子一个巨大广阔的市场，因为他们需要系统高度的可扩展性，即从外存加载应用程序；而大部分RTOS必须和应用程序绑定，和为一体。加应用程序，必须重新编译然后升级固件。这对消费电子是不可想象的。支持了MMU的rtos，可以实现外存加载应用程序。有些朋友又担心MMU会拖慢整个系统的速度，我这么觉得，可以把RT任务和内核编译在一起，或者需要RT的任务直接全部集合到一个特殊的内存地址里，由操作系统给予特殊处理。抑或，采用合适的算法，减少不必要的调度和页面切换。使得整个系统更加高效。
rtos 引以为豪的中断延迟时间，实际上是有最大值和最小值的。一般来说，即使最快的CPU，换上最高效的处理系统，软件控制时间的精确度只能在毫秒级别。换句话说，软件接收到中断，作出判断，结束控制，这个时间只能精确到ms级别。比如说，最大误差不超过2个毫秒啊，或者5个毫秒之内。当然也有例外，如果判断计算过程过于简单，如果没有操作系统，只是前后台系统。在关中断的情况下，控制时间可以精确到微秒级，那样的话，特殊应用是可以，通用应用是没有任何意义的。所以，工业控制和高速应用里才会有PLD和FPGA的身影。所以，rtos里想延迟微秒级别的话，只能采用忙等方式；如果采用任务切换的方式，那延迟时间是不可控的。别以为，延时多长时间是多长时间，rtos也是软件，免不了俗的。真需要小于1ms的延时，linux内核里的udelay已经给了我们答案。
rtos 大都异常简洁。这是好听的话，说句不好听的，就是简陋。特别是没有一个统一的驱动结构和开发模型。比如说uC/OS-II,freeRTOS，这样的操作系统。与其说是操作系统，还不如说是个调度算法。没有统一的驱动结构或开发模型，使得很多既有的成果可能因为系统核心的升级而报废；项目与项目之间的既有成果不能得到利用。从一个系统迁移到另外系统上，因为设计者所站的高度问题，可能使得成果难以复用。这也是很多rtos设计者经常忽略的一个事情。有格局的东西才能发展得辉煌。rtems，个人认为在所有开源rtos中就是有格局的rtos之一。真正的做到了简洁不简单，提供完善的开发模型。其实这也是一个重要的原因，限制其在消费类电子中大量使用的原因。消费电子大多延续性很强，软件项目很大，要求软件在不同的硬件上能延续，付出最少的代价。环顾四周，只有linux做到了，而他不是rtos，不过好消息就是 linux 会融入越来越多的rtos设计理念。
rtos的未来，在mcu领域个人还是看好的，不过在mcu领域rtos尚属于百家争鸣的阶段。发展的好发展的不好，主要是商业的合作模式和推广模式，与技术没什么太大的关系。在其他领域，如果能融入MMU,支持加载分离的应用程序、支持SMP(rtos一般都选择amp方式)对rtos发展也会有巨大的推动作用，特别是在消费类电子领域。毕竟，用得人多了，才会有人愿意发展他。个人浅见，欢迎拍砖。(标注：作者雪松)
00:00:52　　
顶，rtems刚开始学习中
11:16:14　　
PCB在线计价下单
板子大小：
板子数量：
PCB 在线计价
强烈推荐 使用&&rtems 和&&eCOS
适合学习和商业开发
10:11:54　　
很好的文章。赞一个。
19:22:00　　
留待以后学习之用
22:19:25　　
RTOS在汽车电子领域中应用很广啊，想想Airbag收到碰撞信号到点火如果时间不确定，会不会死人啊
17:38:46　　
刚开始学，先找个资料全的先搞懂。
Powered by6416人阅读
RTOS---(1)基础介绍（2）
(原创文章，欢迎转载，请注明出处)
（1）引入RTOS？
很多朋友和同事都问我，在实际中如何选择 RTOS。这个问题好难回答啊，非常复杂。实际中至少有三种情况：
1.有些地方根本不需要 RTOS，可能系统设计者是爱好 RTOS 的人，:-)，硬上了RTOS；
2.有些地方需要 RTOS, 但因为各种原因，没有使用 RTOS；
3.最糟糕的情况是，选择的错误的 RTOS 进行开发，要了开发团队的命……
（2）是否需要RTOS？
在选择之前可以问问以下几个问题：
1.系统对一些事件的响应延迟时间有要求吗？该时限在微秒级。
2.系统对一些事件的处理有时限要求？ 该时限接近 CPU 全速处理该事件一次需要的时间，相差不过毫秒级别。
3.系统中这些事件的处理代码复杂吗(平均每个事件的处理代码不超过100行标准C代码，无函数调用)？这种事件超过5个以上？
4.系统有RAM、ROM的限制，使得大多数操作系统如 linux、uClinux、WinCE 无法正常工作吗？
5.系统有一定的规模，超过 2W 行标准C/C&#43;&#43;代码吗？系统中有多个逻辑事务，逻辑事务之间有同步或数据交换吗？
6.产品或系统生命周期长，有后续升级、发展的要求吗?
7.团队对选择的 RTOS 了解吗？有 RTOS 实施方面的专家吗？
如果上面有超过 2 个问题回答是的朋友们注意了，您很可能需要 RTOS 进行您系统的开发。如果超过 4 个问题回答是的朋友，您必须使用 RTOS 了。
（3）如何选择RTOS？
&&&&&&& 当您决定使用 RTOS，下面的问题就是选择什么 RTOS 了。市面上的RTOS实在是太多，各种各样的都有，我们选择一个RTOS的时候，可能要权衡以下因素：
5.模块丰富
6.RTOS 内核 RAM、ROM 占用量
成本主要是 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 对比表&#26684;。上下文切换时间啊，中断响应时延啊……总喜欢挑那些时间最小的系统……但后来我知道了，事实上不是几个对比表&#26684;就能说清楚问题的。下面会详细说到这些问题。
工具链，它往往决定我们开发的效率，和最终产品交付的质量。有一些 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 的专家，要是学习的话无所谓，研发产品和系统的话，那就是大问题了。
(To be continued...)
(原创文章，欢迎转载，请注明出处)
（4）几种嵌入式RTOS的分析与比较
-----引自：http://blog.csdn.net/sailor_8318/article/details/4009911
(开源操作系统可以参见网址：)
&&&&&&&&&&
1). 4种操作系统的介绍
1.1&&& VxWorks
&&&&&& VxWorks是美国WindRiver公司的产品，是目前嵌入式系统领域中应用很广泛，市场占有率比较高的嵌入式操作系统。VxWorks实时操作系统由400多个相对独立、短小精悍的目标模块组成，用户可根据需要选择适当的模块来裁剪和配置系统；提供基于优先级的任务调度、任务间同步与通信、中断处理、定时器和内存管理等功能，内建符合POSIX(可移植操作系统接口)规范的内存管理，以及多处理器控制程序；并且具有简明易懂的用户接口，在核心方面甚至可以微缩到8
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
/*补充内容*/
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 62304/FDA 510K
IEC 61513, IEC 62138, ASME NQA-1 2008
Automotive
2) &&&&& 性能分析与比较
任务管理、任务及中断间的同步与通信机制、内存管理、中断管理、文件系统、对硬件的支持和系统移植这几方面是实时操作系统的主要性能。下面就从这几个方面着手对上述4种操作系统进行分析与比较。
2.1&&& 任务管理
任务管理是嵌入式实时操作系统的核心和灵魂，决定了操作系统的实时性能。它通常包含优先级设置、多任务调度机制和时间确定性等部分。
优先级设置
嵌入式操作系统支持多任务，每个任务都具有优先级，任务越重要，赋予的优先级应越高。优先级的设置分为静态优先级和动态优先级两种。静态优先级指的是每个任务在运行前都被赋予一个优先级，而且这个优先级在系统运行期间正常情况下是不能改变的，但允许通过系统调函函数改变任务的优先级；动态优先级则是指每个任务的优先级(特别是应用程序的优先级)在系统运行时可以动态地改变，这种改变是调度算法决定的，而非通过系统调用人为改变的。
多任务调度机制
任务调度主要是协调任务对CPU资源的争夺使用。对系统资源非常匮乏的嵌入式系统来说，任务调度尤为重要，它直接影响到系统的实时性能。通常，多任务调度机制分为基于优先级抢占式调度和时间片轮转调度。
基于优先级抢占式调度（PBP，Priority Based and Preemptive）：系统中每个任务都有一个优先级，内核总是将CPU分配给处于就绪态的优先级最高的任务运行。如果系统发现就绪队列中有比当前运行任务更高的优先级任务，就把当前运行任务置于就绪队列中，调入高优先级任务运行。系统采用优先级抢占方式进行调度，可以保证重要的突发事件及时得到处理。
时间片轮转调度（RR，Round Robin） ：让优先级相同的处于就绪状态的任务按时间片使用CPU，以防止同优先级的某一任务长时间独占CPU。
在一般情况下，嵌入式实时操作系统采用基于优先级抢占式调度与时间片轮转调度相结合的调度机制。
时间的可确定性
嵌入式实时操作系统函数调用与服务的执行时间应具有可确定性。系统服务的执行时间不依赖于应用程序任务的多少。基于此特征，系统完成某个确定任务的时间是可预测的。表1具体列出了4种操作系统的调度机制。
4种嵌入式实时操作系统都支持多任务，只是在支持任务数量上和任务调度机制上有所不同。VxWorks具有高效的任务管理功能，它支持多任务，可分配256个优先级，支持优先级抢占式调试和时间片轮转调度，实时性最好。μC/OS-II内核是针对实时系统的要求设计实现的，只支持基于固定优先级抢占式调度；调度方法简单，可以满足较高的实时性要求。μClinux在结构上继承了标准Linux的多任务实现方式，分为实时进程和普通进程，分别采用先来先服务和时间片轮转调度；仅针对中低档嵌入式CPU特点进行改良，且不支持内核抢占。eCos调度方法丰富，提供了两种基于优先级的调度器(即位图调度器和多级队列调度器)，允许用户在进行配置时选择其中一个凋度器，适应性好。
2.2&&& 任务及中断间的同步与通信机制
实时操作系统的功能一般要通过若干任务和中断服务程序共同完成。任务与任务之间、任务与中断间任务及中断服务程序之间必须协调动作，互相配合，这就涉及任务间的同步与通信问题。嵌入式实时操作系统通常是通过信号量Semaphere、互斥信号量Mutex、事件标志Event和异步信号Signal来实现同步，通过消息邮箱MailBox、消息队列没Message、管道Pipe和共享内存Share
Mem来提供通信服务。由于互斥信号量的使用，带来了实时操作系统中常见的优先级反转问题。优先级反转是一种不确定的延迟形式，当高优先级任务企图访问已被低优先级占有的共享资源时，必须等待低优先级任务释放共享资源；如果这时低优先级任务被一个或多个中优先级任务抢占，那么高优先级任务被延迟的时间将更进一步延长，实时性难以保证。因此，应采取相关措施以尽鼍避免出现优先级反转问题。实时系统通常采用优先级继承和优先级置顶机制。
优先级继承是指拥有互斥信号量的任务被提升到与下一个在等待该互斥信号量的最高优先级任务相同的优先级；优先级置顶是指获得互斥量的任务将其优先级提升到一个事先规定好的&#20540;。表2为4种操作系统的同步与通信机制的比较。
4种系统都具有灵话的任务间同步与通信机制，都可以通过信号量、消息队列来实现同步与通信，但是VxWorks与μClinux都不支持邮箱和事件标志，而且除了μClinux和eCos中的位图调度器，其他操作系统都采取了措施抑制优先级反转。
2.3&&& 内存管理
内存管理主要包括：内存分配原则，存储保护和内存分配方式。
内存分配原则
内存分配原则包括快速性、可靠性和高效性。其中，快速性要求内存分配过程要尽可能快，所以一般采用简单、快速的分配算法；可靠性指的是内存分配的请求必须得到满足；系统强调高效性的要求，不仅仅是对系统成本的要求，而且由于系统本身可配置的内存容量也是很有限的，所以要尽可能地避免浪费。嵌入式系统通常会根据特定的需求对内存分配方案进行规划，从而避免内存碎片。
通常在操作系统的内存中既有系统程序也有用户程序，为了使两者都能正常运行，避免程序间相互干扰，需要对内存中的程序和数据进行保护。存储保护通常需要硬件支持，在很多系统中都采用MMU，并结合软件实现；但由于嵌入式系统的成本限制内核和用户程序通常都在相同的内存空间中。因此是否支持存储保护一方面取决于CPU是否支持MMU及不同的运行级别，如ARM7TDMI核不支持MMU，大多数DSP都不支持MMU和运行级别；另一方面依赖于操作系统是否在软件上进行支持，uC/OS、eCos等本身就不支持虚拟内存管理。VxWorks也有不同的版本，6.0版本以下就不支持MMU。
内存分配方式
内存分配方式可分为静态分配和动态分配。静态分配是在程序运行前一次性分配给相应内存，并且在程序运行期间中不允许再申请或在内存中移动；动态分配则允许在程序运行整个过程中进行内存分配。静态分配使系统失去了灵活性，但对于实时性要求比较高的系统是必需的，通常情况下这些系统的内存有限，用户的全局数据都会精心规划，只有内核本身会使用一些动态内存；而动态分配赋予了系统设计者更多自主性，可以灵活地调整系统的功能。
VxWorks对内存的使用采用的是Flat Mode，可被静态或动态链接。VxWorks为用户提供了两种内存区域Region和Partition。Region是变长的内存区，用户可以从创建的Region中分配Segment，其特点是容易产生碎片，但灵活并且不浪费；Partition是定长的内存区，用户可以从刨建的Partition中分配Buffer，其特点是不会产生碎片，效率高但是易浪费。VxWorks采用最先算法分配内存。
μC/OS-II把连续的大块内存按分区来管理，每个分区中都包含整数个大小相同的内存块，但不同分区之间内存的太小可以不同。用户动态分配内存时，只须选择一个适当的分区，按块来分配内存，释放时将该块放回到以前所属的分区，这样就消除了因多次动态分配和释放内存所引起的碎片问题。
μClinux是针对没有MMU的处理器设计的，不能使用处理器的虚拟内存管理技术，只能采用实存储器管理策略。系统使用分页内存分配方式，在启动时对实际存储器进行分页。系统对内存的访问是直接的，操作系统对内存空间没有保护，多个进程可共享一个运行空间，所以，即使是一个无特权进程调用一个无效指针也会触发一个地址错误，并有可能引起程序崩溃甚至系统崩溃。
eCos对内存分配既不分段也不分页，而是采用一种基于内存池的动态内存分配机制。通过两种内存池来实现两种内存管理方法：一种是变长的内存池；另一种是定长的内存池，类&#20284;于VxWorb的管理方案。表3为4种操作系统内存管理的比较。
2.4&&& 中断管理
中断管理是实时系统中一个很重要的部分，系统经常通过中断与外部事件交互。主要考虑是否支持中断嵌套、中断处理机制、中断延时等。
VxWorks的中断管理
VxWorks操作系统中断管理采用中断处理与普通任务分别在不同栈中处理的中断处理机制，使得中断只会引发一些关键寄存器的存储，而不会导致任务的上下文切换，从而极大地缩短了中断延时。同时，VxWorks的中断处理程序一般在最短时间内通告中断的发生，而将其他的非实时处理尽量放入被引发的中断服务任务中来完成，这也缩短了中断处理的时间，可有效减少中断延时。所有中断处理程序使用相同的中断堆栈。为了能处理最坏情况下的中断嵌套，必须分配足够大的中断堆栈空间。
μC/OS-II的中断管理
μC/OS-II中断处理比较简单。一个中断向量上只能挂一个中断服务子程序ISR，而且用户代码必须都在ISR中完成。ISR需要做的事情越多，中断延时也就越长。是否支持中断嵌套取决于具体实现，如在ARM处理器上当选择中断嵌套时需要切换不同的处理器模式，实现起来也比较麻烦。
μClinux的中断管理
μClinux操作系统将中断处理分为两部分：顶半处理和底半处理。在顶半处理中，必须关中断运行，且仅进行必要的、非常少、速度快的处理，其他处理交给底半处理；底半处理执行那些复杂、耗时的处理，而且允许被中断。通常在硬件中断返回的时候会执行底半部的软中断，若软中断太多则会交给专门的内核处理任务处理，此时中断返回，避免由于中断运行时间过长影响其它其他进程。因此在顶半部中断是不会嵌套的。所有的中断服务下半部将顺序执行。所有的中断处理程序共用系统堆栈。
eCos的中断管理
eCos使用了分层式中断处理机制，把中断处理分为传统的ISR和滞后中断服务程序DSR。类&#20284;于μClinux的处理机制，这种机制可以在中断允许时运行DSR，因此在处理较低优先级中断时允许高优先级的中断和处理。为了极大地缩短中断延时，ISR应当可以快速运行。如果中断引起的服务量少，则ISR可以单独处理中断；如果中断服务复杂，则ISR只屏蔽中断源，然后交由DSR处理。
2.5&&& 文件系统
所谓&文件系统&是指负责存取和管理文件信息的机构，也可以说是负责文件的建立、撤销、组织、读写、修改、复制，以及对文件管理所需的其他资源实施管理的软件部分。
VxWorks操作系统在文件系统与设备驱动程序之间使用一种标准的I/O口操作接口，且支持MS-DOS、RT-11、RFS、CD-ROM、RAW等文件系统。这样，在单个VxWorks操作系统中可以运行多个相同或不同种类的文件系统。
μC/OS-II是面向中小型嵌入式系统的，即使包含全部功能，编译后内核也不到10 KB，所以系统本身并没有提供对文件系统的支持。但是μC/OS-II具有良好的扩展性能，如果需要也可自行加入文件系统的内容。
μClinux继承了Linux完善的文件系统性能，采用VFS机制，可以支持ROMFS、NFS、ext2、MS-DOS、JFFS等文件系统。但一般采用ROMFS文件系统，这种文件系统相对于一般的文件系统(如ext2)占用更少的空间。但是ROMFS文件系统不支持动态擦写保存，对于系统需要动态保存的数据须采用虚拟RAM盘／JFFS的方法进行处理。
eCos操作系统的可配置性非常强大，用户可以自己加入所需的文件系统。
2.6&&& 对硬件的支持
VxWorks、μC/OS-II、μClinux和eCos这4种操作系统都支持当前流行的大部分嵌入式CPU。μC/OS-II支持从8位到32位的CPU，VxWorks、μClinux和eCos可以在16位、32位和64位等不同体系结构之间移植。
由于μClinux继承了Linux的大部分性能，所以至少需要512KB的RAM空间，lMB的ROM／Flash空间；而μC/OS-II和eCos由于本身内核就很小，经过裁剪后的代码最小可以分别为2 KB和10 KB，所需的最小数据RAM空间分别为4
KB和10 KB。总的来说，4种系统对硬件的要求比较低，比较经济。具体比较如表4所列。
2.7&&& 系统移植
嵌入式操作系统移植的目的是使嵌入式操作系统能在某个微处理器或微控制器上运行。4种系统中VxWorks是商用操作系统的有很多API函数及相关技术支持，所以移植和二次开发比较容易，但是移植成本较高。其他3种系统的结构化设计便于把与处理器相关的部分分离出来，所以被移植到新的处理器上也是可能的。μC/OS-II的移植相对比较简单，只需要修改与处理器相关的代码就可以了。μClinux是Linux针对嵌入式系统的一种改良，其结构比较复杂。移植μClinux，目标处理器除了应满足μC/OS-II移植所需的条件外，还需要足够容量的外部ROM和RAM。eCos系统的可移植性明显比μC/OS-II和μClinux好。在eCos系统中，每个硬件平台都有一个单独的目录，用于存放引对这一硬件平台的硬件抽象层的代码和配置信息；而μClinux的硬件抽象层的代码则分布在好几个目录中，通过命令来选择不同硬件平台的代码。所以，修改eCos代码相对简单，移植也相对容易。
2.8&&& 结论
&&&&&& 这4种嵌入式实时操作系统在嵌入式系统的应用非常广泛，但是又具有各自的特点。根据上述比较，归纳出各自的适用领域。
&&&&&&& VxWorks是一套类&#20284;于Unix的实时操作系统，它内建了符合POSIX规范的内存管理，以及多处理器控制程序，并且具有简明易懂的用户接口，在核心方面甚至可以微缩到8 KB。它由400多个相对独立的、短小精悍的目标模块组成，用户可根据需要选择适当模块来裁剪和配置系统，有效地保证了系统的安全性和可靠性。它被广泛地应用在通信、军事、航空、航天等高尖技术及实时性要求极高的领域，尤其是在许多关键应用方面，VxWorks还是一枝独秀。例如，美国波音公司就在其最新的787客机中采用了此操作系统；而在外层空间探索领域，VxWorks则一直是美国太空总署NASA的最爱。
&&&&&& μC/OS-II是一个结构简单、功能完备和实时性很强的嵌入式操作系统内核，适合于广大的嵌入式系统开发人员和爱好者入门学习，以及高校教学和科研。μC/OS-II很适合开发那些对系统要求不是很苛刻，且RAM和ROM有限的各种小型嵌入式系统设备。
&&&&&&& μClinux最大特点在于针对无MMU处理器设计，可以利用功能强大的Linux资源，因此适合开发对时间要求不高的小容量、低成本的各类产品，特别适用于开发与网络应用密切相关的嵌入式设备或者PDA设备。例如，CISCO公司的／4000路由器就是基于μClinux操作系统开发的。
&&&&&&& eCos最大特点是配置灵活，而且是面向深度嵌入式应用的，很适合用于一些商业级或工业级对成本敏感的嵌入式系统，例如消费电子类领域中的一些应用。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：184543次
积分：2228
积分：2228
排名：第16176名
原创：21篇
转载：151篇
评论：14条
(26)(57)(42)(31)(16)
test for ****}