关于RTOS，前世今生，如何选择，杂谈……

coolbacon

1980年，美国Ready System公司推出了实时操作系统VRTX/OS算起，如今已有30年的历史，RTOS产品也是繁花似锦。20世纪80年代，除VRTX外，还有IPI公司的MTOS和ISI公司的PSOS。到了20世纪90年代后，由于现代操作系统的思想运用，诞生了很多如今都在广泛应用的实时操作系统(RTOS)，如大家熟知的VxWorks、μC/OS、QNX、Lynx、eCOS等。


21世纪，由于商业领域的运作和市场的要求，RTOS产品开始兼并整合，一些产品被兼并淘汰，如PSOS被Windriver收购，主要功能特点合并到VxWorks中；另外一些产品则壮大成熟，如商业上极其成功的VxWorks，和几乎所有MCU都可以使用的μC/OS-II，现在已经发展到了μC/OS-III。当然也出现一些后起之秀，如中国人自己研发的Delta OS、RT-thread和开源世界的FreeRTOS。


RTOS大都是以应用为主的可定制的操作系统。软件模块可被高度的裁剪、定制，以适应各种不同的应用，不同的硬件条件，同时在有限的资源下实现性能的最优化。这是传统的桌面操作系统、服务器操作系统所不及的。进入20世纪90年代后，RTOS在嵌入式系统设计中的主导地位已经形成。它的发展有以下特点：
1.    新处理器大量运用，要求RTOS易于移植，以便在短时间内支持不同的处理器；消费类电子产品对实时性要求并不高，如掌上电脑、手机、机顶盒等，但对软件的可维护性、扩展性、易用性、交互性有比较高的要求，使得WinCE、Linux和uCLinux等软实时操作系统广泛地被应用到消费类电子产品中；
2.    由于电信设备、控制系统的高可靠性，对RTOS提出了新的要求，如双机热备份、线程迁移、使用MMU保护RTOS内核等；
3.    芯片制造技术的提升，多核处理器大量运用，要求RTOS支持单芯片多处理器(Chip-Multiprocessor，CMP)、对称多处理器(Symmetric Multiprocessor，SMP)、非对称多处理器(Asymmetric Multiprocessor，ASMP)；
4.    系统级别的应用越来越多，要求系统支持各种各样的协议栈、文件系统、Web服务器、数据库、图形界面，甚至支持Java虚拟机和脚本语言；
5.    开放源码已经成为大势所趋，一些商业老牌的RTOS已经向授权客户开发源码，如VxWorks、QNX等。
6.    RTOS一般都有一套自己的集成开发环境，便于操作系统在实际应用中的定制和应用开发工作，也有采用GNU工具链或第三方工具链的RTOS产品，但工具链大都也经过整合加工，变得更加易用。


————————————————
版权声明：本文为CSDN博主「coolbacon」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/coolbacon/article/details/6436000

coolbacon

嵌入式开发不同于PC平台的开发，它首先面临着软件与硬件同时成熟的风险。同时市场的迫切需求，使得嵌入式产品的开发周期越来越短。虽然新开发方法、新工具的应用提高了开发效率，对开发人员来说，产品成熟的压力和风险依然丝毫未减；再次它面临着硬件资源、系统性能、产品成本的平衡问题，市场的竞争使得嵌入式系统追求最佳的性价比，这更增加了系统设计的难度；最后由于摩尔定律的支配，高性能MCU价格降低并广泛使用，使得前后台系统不再风光一时，系统的可维护性、伸缩性、可移植性等问题越来越突出。要很好地解决这些问题，不得不求助操作系统或一些成熟的中间件。

嵌入式系统级的应用使得开发方面与PC平台差距越来越小，应用层开发和调试难度也逐渐减小。但同时系统级别的应用必然需要牺牲一些效率；同时，操作系统和中间件不可能覆盖所有的硬件，这就要求驱动底层人员不仅熟悉具体的硬件，还要了解操作系统或中间件的工作机制，对底层开发人员要求变高。

