RTOS的ABC讨论

学习和应用 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

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

市面上有许多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发展也会有巨大的推动作用，特别是在消费类电子领域。毕竟，用得人多了，才会有人愿意发展他。个人浅见，欢迎拍砖。