请教:惊现永远不关中断和在ISR中上下文切换的RTOS!
偶然在IAR的网站上看到对它们PowerPac操作系统的说明,其中有一个:Zero Interrupt latency
换句话说也就是永不关中断!
我们都知道,OS在操作全局数据时,通常的作法是把它们包进“关中断型临界区”
如果在操作全局数据时,不想关闭中断,我能想到的办法就是,禁止调度,或者在入口处设置互斥锁,以避免操作全局数据的程序段被重入。
然而如果ISR不巧发出了对操作相同全局数据函数的调用,该怎么办?给ISR返回一个错误的值说访问冲突?总不能悍然让ISR的调用不管三七二十一就动这个全局数据吧,数据共享紊乱危象也不是闹着玩的呀!
百思不解~~
另外,PowerPac还声称可以在ISR中进行任务切换,巨另类!按我们的理解,ISR的实时要求肯定比任务的要高,难道让ISR等任务么?如果是同步的目的,完全可以让ISR对应一个任务来负责此事。因此这样做的意义何在呢?而且,ISR属于哪个任务的上下文?还是为ISR单独开出上下文的保存空间? 像CM3这样的处理器,我还能想到的办法是:
利用BASEPRI优先级阈值寄存器,只关闭一部分优先级,开放一部分高优先级。但是撰写高优先级ISR的程序员必须自律:不调用可能导致共享访问冲突的API! 不太相信。
楼主试下编译一个最简单例子,调试看汇编代码有没有关中断。 像CM3这样的处理器,我还能想到的办法是:
利用BASEPRI优先级阈值寄存器,只关闭一部分优先级,开放一部分高优先级。但是撰写高优先级ISR的程序员必须自律:不调用可能导致共享访问冲突的API!
高明啊!下了一个PowerPac 看了看,文档第100页,果然写了:
How many different levels of interrupts there are depend on the CPU and the interrupt controller. Details are explained
in the CPU/MCU/SOC manuals and the CPU & Compiler Specifics manual of IAR PowerPac RTOS. IAR PowerPac
RTOS distinguishes two different levels of interrupts: High / Low priority interrupts. The IAR PowerPac RTOS port
specific documentation explains where "the line is drawn", which interrupts are considered high and which interrupts
are considered low priority. In general, the differences are:
Low-priority interrupts
● May call IAR PowerPac RTOS API functions
● Latencies caused by IAR PowerPac RTOS
High-priority interrupts
● May not call IAR PowerPac RTOS API functions
● No Latencies caused by IAR PowerPac RTOS (Zero latency) 嘿嘿,BLUELUCY和CLIFF2大高手切磋,少不了我这个看热闹的,^_^ Cliff和大家的钻研精神值得我学习啊!原来IAR也挺会炒作的嘛!
我觉得咱们论坛讨论RTOS的人气不够旺,比如这个版都没有版主
现在的RTOS都太强调“可移植性”。但可移植性强了必然会导致针对性的优化减少。
像CM3这样有性格的CPU,是不是应该有对它“用情专一”的rtos,才能挖掘它的潜力呢? RTOS占用RAM太大。
AVR上很难跑上。
暂时对RTOS兴趣不大。
对基于事件的协作式调度内核更有兴趣,可以在小RAM单片机机上跑的很好。 RTOS在中小公司的普及程度很低的,大公司都是花钱买的,有什么问题直接就支持了,通常在外面讨论的少也就正常了
说到这里,我不得不提到uCLinux,我(此奥),加入了Mail List,那些家伙从来就无视我的问题,都是一行一行汇编代码看过来的,那个苦啊。猜想可能中国人在这个圈子里面的口碑太那个了,哎。敬告想要搞Linux的一句话,如果做着玩可以,作产品,不建议使用,一个没有技术支持的东西,开发过程就是一个字:苦!而且,失败的可能性也比其他的操作系统大得多 呵呵,根据应用的需要,自已写一个简单的OS,中断程序中避开临界区问题,就可以做到Zero Interrupt latency了.
其实中断滞后的根本原因正是因为操作系统太复杂,只要解决掉"复杂"这个问题,就没有问题了.
我做的几个小玩意全都是"Zero Interrupt latency"的,没什么神奇的.OS用的是自已写的超轻量. 我构思过一个简单的任务切换方法,不知道能不能用:在中断中保护R0-31,SP等现场数据,作为任务的依据,在改SP为另一个任务的私有堆伐空间,然后恢复另一个的保护数据在中断返回,程序会回到另一个任务了,因为所有保护的数据都在堆伐中,所以不会出现其他的情况了,不用关中断,甚至可以在切换任务时进入更高的中断,他们会保护自己用到的地方。
一个想法,一直没有用,理想的条件下只用C就能实现,甚至不用嵌入asm TO 【7楼】 thomasdu:关键还是中国人“不愿意花钱”的心思在作怪啊。商用 RTOS 要钱,Linux么……如果你要服务,也行啊,也有啊,如 Montavista。可是,有人愿意吗?
TO 【8楼】 rainyss:这不是中断程序中避开临界区,而是进入临界区后,中断还能照常响应。
TO 【9楼】 mcu5i51 梦幻英雄:任务之间还要通信呢,而通信,就需要共享资源,也就需要8楼说的临界区,那也就有关中断了。 【5楼】 bluelucky
现在的RTOS都太强调“可移植性”。但可移植性强了必然会导致针对性的优化减少。
像CM3这样有性格的CPU,是不是应该有对它“用情专一”的rtos,才能挖掘它的潜力呢?
====================================
标准RTOS操作模式对CM3的性能降低,足以让RTOS的实用率显著下降,但实际使用中,定制的“普通”RTOS就够了
另一方面就是,CM3目前在绝大多数项目中,只是用作替代ARM7使用的,此时并不需要太过强悍的RTOS,因为既然常规速率在60MHz上下的ARM7都能搞定的工作,没理由CM3搞不定 大家的讨论热起来了,开心ing ^_^
揭开炒作的迷雾,只要存在并发,在并发中有资源共享,又不想被返回一个“共享冲突”的错误值,唯一的办法就是使用关中断。不过,对于非ISR,被返回一个“共享冲突”,可能也是可以接受的吧!因此我觉得,临界区有三种:
1. 关中断型临界区,权称为IDS好了(Interrupt Disabled Section)
2. 不可抢占型临界区,权称为NPS好了(Non Preemptive Section)。一旦有任务进入该区,其它任务就不可抢占。即使任务自己放 弃CPU,也要等离开该区才能上下文切换。
3. 独唱执行区,权称SES好了(Solo Execute Section)。其实效果跟windows中的CRITICAL SECTION一致:一旦某任务进入SES,则其它任务在它出来之前不得进入同一个SES。这有点像被一个互斥体保护的那样。
使用2和3,以及CM3的互斥访问指令,有望做到在ISR可以接受“共享冲突”错误的条件下,永远不关中断。
关中断型临界区是在并发执行的环境下,由共享冲突的本质决定的,跟rtos没关系。即使不上rtos,也存在这个问题。因为ISR与主程序的关系也是“并发多任务”的朴素表现形式。所以,只要ISR与主程序要操作相同的全局变量,就依然必须解决共享冲突的问题。如果不能接受“共享冲突”错误,就不可避免要关中断。操作系统的“复杂”只是恶化了中断延迟,但不是始作俑者。好的rtos功能再复杂,也不应该拖中断呼应的后腿。
To thommasdu 同感!我觉得,在国内要把linux很爽地用在商业项目上,必须是一个有钱有势的大组织,而且最好还有背景。比如浙大的一位教授,他手下有160多号人,把浙大最气派的一幢楼的整个一层都占掉了。那里面不乏常驻的精英人才,能力强,项目经验和调试经验丰富,带新人闪电般地快。在这方面安徽华恒也很有相似点。我觉得有人带与没人带是天壤之别,尤其是在linux这种欺生的系统上,而国内的linux热又过于口号化。
Cliff说得很对,别对linux的“免费”断章取义。开发人员的高薪,技术服务的高费用,大量除虫所消耗的时间,不管是本公司的还是外公司的,都不是一个小数字。
To watercat: 大家对CM3的要求也会不断地高起来的。作为应用程序的开发者,肯定希望系统的裕量不要紧巴巴的;站在OS开发者的立场上,却要向高标准看齐,并且要考虑到未来的需求,因此要穷尽所能地减小资源占用和提高效率。对使用者来说,如果有同样容易学习,并且更强的rtos,包括实时性能,同步设施,调试与内核跟踪,友好IDE的支持,优秀的教材,肯定会慢慢红起来的,尤其是对于新人。 Cliff说得很对,别对linux的“免费”断章取义。开发人员的高薪,技术服务的高费用,大量除虫所消耗的时间,不管是本公司的还是外公司的,都不是一个小数字。
------------------------------------
就是,只有精明的老板才会算这个帐,一般的家伙,哈哈,看到"免费"2个字,立马就两眼放光,可是,光的长度只有一寸:D 并发问题,在国外一些操作系统的论述中是称作“同步”(synchronization)问题,是指并发情况下,如何使不同任务对共享资源的访问前后保持一致性、唯一性。
具体做法很多,可以看看ibm的一篇技术文章:
http://www.ibm.com/developerworks/cn/linux/l-linux-synchronization.html
【12楼】 bluelucky 所说的SES类型,其实就是指上锁(包括自旋锁、读/写锁、信号量等方法)。这是面对真正的并发情况,比如多处理器下的同步,而非单处理器下多任务调度,因为多处理器是真的同时在并行运行程序的,多个cpu对内存的访问是由总线仲裁决定的。这时光靠关中断是没用的(因为那只能是当前执行关中断指令的cpu停止中断响应,而其它cpu仍可访问共享资源),如果关全局性中断,那么整个系统的性能就浪费了(因为其它cpu可能正好不会访问同一个资源,但需要其它资源,仍应当允许它们访问其它资源),锁机制就是对这个问题产生的(依赖于硬件提供的原子访问指令实现)。
多处理器下,用哪种同步机制是开发人员的责任,能使用小范围的保护机制,就应当避免使用全局性的保护。
但这里要注意的是,无论哪种同步机制,目的都是保护共享资源的同步,而不是保护哪段执行代码。
所以windows中的CRITICAL SECTION也只是为了限制对共享资源访问的代码执行。
关于避开使用关中断,一些情况下也可以通过循环缓冲队列来解决,但就是带来性能上的一定损失。
至于linux的费用问题,如果要指望系统和服务都是免费的馅饼,那是不现实的(那样程序员也甭活了),开源软件的盈利模式之一就是服务收费,社区也只是个交流的地方而已,要看别人兴趣的,不是售后服务处。 【12楼】 bluelucky
To thommasdu 同感!我觉得,在国内要把linux很爽地用在商业项目上,必须是一个有钱有势的大组织,而且最好还有背景。比如浙大的一位教授,他手下有160多号人,把浙大最气派的一幢楼的整个一层都占掉了。那里面不乏常驻的精英人才,能力强,项目经验和调试经验丰富,带新人闪电般地快。在这方面安徽华恒也很有相似点。我觉得有人带与没人带是天壤之别,尤其是在linux这种欺生的系统上,而国内的linux热又过于口号化。
Cliff说得很对,别对linux的“免费”断章取义。开发人员的高薪,技术服务的高费用,大量除虫所消耗的时间,不管是本公司的还是外公司的,都不是一个小数字。
==========================================
会说出这些话,只能说明,你们并不是真正喜欢技术、并愿意把时间消耗在技术研究上的人
【12楼】 bluelucky
To watercat: 大家对CM3的要求也会不断地高起来的。作为应用程序的开发者,肯定希望系统的裕量不要紧巴巴的;站在OS开发者的立场上,却要向高标准看齐,并且要考虑到未来的需求,因此要穷尽所能地减小资源占用和提高效率。对使用者来说,如果有同样容易学习,并且更强的rtos,包括实时性能,同步设施,调试与内核跟踪,友好IDE的支持,优秀的教材,肯定会慢慢红起来的,尤其是对于新人。
==========================================
我不知道你是否“新人”,但我想说,如果你是新人,请不要好高骛远;如果你不是新人,就请学会自己动手,不要总指望别人做好了饭喂到自己嘴里 感谢yyccaa有关同步问题的精彩讲解!这还让我知道了在多核系统之间还有“全局中断”这一概念:是不是有点像黑夜中一个大屋子里的灯开关,任何一个人都可以关灯,任何其它人都可以开灯呢?而且在多核系统中对内存单元访问的原子性,是由存储器系统的硬件在与各核保持保证的。
仔细地读了《Linux同步方法剖析》,重点了解了原子操作,以及建立在其之上的自旋锁和内核互斥锁。看来即使是在多核系统下,如果想不关中断,也必须让ISR可以接受“访问冲突”错误。而且加锁与解锁的操作必须是互斥。在ISR中使用忙等待的自旋锁可能得谨慎些,要是被别的核一口咬住不放可就惨了。
我后来又想了想,发现在共享存储器的多核系统上,问题还真不像乍一想的那么简单。比如,上电复位后,操作系统的初始化以及全局变量的初始化应该在哪个核上执行,还是公平竞争?再如,很多rtos的任务状态模型都失效了,因为它们大多假设只有一个任务处于执行态,但现在不止一个任务可以同时执行。还有,片上cache也不能用了,因为某个核把数据弄脏后,其它核却看不到它的家事呀。看来,要想把单核系统的rtos改造成多核的,要改动的地方一定很多,而且还要有不少洗心革面的大手术呢!多核看起来挺有吸引力,但是得小心地喝这口“温柔河水”,否则真会跌进灭顶的狂流呢。
linux的atomic_XX()函数是不是与windows的InterlockedXX()会不会是同样功能的呢?
在讲原子操作时,还提到“而另一些方法依靠 c 语言并且使用 local_irq_save 和 local_irq_restore 禁用中断。”这是不是只有在单CPU下才可行,如果是多核,就成了掩耳盗铃了?因为某个核关不关中断,才不关其它核的事呢。 To watercat: 前辈请别误会。真正喜欢技术、并愿意把时间消耗在技术研究上的人,也一定是越喜欢技术,就越希望更快更好地学会,并且创造出有价值的东西来证明自己的所爱是崇高的。如果喜欢的程度极高,在即使有后顾之忧的条件下,依旧奋不顾身地研究它,哪怕对自己在商业社会的生存和家庭幸福产生不利影响也在所不惜,这样的大侠确实可敬,终于做出这个决定绝对需要《勇气》和痴情。而且值得被这样迷恋的技术也不只linux一个,总不能所有人都研究linux吧。相信大家肯定有自己热心的领域,并且有为之痴狂的一个!另一方面,公司为了活下去,就是要追逐效益,因此即使“忘了本”也无可厚非。
关于rtos,国内的现状可能令人失望,而我会多动手的,有志的年轻人也一定很多。在悲愤的主旋律之下,一定还有转变的机会。 RTOS(不仅仅是RTOS,整个嵌入式行业)现状反映了中国人观念落后,技术落后,制度落后。 用过PowerPac的评估版,只能建两个任务。感觉要比uC/OS小巧些。 上官大哥是不是指像uC/OS-II这样的系统仍然受到太多追捧?非常同感,我也斗胆地说一句直肠子的话:uC/OS-II在32位机上,尤其是像CM3这样的32位机上,早已不是优秀的操作系统了,它是因为历史原因才一直活跃在中国的教育界。尽管使用方便且可以满足很多应用,但对于国内研究rtos的,却要看得远一些。非要举个例子的话,比如,它只允许一个优先级有一个任务,就从本质上拒绝了防优先级反转和死锁避免的能力。
我觉得针对像CM3这样有新意的32位单片机内核,应该有一个把移植性放第2位,针对性和优化度都高的rtos,除了实时性强,同步机制丰富,面对不同行业做出不同定制版之外,还要在IDE友好度、内核调试与跟踪能力、以及中间件子系统可扩展性上都要出彩。我真想把其它工作都放下去做它。要是我的皮肤中也有叶绿体就好了! 呵呵,关于临界区,自旋锁之些东西,其实去看看LINUX的内核就很清楚了.至于多CPU下,锁机制不是靠中断来完成的.所以所谓的"中断零滞后"跟关中断其实是没有本质关联的,靠的是一些机制的保证,而你想达到零滞后,就得遵守那些机制,不要把视线老停留在"依靠关中断解决临界区问题"上.
我在LINUX内核里搞过两年,所以很容易做到不中断就解决临界区的问题.但我仍然喜欢用关中断的方法,因为开销小.对单片机来说,"simple is more"! TO【9楼】 mcu5i51 梦幻英雄
积分:162
派别:
等级:------
来自:河北衡水
我构思过一个简单的任务切换方法,不知道能不能用:在中断中保护R0-31,SP等现场数据,作为任务的依据,在改SP为另一个任务的私有堆伐空间,然后恢复另一个的保护数据在中断返回,程序会回到另一个任务了,因为所有保护的数据都在堆伐中,所以不会出现其他的情况了,不用关中断,甚至可以在切换任务时进入更高的中断,他们会保护自己用到的地方。
一个想法,一直没有用,理想的条件下只用C就能实现,甚至不用嵌入asm
你这办法老早就很多人在用了,而且现在正在用.这并不能解决临界区的问题.只要你用了中断,就会有临界区问题,举个例子:
假定i是全局资源,当前值为1
进程中的语句:
if(i)//假定执行这个判断时中断发生,那就意味着执行完这条语句后将跳入中断程序.而此刻这条语句已认为i!=0,所以流程已定为i--的方向
i--;//中断中返回后回到,此刻i本该是原来的值1,却因中断里的访问而变成了0,进程并不知道这一点,继续执行,于是在i--之后变成了-1,一个很可怕的值
else
i = 5;
中断里执行有同样的语句:
...
if(i)//执行到这时,i仍为1
i--;
else
i = 5;
//现在i变成0了
...
当i在打断前为1时,j的值会错误的变为-1,而不是预期的5.这个示例可能看不出问题的严重性,但试想一下这个i一个环形FIFO的下标指示...
在实际应用中这样的问题只是很常见的问题,但已经可以造成严重后果. 按照yyccaa推荐的文章,加锁与解锁应该是靠原子操作来完成的吧,但我觉得在CM3中还能用互斥读写指令。零中断滞后实现了,我估计肯定会使ISR不可避免地要遭遇试图访问的资源被锁的情况。比如在ISR中欲唤醒一个任务,而任务控制块队列正被保护中,结果ISR又不能阻塞,只能被拒
rainyss在22楼演示的紊乱危象实例,非常典型!只要存在互斥共享就要避免这个永恒的问题 所以临界区的问题,只能在机制上下功夫去避免,而不是挖空心思去硬闯.实在躲不掉的时候,尽可能快地临时关中断就行了. 不错。MARK,学习了 个人认为,那点延迟真得不算什么,大多数情况下只是开发者追求完美的一种表现而以……
真正的高可靠高实时要求场合,不会有那么多通用的方法可用的
另外,单片机用时间协作的方法处理多并发就好了,搞那么多RTOS感觉没必要,毕竟只是单片机,呵呵 精彩的讨论,做个记号。 感谢大家的热心啊!
稍许小结一下,一方面充分挖掘新型32位机在中断系统上的硬件支持,另一方面在ISR模型中分类而不一刀切,是解决矛盾的主要途径
To 29楼 Totry
有一定的道理。主要是在需要响应高频事件的系统中,对中断延迟和处理效率还很斤斤计较(多见于电力电子和高精机电控制中)
高可靠高实时应用通常比较单纯。所以好的RTOS设计就应该能胜任功能复杂的高可靠高实时应用
单片机业界正在蜕变,现在像基于CM3,AVR32,M4K的单片机动不动就有16KB以上的内存,可以在它们身上渐渐把使用完善的RTOS提上议事日程了 Real-time response
Unlike other real-time operating systems that disable interrupts in every kernel service call, velOSity's state-ofthe- art architecture guarantees the absolute minimum interrupt latency by never disabling interrupts in any service call.
http://www.ghs.com/products/velosity.html
http://www.ghs.com/products/safety_critical/integrity-do-178b.html
目前调研到的其实只有一个军工用的RTOS声称不关中断。至于是怎么实现的,还在思考中。
另外,http://www.smxrtos.com/articles/lsr_art/lsr_art.htm 和 http://www.rtcmagazine.com/home/article.php?id=100152&pg=2 提出了一些方法快速响应中断。
希望对其实现方法大家一起讨论。 研究过一段时间的Keil的RTOS和uCOS的不同
有没有这样的RTOS: 既支持时间片轮转又支持任务抢占式 RT-Thread
相同优先级就是按时间片轮转调度的 to 33楼:这样的RTOS到处都是,比较有名气的,可能也就uC/OS-II不是这样的了。 TO 35楼:晕哦,我这个菜鸟只能接触到能接触的RTOS了
到处是也好夸张吧?没有几个RTOS国内常用的吧 VxWorks? VxWorks用的也是挺多的
国内uC/OS-II之所以这么流行,最主要的原因还是宣传到位
虽然uC/OS-II对付很多没有太苛刻性能要求的产品已经够了,而且学习难度适中,但我们还是要把眼光看远一点 大家看看coOS怎么样? DJYOS 据说不用关中断。 coos 还有一些 bug 没有修正,谨慎使用! keil 自家的 RL-RTX 在 cm3 上就是不关中断的。 俺家的RTOS也是从不关中断的
都关中断了,还有何实时性可言 太深奥拉。,, laoshuhunya 发表于 2012-9-6 17:25
俺家的RTOS也是从不关中断的
都关中断了,还有何实时性可言
你家的rtos是哪个啊 myxiaonia 发表于 2014-9-15 16:07
你家的rtos是哪个啊
额,这一镐挖得好深。。。
引用下金刚经的话:名为bgRTOS,即非bgRTOS,是名bgRTOS。
哈哈,开个玩笑啦。 laoshuhunya 发表于 2014-9-15 16:43
额,这一镐挖得好深。。。
引用下金刚经的话:名为bgRTOS,即非bgRTOS,是名bgRTOS。
哈哈,开个玩笑啦。 ...
你女儿是个小美女啊,祝福一个 myxiaonia 发表于 2014-9-15 22:19
你女儿是个小美女啊,祝福一个
女儿今年刚上一年级,有点小臭美。
幼儿园大班时班上有个小帅哥(班长),平时见到我女儿眼神总是呆呆的,还到处宣扬说以后要娶我女儿。一次老师在课上问孩子们长大了理想是什么,这位帅哥呼啦就站起来说要娶我女儿,老师和同学都笑翻了。
老师问我女儿:“xxx同学,你长大了愿意嫁给他吗?”
我女儿瞪了一眼那位同学,不紧不慢的说:“谁知道他长大了会怎什么想呢!”
哈哈,这都是老师事后跟我们说的。
晕。。。歪了楼,补充下技术话题,免得有灌水之嫌:
这个bgRTOS用了好多年了,起初是由几个人合写的,主要是三位天才MM(可惜现在都已不做技术了)。因为一直有用在产品上,出于商业原因没有公开。早期是用于MCS51单片机,后来移植到ARM CM/CA上。这个RTOS的最大特点是:
(1)全透明任务切换,整个内核没有任何开关中断的操作,确保了紧急任务的高度实时性。
(2)可同时激活的任务数几乎没有限制(在8位机上为2^8=256,在32位机上为2^32=4294967296)
(3)抢先型多任务,允许相同的任务优先级。
(4)可分配的任务优先级几乎没有限制(在8位机上为2^8=256,在32位机上为2^32=4294967296)
(5)具有任务重要度分级,完美支持前后台任务规划。(说明:任务优先级解决的是任务执行的先后问题,任务重要度解决的是任务执行的快慢问题)
(6)完全自主的任务优先级结构,支持无反转动态优先级切换。
(7)一个可选的系统特权任务,使任务管理和资源管理更灵活。
......
laoshuhunya 发表于 2014-9-16 02:24
女儿今年刚上一年级,有点小臭美。
幼儿园大班时班上有个小帅哥(班长),平时见到我女儿眼神总是呆呆的 ...
理解理解,有次带我儿子去早教中心体验,我儿子花痴一样的老在一小美女旁边姐姐姐姐叫着围着她转,旁边的家长说她是这里班上的女神啊哈哈哈。。。
话说你的这个天才mm写出的rtos,性能如此出色,不知道能否透露透露思路。。。特色很鲜明啊我很好奇
我就研究过keil的rtx,感觉也是非常有特色,各种评测在cm3上也是十分耀眼。。。。
它采用了svc陷入中断的方法调用系统api,中断中使用系统api则放入osfifo队列挂起,在pensv中运行的方式,从而完全避免了关中断的做法
不知道还有什么其他思路 myxiaonia 发表于 2014-9-16 10:50
理解理解,有次带我儿子去早教中心体验,我儿子花痴一样的老在一小美女旁边姐姐姐姐叫着围着她转,旁边的 ...
思想决定架构,架构决定性能
首先,我们设计这个系统的基本思想是:
1、强实时
实时分为两种:强实时和弱实时。强实时靠硬件和中断来保证,弱实时则由RTOS任务优先级来保证。内核不应该去开关中断。
2、高可靠
任务隔离。一个任务崩溃不能波及其它任务。这对军工、医疗和特殊控制领域尤其重要。
3、可扩展
能够适应多核和分布式系统。
4、广泛的适用性
任务的优先级、可同时激活的任务数仅受机器硬件条件限制。
5、非侵入式API
对编程没有额外的限制。很多RTOS应用中需要遵守N多规则,不允许这不允许那的,太多的陷井。
当设计的基本思想确定后,系统的基础框架就确定了,实现调度器时就会发现不关中断切换任务是非常自然的事情,根本不用特殊的技巧去实现。
laoshuhunya 发表于 2014-9-16 13:39
思想决定架构,架构决定性能
首先,我们设计这个系统的基本思想是:
如果这些要求给我让做rtos,一点思路都没有,起点太高了 rtos用的还是少,一般不用的, 好高深啊~~受益匪浅
页:
[1]