中国正在如火如荼的进行一场空前的系统化工程——物联网(The Internet of things)。顾名思义，物联网就是“物物相连的互联网”。有两层意思：第一，物联网的核心和基础仍然是互联网，是在互联网基础上的延伸和扩展的网络；第二，其用户端延伸和扩展到了任何物体与物体之间，进行信息交换和通信。从而实现比传统的互联网本身更广泛的价值。和传统的互联网相比，物联网有鲜明的特征：
1.    它是各种感知技术的广泛应用。物联网上部署了海量的多种类型传感器，每个传感器都是一个信息源，不同类别的传感器所捕获的信息内容和信息格式不同。传感器获得的数据具有实时性，按一定频率周期性地采集环境信息，不断更新数据；
2.    它是一种建立在互联网上的网络。物联网技术的重要基础和核心仍旧是互联网，通过各种有线和无线网络与互联网融合，将物体的信息实时准确地传递出去。在物联网上，传感器定时采集的数据信息需要通过网络传输。由于其数量极其庞大，形成了海量信息。在传输过程中，为了保障数据的正确性、可靠性和实时性，必须适应各种异构网络和协议；
3.    物联网不仅仅提供了传感器的连接，其本身也具有智能处理的能力，能够对物体实施智能控制。物联网将传感器和智能处理相结合，利用云计算、模式识别等各种智能技术，扩充其应用领域。从传感器获得的海量信息中分析、加工和处理出有意义的数据，以适应不同用户的不同需求。

物联网可以分为三层架构：感知层、网络层和应用层。不难看出，物联网实必须需要嵌入式系统的支撑；物联网需要实现各种各样的系统级应用，并对系统的实时性有一定的要求；物联网的感知层和物联网是一个比传统互联网更加庞大更加复杂的分布式系统。这些要求被转化为对RTOS的要求，推动促进其发展。

RTOS 的发展方向主要集中在三个方面。首先是RTOS的标准化研究。如今国内外的RTOS开发商数不胜数，提供了上百个RTOS，它们各具特色。这也给应用开发者带来难题，当选择不同的RTOS开发时，代码不能复用，用户的软件投资付之东流。RTOS的标准化研究越来越被重视，如IEEE协会在UNIX的基础上，制定了可移植操作系统接口标准 POSIX 1003.1b，用于规范实时系统接口；日本开发的ITRON标准等。新的应用层出不穷，软件接口仍然需要不断地完善，与时俱进。

其次是多处理器结构RTOS、分布式实时操作系统和实时网络的研究。实时应用的飞速发展，对RTOS的性能提出了更高的要求。单处理器的嵌入式系统已不能很好地满足某些复杂实时应用系统的需要，开发支持多处理器结构的RTOS已成为发展方向。至于分布式RTOS，如QNX、VxWorks、RTEMS、eCos等都提供相关的功能。但分布式实时操作系统的研究还未完全成熟，特别是在网络实时性和多处理器间任务调度算法上还需进一步地研究。

最后是集成化的RTOS开发环境的研究。开发实时应用系统，只有RTOS是不够的，还需要集编辑、编译、调试、模拟和仿真等功能为一体的集成开发环境的支持。开发环境的研究还包括网络上多主机协作开发、分布式RTOS的调试等技术。很多开源RTOS在性能方面是超越商业RTOS，但是在工具链方面与商业RTOS还有着不小的差距。如RTEMS使用GNU的工具链，调试使用GDB；而VxWorks的工具链不仅提供图形化调试界面，还提为用户提供系统运行时的一些状态信息。虽然GNU提供了GDB的图形化前端DDD以及insight，但两者差距还是不小。

coolbacon

学习和应用 RTOS 好多年了。对RTOS的发展和应用有一些粗浅的想法。尤其认识了RAW OS(一款新的RTOS)的作者后，就更多的想法。就写在这里，让大家拍砖吧。


我心里一直对这几个问题耿耿于怀。


1、什么行业在什么情况下应用RTOS?
2、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


看了之后，不禁佩服这些先哲，早已把这些问题看得这么透。我们只需要应用就好了。

coolbacon

市面上有许多RTOS操作系统，threadx, freeRtos, uC/OS-II, rtems, QNX, LynxOS, VxWorks, raw OS, ecos, NuttX……太多了。我们用了实时操作系统以为自己的应用就装进了保险箱，可是，Liu早就在1973年告诉我们，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，换上最高效的处理系统，软件控制时间的精确度只能在毫秒级别。(这里有一些争议，请看4楼的评论。并不是指RTOS中断的延时，是指中断来了，中断给信号量给任务，任务完成中断的服务的全部时间。)换句话说，软件接收到中断，作出判断，结束控制，这个时间只能精确到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发展也会有巨大的推动作用，特别是在消费类电子领域。毕竟，用得人多了，才会有人愿意发展他。

coolbacon

很多朋友和同事都问我，在实际中如何选择 RTOS。这个问题好难回答啊，非常复杂。实际中至少有三种情况：
1.有些地方根本不需要 RTOS，可能系统设计者是爱好 RTOS 的人，:-)，硬上了RTOS；
2.有些地方需要 RTOS, 但因为各种原因，没有使用 RTOS；
3.最糟糕的情况是，选择的错误的 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 了。

