注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

dp: 生活的脚步,进步的点滴...

Cam、DSP、FPGA、PM、Life、More ...

 
 
 

日志

 
 

RTOS与实时性  

2013-07-26 08:37:25|  分类: 专业 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
我心里一直对这几个问题耿耿于怀:
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,换上最高效的处理系统,软件控制时间的精确度只能在毫秒级别。(这里有一些争议,并不是指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发展也会有巨大的推动作用,特别是在消费类电子领域。毕竟,用得人多了,才会有人愿意发展他。
  评论这张
 
阅读(564)| 评论(0)
推荐

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2016