coolbacon

当您决定使用 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 的专家，要是学习的话无所谓，研发产品和系统的话，那就是大问题了。

coolbacon

有朋友问我，为什么有些 RTOS 支持中断嵌套， 有些 RTOS 不支持？

这个问题，我想了一下。先从中断来说吧，中断是什么。当CPU在做一件事情的时候，现在有另外一件事情插进来处理，CPU就中断了当前正在做的事情，执行完插入进来的事情后，继续中断之前的事情。中断这个东西是比较好理解的，就像咱在做家务，有个快递来敲门，听到声音后我去开门，收完快递，继续做家务。。

然而，中断本身不同于RTOS的任务调度，一个光秃秃的CPU，使用前后台系统，它也是支持中断的，不管有没有使用 RTOS 。可见，中断是硬件调度的，与软件关系不大。 既然中断是硬件调度的，那么嵌套中断呢？既然 CPU 已经支持了中断，支持嵌套中断的代价比支持中断的代价高多少呢？假设，CPU 当前正在执行A事务，B、C 两个中断依次到来，且B的优先级低，C的优先级高。

A->B->C->B->A

在A中断进入B时，CPU 需要判断A是否为中断，A 不是中断，CPU 保存A的断点信息，开始执行B；当C中断B时，B是中断，这时发生了中断嵌套。CPU 需要判断 C 的优先级别是否高于 B, 高于B才让中断，不然，随便来个中断, B都要让出CPU控制权，中断频繁点，那B就别执行了。所以，CPU必须判断嵌套中断与被嵌套中断之间的优先级。这时保存了B的断点信息，执行C；C执行完成后，恢复B的断点信息，B恢复执行，执行完成后，又恢复A的断点信息，执行A。

我们来看这个过程，发生中断时，CPU 需要：

判断是否为嵌套中断，如果是，需要判断中断优先级别；中断优先级别低于被中断的优先级别，则不允许中断；
如果允许中断，则需要保存断点信息；
中断服务完成后，恢复断点信息。

其中，2、3两条，只要支持中断是必须要做的工作，对于不支持嵌套中断的CPU来说，第一条可以略去。现在CPU很少能找到不支持中断嵌套的。如果能找到，建议可以做一个展台，把这个东东放进去，做CPU的历史展览吧。，看来这个代价是很小的。

我们再仔细看看上面这三条，第一条是需要硬件支持的。2、3两条不同的处理器，有不同的做法。我们逐一来看：

ARM7、ARM9 代表的 CPU 是这样做的:
中断分两种，普通中断和快速中断，不同之处就是多了一些分组寄存器，少浪费保护恢复寄存器的时间。中断发生硬件只保存返回地址(lr)和程序状态字(cpsr)。用户需要自己保存被破坏的寄存器的值。中断退出时，用户需要恢复这些寄存器的值，而硬件会自动恢复(lr)、(cpsr)的值。仔细看这个过程，实际上是一个软件和硬件相结合的过程。

Cortex-M3 代表的 CPU 是这样做的：
中断分两种，普通中断和快速中断；但Cortex-M3 有一个中断管理器，发生中断时，硬件会把所有必要的信息全部保存，不需要用户代码操心。中断服务结束时，硬件也会自动恢复这些寄存器，用户也无需参与。这个过程是硬件全部自动完成的，所以cortex-m3中断的代码相对简洁很多。

这两种做法，基本上代表了 cpu 的大部分通行的做法。这里稍微提一下中断的另外一个特性：
Cortex-M3 还支持一个特性，如果有两个A、B中断优先级别相同，A正在执行，B发生中断，当A执行完毕后，立即执行B，并不恢复断点执行一条被中断代码，然后再执行B。这样做最直接的好处，对中断的响应就及时、快速，然而，如果中断过于频繁，直接的结果就是被中断的代码没有执行时间。很多CPU都是返回被中断的代码后，执行一条指令，再次进入中断。这种做法保证了再频繁的中断，被中断的代码都能有时间执行，但来回保存、恢复断点信息，使得CPU浪费大量的执行时间。所以，设计者要充分关注这些细节，才能设计出实时性优良的系统。

这两种做法都需要将信息保存在栈中，然后从栈里恢复信息。这有牵扯到另外一个问题，就是 CPU 要求 ISR 有独立的硬件栈，还是共享 RTOS 任务的栈。

ISR 有独立的硬件栈 ，第一次中断时，RTOS 需要使用任务栈保存断点，发生嵌套时，isr 使用独立的硬件栈，而不使用任务的栈。
ISR 共享 RTOS 任务的栈 ，这个情况就比较“杯具”了，一股脑的全部使用被中断的任务栈。我们想想，那一个任务栈要多开多大的内存，才能保证最大中断嵌套正常工作？您知道是哪一个任务会被中断 N 次吗？所以，所有的任务栈都必须足够大，以允许最深的嵌套。

从设计的角度来说，中断嵌套要求的设计难度较大，并且这部分全部是与处理器高度相关的，处理器与处理器之间很可能借鉴意义都没有……需要用户自己 Coding……听起来是个不好的消息，好在大部分 rtos 都给出移植的例子，可能有些例子不支持中断嵌套，并不意味着 rtos 真的不支持。

好，到这里我分析的差不多了，总结一下：

1.只有不支持中断嵌套的CPU，没有不支持中断嵌套的 RTOS。
2.如果 RTOS 不支持中断嵌套，请参考以下原因：
  2-1.为了节省宝贵的 RAM；
  2-2.基于实时性的设计要求(系统只有少数几个中断，不频繁，对任务切换的实时性要求高)；
  2-3.移植的童鞋可能水平不够或时间不够。

coolbacon

最近有个朋友，叫我出出主意，想想怎么把他写得RTOS发扬光大。这事情问到我，让我思索良久。的确啊，现在的RTOS，知名的，不知名的；低调的，高调的。少说都有上百种。如何在这么多的RTOS中脱颖而出，那是需要点思路的。纵观整个RTOS的产品，有免费的和不免费的；有鲸鱼式的巨无霸，也有蜂鸟那样的小小鸟。有商业化成功的航空母舰，也有未走出只有学习者的小舢板。多年的工作让我明白，技术往往在商业成功中充当一个支撑的要素。商业的成功，需要非常多的要件。

中国是最大的发展中国家，国民经济的腾飞，带来了各方面的需要。OS 的自主化，是非常重要的基础项目。经济的腾飞催生了巨大的市场空间。然而，这个需求大部分是由中小企业催生的。他们是市场的主体。由于近年来，ARM等CPU的崛起，使得嵌入式领域的处理器越来越强；传统单片机的前后台系统无法胜任几何级数般增长的代码。必然需要更高级的东西，来解决这些问题。然而RTOS的应用领域有限，并不太适合高端的消费类电子；主要还是以工业控制为主。工业控制强调稳定、可靠。这也是各大RTOS竭力吹嘘的地方。

对于中小企业来讲，他们没有足够的技术力量去评估一款RTOS是否稳定、可靠，有心无力。有些根本是无心也无力。在选择RTOS时，对这个技术决策来讲，最重要的莫过于开发的简易程度，是否能解决他们的问题。稍微强一点的能考虑以后产品的升级，以及产品系列的兼容问题。然而，一些企业生产的产品自身的问题不断，担当救火队就已经使研发部门的资源耗费殆尽，何谈考虑的这么长远？当然还是有些企业能考虑到这些问题。甚至考虑到版权、维护等等各方面的市场的，技术上的，以及法律上的各种风险，最终定下来一款RTOS。这样的企业又有几家呢？有朋友经常在坛子里和群里发牢骚：公司没出息，又偷着用xxx系统。类似的声音不绝于耳。中国目前处在社会的转型期，各种世界观、价值观激烈的角逐冲突。其中这个盗版和对版权的尊重这方面，尤为突出。这也使得国内市场靠版权费用生活的RTOS日子过得并没有那么好的原因之一。

一款RTOS要发展起来，首先要活下来。活下来的第一要件就是满足市场的需要；大家有用它的动力，才有可能发展的空间。中小企业既然关心的开发的简易程度，能否解决他们的问题。那为什么不在这个关键点上下功夫？现在的不论大小RTOS，都秉承着通用，普适的道路走着。看看VxWorks，看看RTEMS，它们都是发展了超过15年以上的RTOS。有着稳定的用户群体，出众的产品性能。就算开发人员是穿越回来的，写了个非常先进的RTOS，被市场接受也不是一年半载就能完成的。这些老牌RTOS，在各行各业都有使用，经过了多年的催生发展，实在是难以抗衡。不过，缺点也是有的，主要是庞大，移植复杂。费用也是高得离谱。仅凭这三点，新的OS就有生存的空间。

从某一个行业入手，将适合这个行业的芯片，从驱动到简单的业务模型，都做完善了。这样使得这些中小企业看到曙光，不需要为他们不在行的部分付出过多的精力。底层的移植，驱动的开发测试等等。使他们心甘情愿的使用RTOS。使用农村包围城市的思想，一点点从某个行业发展起来。继而发展成通用型操作系统。