嵌入式os的选择

时间:2023-01-25 21:05:47
原文地址:http://ar.newsmth.net/thread-cd44cc4172b593.html
发信人: easyfish (晶鱼), 信区: Embedded 
标  题: [合集] 关于操作系统的选择,闹心,大牛给点指点吧 
发信站: 水木社区 (Sun Nov  4 12:41:06 2012), 站内 

☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sat Oct 27 08:15:14 2012)  提到: 

做个控制的项目 

平台必须是ARM9(领导定的),因为对实时性有所要求,对系统的选择有点难产了 

VXWORKS  初始授权30万左右,我刚来这个公司,估计很难批下来;如果用盗版,且不说源码&资料不好搞,最重要是未来可能会有官司,现在WINDRIVER查的很严 

Linux  很想用这个,想借这个项目好好学学LINUX,摆脱裸跑&UCOSII,但资料上说很难满足实时要求(其实也不是特别高,从判断电流过大到继电器完成动作20ms左右,最多不超过30ms),加RTLINUX补丁呢,又不知道ARM9行不行,另外资料也比较少 


望大牛给写指点,尤其是ARM9可以跑RTlinux么 

谢谢了 


☆─────────────────────────────────────☆ 
  
 dormouseBHU (dormouseBHU) 于  (Sat Oct 27 09:39:35 2012)  提到: 

uCOS-II 就挺好,不想吃官司还有 FreeRTOS、RT-Thread。 
比起来,RT-Thread 功能最强,个人觉得已经不比商业的实时操作系统差了,而且是国人搞的,可以支持一下。 
另外 djyos 也不错。 


☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sat Oct 27 10:25:21 2012)  提到: 

eCos 

rtems 


【 在 leopardlee (MHY) 的大作中提到: 】 
: 标  题: 关于操作系统的选择,闹心,大牛给点指点吧 
: 发信站: 水木社区 (Sat Oct 27 08:15:14 2012), 站内 
:  
: 做个控制的项目 
:  
: 平台必须是ARM9(领导定的),因为对实时性有所要求,对系统的选择有点难产了 
:  
: VXWORKS  初始授权30万左右,我刚来这个公司,估计很难批下来;如果用盗版,且不说源码&资料不好搞,最重要是未来可能会有官司,现在WINDRIVER查的很严 
:  
: Linux  很想用这个,想借这个项目好好学学LINUX,摆脱裸跑&UCOSII,但资料上说很难满足实时要求(其实也不是特别高,从判断电流过大到继电器完成动作20ms左右,最多不超过30ms),加RTLINUX补丁呢,又不知道ARM9行不行,另外资料也比较少 
:  
:  
: 望大牛给写指点,尤其是ARM9可以跑RTlinux么 
:  
: 谢谢了 
: -- 
:  
※ 来源:·水木社区 http://newsmth.net·[FROM: 119.40.52.*] 




☆─────────────────────────────────────☆ 
  
 Aquamarine (你大爷永远都是你大爷) 于  (Sat Oct 27 10:58:27 2012)  提到: 

亲,不要误导别人啊。 
djy是深圳南瑞的老罗搞的,我认识老罗,所以有些事情不说了。 
RTT是上海Marvell的老熊写的,支持ARM CM3最好,我认识老熊,所以有些事情不说 
了。 
作为一个不懂技术的人,也没上过什么学,个人觉得,djy和RTT都是单片机系统,上手可 
能比较容易,但是没有一个完整统一稳定的framework。做嵌入式产品最多的工作是什 
么?是维护,选型不合适,初期开发爽了一下,后期维护,你伤的起么? 

RTEMS被NASA扔上了太空。eCos在一些机器人中有使用,现在这个项目好像基本挂了。 
RTLinux也经得起华为的检验了。 
这仨都是无版税,并且经得起历史检验的,做产品,最重要求稳,开发的时候儿戏,市场 
也可以儿戏么? 

【 在 dormouseBHU (dormouseBHU) 的大作中提到: 】 
: uCOS-II 就挺好,不想吃官司还有 FreeRTOS、RT-Thread。 
: 比起来,RT-Thread 功能最强,个人觉得已经不比商业的实时操作系统差了,而且是国 
人搞的,可以支持一下。 
: 另外 djyos 也不错。 


☆─────────────────────────────────────☆ 
  
 Ylong (沧海云龙) 于  (Sat Oct 27 11:08:05 2012)  提到: 

所谓的Linux不支持实时,是指的用户态还是核心态啊? 
如果指的核心态的话,那么多高速硬件设备是怎么跑的呢? 
不过20ms也算不上实时要求 
【 在 leopardlee (MHY) 的大作中提到: 】 
: 做个控制的项目 
: 平台必须是ARM9(领导定的),因为对实时性有所要求,对系统的选择有点难产了 
: VXWORKS  初始授权30万左右,我刚来这个公司,估计很难批下来;如果用盗版,且不说源码&资料不好搞,最重要是未来可能会有官司,现在WINDRIVER查的很严 
: ................... 



☆─────────────────────────────────────☆ 
  
 kidstar (linux) 于  (Sat Oct 27 11:22:46 2012)  提到: 

linux + 实时补丁吧 
很多电力保护装置在用 
【 在 leopardlee (MHY) 的大作中提到: 】 
: 做个控制的项目 
: 平台必须是ARM9(领导定的),因为对实时性有所要求,对系统的选择有点难产了 
: VXWORKS  初始授权30万左右,我刚来这个公司,估计很难批下来;如果用盗版,且不说源码&资料不好搞,最重要是未来可能会有官司,现在WINDRIVER查的很严 
: ................... 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sat Oct 27 11:25:30 2012)  提到: 

先re一下 

再现身说法一下,rtems 用在列车控制器上 

eCos用在小煤化工控制器上,运行良好…… 


【 在 Aquamarine (你大爷永远都是你大爷) 的大作中提到: 】 
: 标  题: Re: 关于操作系统的选择,闹心,大牛给点指点吧 
: 发信站: 水木社区 (Sat Oct 27 10:58:27 2012), 站内 
:  
: 亲,不要误导别人啊。 
: djy是深圳南瑞的老罗搞的,我认识老罗,所以有些事情不说了。 
: RTT是上海Marvell的老熊写的,支持ARM CM3最好,我认识老熊,所以有些事情不说 
: 了。 
: 作为一个不懂技术的人,也没上过什么学,个人觉得,djy和RTT都是单片机系统,上手可 
: 能比较容易,但是没有一个完整统一稳定的framework。做嵌入式产品最多的工作是什 
: 么?是维护,选型不合适,初期开发爽了一下,后期维护,你伤的起么? 
:  
: RTEMS被NASA扔上了太空。eCos在一些机器人中有使用,现在这个项目好像基本挂了。 
: RTLinux也经得起华为的检验了。 
: 这仨都是无版税,并且经得起历史检验的,做产品,最重要求稳,开发的时候儿戏,市场 
: 也可以儿戏么? 
:  
: 【 在 dormouseBHU (dormouseBHU) 的大作中提到: 】 
: : uCOS-II 就挺好,不想吃官司还有 FreeRTOS、RT-Thread。 
: : 比起来,RT-Thread 功能最强,个人觉得已经不比商业的实时操作系统差了,而且是国 
: 人搞的,可以支持一下。 
: : 另外 djyos 也不错。 
: -- 
:  
※ 来源:·水木社区 http://newsmth.net·[FROM: 111.161.71.*] 




☆─────────────────────────────────────☆ 
  
 leelinping (michael) 于  (Sat Oct 27 13:25:28 2012)  提到: 

qnx 


☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sat Oct 27 15:23:57 2012)  提到: 

好,谢谢 
我认真对比下 

【 在 dormouseBHU (dormouseBHU) 的大作中提到: 】 
: uCOS-II 就挺好,不想吃官司还有 FreeRTOS、RT-Thread。 
: 比起来,RT-Thread 功能最强,个人觉得已经不比商业的实时操作系统差了,而且是国人搞的,可以支持一下。 
: 另外 djyos 也不错。 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sat Oct 27 15:24:57 2012)  提到: 

我在心底还是倾向LINUX,毕竟用途更广泛,和C也更亲近 
【 在 Aquamarine (你大爷永远都是你大爷) 的大作中提到: 】 
: 亲,不要误导别人啊。 
: djy是深圳南瑞的老罗搞的,我认识老罗,所以有些事情不说了。 
: RTT是上海Marvell的老熊写的,支持ARM CM3最好,我认识老熊,所以有些事情不说 
: ................... 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sat Oct 27 15:25:51 2012)  提到: 

貌似是多任务轮询分片,不能抢占内核,但2.6做了些软实时,但还是不满足工控 

【 在 Ylong (沧海云龙) 的大作中提到: 】 
: 所谓的Linux不支持实时,是指的用户态还是核心态啊? 
: 如果指的核心态的话,那么多高速硬件设备是怎么跑的呢? 
: 不过20ms也算不上实时要求 



☆─────────────────────────────────────☆ 
  
 cordoba (最佳中卫※静以修身|俭以养德) 于  (Sat Oct 27 15:26:48 2012)  提到: 

实际大部分情况的实时要求都没那么高。 
还是对需求做好评价之后再选择。 


【 在 leopardlee (MHY) 的大作中提到: 】 
: 貌似是多任务轮询分片,不能抢占内核,但2.6做了些软实时,但还是不满足工控 




☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sat Oct 27 15:27:01 2012)  提到: 

谢谢 
只要有人用着靠谱,我就用这个了,毕竟电力保护控制实时性不是那么夸张,更重要的是可靠 

【 在 kidstar (linux) 的大作中提到: 】 
: linux + 实时补丁吧 
: 很多电力保护装置在用 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sat Oct 27 15:28:38 2012)  提到: 

嗯,谢谢提醒 
我也在认真评估,电科院测试要求40毫秒内,我想做30毫秒左右,要求其实也不是那么高 

【 在 cordoba (最佳中卫※静以修身|俭以养德) 的大作中提到: 】 
: 实际大部分情况的实时要求都没那么高。 
: 还是对需求做好评价之后再选择。 



☆─────────────────────────────────────☆ 
  
 yanyao (焱垚) 于  (Sat Oct 27 16:11:27 2012)  提到: 

ucos或者QNX? 

【 在 leopardlee 的大作中提到: 】 
: 做个控制的项目 
: 平台必须是ARM9(领导定的),因为对实时性有所要求,对系统的选择有点难产了 
: VXWORKS  初始授权30万左右,我刚来这个公司,估计很难批下来;如果用盗版,且不说源码&资料不好搞,最重要是未来可能会有官司,现在WINDRIVER查的很严 
: ................... 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sat Oct 27 16:15:08 2012)  提到: 

四方的么? 

【 在 leopardlee (MHY) 的大作中提到: 】 
: 嗯,谢谢提醒 
: 我也在认真评估,电科院测试要求40毫秒内,我想做30毫秒左右,要求其实也不是那么高 




☆─────────────────────────────────────☆ 
  
 thkdragon (kernel) 于  (Sat Oct 27 16:15:13 2012)  提到: 

QNX不免费吧 


【 在 yanyao (焱垚) 的大作中提到: 】 
: ucos或者QNX? 




☆─────────────────────────────────────☆ 
  
 yanyao (焱垚) 于  (Sat Oct 27 16:18:50 2012)  提到: 

我记得是免费的,以前在小项目上用过,感觉和Linux很像。 
你可以再查查确认一下。 


【 在 thkdragon 的大作中提到: 】 
: QNX不免费吧 
:  
:  



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sat Oct 27 17:23:41 2012)  提到: 

个人跟非商业用户免费吧 

【 在 yanyao (焱垚) 的大作中提到: 】 
: 我记得是免费的,以前在小项目上用过,感觉和Linux很像。 
: 你可以再查查确认一下。 




☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sat Oct 27 18:10:16 2012)  提到: 

四方这种破地方,轮不到我选系统吧 

【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: 四方的么? 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sat Oct 27 18:18:18 2012)  提到: 

大概看了下rtems的资料,貌似不错,但资料太少了,怕一个人搞不定啊,而且对ARM支持不是很好 

【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: 先re一下 
: 再现身说法一下,rtems 用在列车控制器上 
: eCos用在小煤化工控制器上,运行良好…… 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sat Oct 27 18:20:39 2012)  提到: 

哈哈 
【 在 leopardlee (MHY) 的大作中提到: 】 
: 四方这种破地方,轮不到我选系统吧 




☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sat Oct 27 18:22:01 2012)  提到: 

应该对 三星 atmel 以及NXP的一些arm9支持很好了吧…… 

【 在 leopardlee (MHY) 的大作中提到: 】 
: 大概看了下rtems的资料,貌似不错,但资料太少了,怕一个人搞不定啊,而且对ARM支持不是很好 




☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sat Oct 27 18:31:21 2012)  提到: 

有啥不能说的, 
不就为了生存问题不能支持多核心,MIPS64么 

RT-Thread不是说只能支持CM3,ARM9当然也支持得很好,也有企业使用在产品上。在1.1.0 
系列中有JFFS2文件系统移植,这就是当时给一家企业移植,并按照JFFS2的许可证方式开 
源出来的。 

【 在 Aquamarine (你大爷永远都是你大爷) 的大作中提到: 】 
: 亲,不要误导别人啊。 
: djy是深圳南瑞的老罗搞的,我认识老罗,所以有些事情不说了。 
: RTT是上海Marvell的老熊写的,支持ARM CM3最好,我认识老熊,所以有些事情不说 
: ................... 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sat Oct 27 18:33:27 2012)  提到: 

RTT如果能有较多的应用,就让我们这些观望的人有些底了。。。。 

比如我们做东西,纠结半天之后,还是Freertos了。。。 



【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 有啥不能说的, 
: 不就为了生存问题不能支持多核心,MIPS64么 
: RT-Thread不是说只能支持CM3,ARM9当然也支持得很好,也有企业使用在产品上。在1.1.0 
: ................... 



☆─────────────────────────────────────☆ 
  
 Aquamarine (你大爷永远都是你大爷) 于  (Sat Oct 27 18:43:09 2012)  提到: 

熊总驾到,framework才是王道啊,什么都不扯了,我请客,你掏钱,发票可以给我,哈 
哈 

【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 有啥不能说的, 
: 不就为了生存问题不能支持多核心,MIPS64么 
: RT-Thread不是说只能支持CM3,ARM9当然也支持得很好,也有企业使用在产品上。 
在1.1.0 
: ................... 



☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sat Oct 27 19:03:24 2012)  提到: 

这个我并不是这么看, 
案例虽然有一堆,但是别人基于RT-Thread能够做出来好用的产品,但并不代表换一个 
人也能够做出来。 

所以我建议的方式依然是: 
寻找适合的系统进行评估,是否符合自己的风格方式,是否稳定,或者某些不行但自己 
能够解决。另外,测试的投入是必不可少的,这也与产品的稳定性息息相关(即使采用 
的是商业系统)。 

使用开源、免费的系统,投入更多精力是很明显的,不同的开源系统区别只在于后续投 
入精力的多少。开源的系统只是打开了一扇窗,就看这扇窗是否适合自己,因为开源, 
可以把握的东西能够更多。 

RT-Thread的好处在于,当有什么问题时可以寻找本地化的支持,甚至寻找商业性的支 
持都可以。不可否认的是RT-Thread还存在很多缺陷,文档严重不足,甚至是 
Aquamarine刚提出来的,哪里有一个下载下去就能跑起来的版本,这个我同样回答不出 
来。所以后续的1.2.0版本更多的还需要在周边下功夫,framework虽然好,但是缺乏基 
本的这些东西,framework急剧扩充,大家都不会使用也是白搭。<framework不就是代 
码么,专业码农还担心码不出来代码?!> 

【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: RTT如果能有较多的应用,就让我们这些观望的人有些底了。。。。 
: 比如我们做东西,纠结半天之后,还是Freertos了。。。 


☆─────────────────────────────────────☆ 
  
 hubertabc (Ludewig) 于  (Sat Oct 27 19:22:15 2012)  提到: 

30毫秒我觉得这些系统问题都不大,linux的问题是要自己调整下 
linux,rtems,vxworks神马的我们都用过了, 
【 在 leopardlee (MHY) 的大作中提到: 】 
: 做个控制的项目 
: 平台必须是ARM9(领导定的),因为对实时性有所要求,对系统的选择有点难产了 
: VXWORKS  初始授权30万左右,我刚来这个公司,估计很难批下来;如果用盗版,且不说源码&资料不好搞,最重要是未来可能会有官司,现在WINDRIVER查的很严 
: ................... 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sat Oct 27 19:29:51 2012)  提到: 

你说的没错,不过一个rtt如果真的想做到足够大,不推广开来肯定是不行的 

大部分的工程师,都会有从众的心理,而用户数量明显会影响你所说的操作系统“演化” 

我也不认可framework才是王道的说法 

对于我们来说,做的都是非常专用的东西,我们需要的,是一个用户数量足够大,参考文档 
足够多的一个微内核,其他的东西,除了TCP/IP协议,我们都是更想自己来完成的。 

国内做rtos的 rtt算是做的很好的,期待能有一个准确的定位,也有一个较大的用户群, 



【 在 ffxz 的大作中提到: 】 
: 这个我并不是这么看, 
: 案例虽然有一堆,但是别人基于RT-Thread能够做出来好用的产品,但并不代表换一个 
: 人也能够做出来。 
: ................... 



☆─────────────────────────────────────☆ 
  
 EuroPad (好奇的中年 | 不断的犯错,又不断的远离) 于  (Sat Oct 27 19:30:54 2012)  提到: 


        赞。。。 

【 在 Aquamarine (你大爷永远都是你大爷) 的大作中提到: 】 
: 标  题: Re: 关于操作系统的选择,闹心,大牛给点指点吧 
: 发信站: 水木社区 (Sat Oct 27 10:58:27 2012), 站内 
:  
: 亲,不要误导别人啊。 
: djy是深圳南瑞的老罗搞的,我认识老罗,所以有些事情不说了。 
: RTT是上海Marvell的老熊写的,支持ARM CM3最好,我认识老熊,所以有些事情不说 
: 了。 
: 作为一个不懂技术的人,也没上过什么学,个人觉得,djy和RTT都是单片机系统,上手可 
: 能比较容易,但是没有一个完整统一稳定的framework。做嵌入式产品最多的工作是什 
: 么?是维护,选型不合适,初期开发爽了一下,后期维护,你伤的起么? 
:  
: RTEMS被NASA扔上了太空。eCos在一些机器人中有使用,现在这个项目好像基本挂了。 
: RTLinux也经得起华为的检验了。 
: 这仨都是无版税,并且经得起历史检验的,做产品,最重要求稳,开发的时候儿戏,市场 
: 也可以儿戏么? 
:  
: 【 在 dormouseBHU (dormouseBHU) 的大作中提到: 】 
: : uCOS-II 就挺好,不想吃官司还有 FreeRTOS、RT-Thread。 
: : 比起来,RT-Thread 功能最强,个人觉得已经不比商业的实时操作系统差了,而且是国 
: 人搞的,可以支持一下。 
: : 另外 djyos 也不错。 
: -- 
:  
※ 来源:·水木社区 http://newsmth.net·[FROM: 111.161.71.*] 




☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sat Oct 27 19:42:21 2012)  提到: 

是做什么只需要30ms?许继的电力保护装置给我们的要求是1us 

如果是30ms,linux只要稍微注意些足够了。 

【 在 leopardlee (MHY) 的大作中提到: 】 
: 嗯,谢谢提醒 
: 我也在认真评估,电科院测试要求40毫秒内,我想做30毫秒左右,要求其实也不是那么 
高 



☆─────────────────────────────────────☆ 
  
 einsnabuck (爱家爱老婆) 于  (Sat Oct 27 19:51:10 2012)  提到: 

RTLinux华为和北电都用了好几年。只能经受业界考验的,才值得用。 
【 在 Aquamarine 的大作中提到: 】 
: 亲,不要误导别人啊。 
: djy是深圳南瑞的老罗搞的,我认识老罗,所以有些事情不说了。 
: RTT是上海Marvell的老熊写的,支持ARM CM3最好,我认识老熊,所以有些事情不说 
: ................... 



☆─────────────────────────────────────☆ 
  
 dormouseBHU (dormouseBHU) 于  (Sat Oct 27 20:37:16 2012)  提到: 

rtems 可以上 csdn 找 coolbacon。他是高手。 

【 在 leopardlee 的大作中提到: 】 
: 大概看了下rtems的资料,貌似不错,但资料太少了,怕一个人搞不定啊,而且对ARM支持不是很好 
:  



☆─────────────────────────────────────☆ 
  
 dormouseBHU (dormouseBHU) 于  (Sat Oct 27 20:57:19 2012)  提到: 

不要张口闭口 framework,对于大多数工业控制类的应用我不推荐上个大而全的 framework。代码是否易于维护也与 framework 无关。 

现在的嵌入式程序员有个趋势,感觉自己不会用 linux 就低人一等,这不是什么好事。 


【 在 Aquamarine 的大作中提到: 】 
: 亲,不要误导别人啊。 
: djy是深圳南瑞的老罗搞的,我认识老罗,所以有些事情不说了。 
: RTT是上海Marvell的老熊写的,支持ARM CM3最好,我认识老熊,所以有些事情不说 
: ................... 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sat Oct 27 21:12:34 2012)  提到: 

linux主要是资源太丰富了,在实时性要求不高的地方用linux确实是上上之选。 

真的要求实时性特别好的场合其实也不多 

【 在 dormouseBHU (dormouseBHU) 的大作中提到: 】 
: 不要张口闭口 framework,对于大多数工业控制类的应用我不推荐上个大而全的 framework。代码是否易于维护也与 framework 无关。 
: 现在的嵌入式程序员有个趋势,感觉自己不会用 linux 就低人一等,这不是什么好事。 




☆─────────────────────────────────────☆ 
  
 farther (ξαγτηεγ) 于  (Sat Oct 27 21:29:29 2012)  提到: 

不同应用对实时性要求不一样,有的应用响应控制在10us以内叫实时,有的应用响应控制在一小时甚至一天以内就可以叫实时了。 
【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: linux主要是资源太丰富了,在实时性要求不高的地方用linux确实是上上之选。 
: 真的要求实时性特别好的场合其实也不多 




☆─────────────────────────────────────☆ 
  
 feb29 (每天爱你多一些) 于  (Sat Oct 27 21:31:21 2012)  提到: 

所谓实时,本质上不是快慢问题,而是时间上的可预测性 
【 在 farther (ξαγτηεγ) 的大作中提到: 】 
: 不同应用对实时性要求不一样,有的应用响应控制在10us以内叫实时,有的应用响应控制在一小时甚至一天以内就可以叫实时了。 




☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sat Oct 27 21:35:07 2012)  提到: 

嗯,有个确定的定义跟通俗的定义, 

单说实时性的定义,是在特定长的时间内一定对外来事件做出反应。 

这个特定长的时间可长可短 

但是一般咱们说实时操作系统,都是对于响应时间有苛刻要求的吧。 


我们一般是这么决定的 ,要求的响应时间要求20ms以上的可以用linux 

其他的,要么用rtems,要么是freertos 


【 在 farther (ξαγτηεγ) 的大作中提到: 】 
: 标  题: Re: 关于操作系统的选择,闹心,大牛给点指点吧 
: 发信站: 水木社区 (Sat Oct 27 21:29:29 2012), 站内 
:  
: 不同应用对实时性要求不一样,有的应用响应控制在10us以内叫实时,有的应用响应控制在一小时甚至一天以内就可以叫实时了。 
: 【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: : linux主要是资源太丰富了,在实时性要求不高的地方用linux确实是上上之选。 
: : 真的要求实时性特别好的场合其实也不多 
:  
:  
: -- 
: 结婚快七年了,老婆问:要给你买个不求人不? 
:  
:  
※ 来源:·水木社区 newsmth.net·[FROM: 112.21.150.*] 




☆─────────────────────────────────────☆ 
  
 dormouseBHU (dormouseBHU) 于  (Sat Oct 27 21:38:43 2012)  提到: 

如果真的精通 linux 那没问题,随便用。 
linux 的问题是,写好程序后如果性能够用那OK,如果实时性一类的有达不到的地方改起来能把你整死,让你有种推到重来的冲动。 

而且实时性并不是说程序要跑得多快,楼主的应用 20ms 的deadline 如果绝对不许逾越那就是硬实时,不打实时补丁的 linux 肯定不行。 

【 在 nuptguizi 的大作中提到: 】 
: linux主要是资源太丰富了,在实时性要求不高的地方用linux确实是上上之选。 
: 真的要求实时性特别好的场合其实也不多 
:  



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sat Oct 27 21:40:13 2012)  提到: 

20ms,如果处理得当,不打补丁的linux还是可以的 

【 在 dormouseBHU (dormouseBHU) 的大作中提到: 】 
: 如果真的精通 linux 那没问题,随便用。 
: linux 的问题是,写好程序后如果性能够用那OK,如果实时性一类的有达不到的地方改起来能把你整死,让你有种推到重来的冲动。 
: 而且实时性并不是说程序要跑得多快,楼主的应用 20ms 的deadline 如果绝对不许逾越那就是硬实时,不打实时补丁的 linux 肯定不行。 
: ................... 



☆─────────────────────────────────────☆ 
  
 maybug (maybug) 于  (Sat Oct 27 22:52:51 2012)  提到: 

ucos的价格 

UCOS核,7500USD 
TCPIP模块,1WUSD 
UCGUI,6000USD 
还有其他模块都是5000USD以上,就没有仔细咨询 
以上价格要求是单一产品上使用!比如示波器的话,就是定在一个型号内使用,如果是系列产品,比如示波器系列,那价格就是以上价格的5倍。 
另外还有种价格就是按芯片收费,比如使用STM32F103ZET6这个芯片,那支付以上价格的6.5倍,就可以使用这一款芯片开发所有产品。 


☆─────────────────────────────────────☆ 
  
 Ylong (沧海云龙) 于  (Sat Oct 27 23:04:25 2012)  提到: 

我在板子上加一个1us的硬时钟中断 
这样的话做到us级的响应毫无问题啊? 
所谓的Linux不支持实时控制指的是什么啊? 
【 在 leopardlee (MHY) 的大作中提到: 】 
: 做个控制的项目 
: 平台必须是ARM9(领导定的),因为对实时性有所要求,对系统的选择有点难产了 
: VXWORKS  初始授权30万左右,我刚来这个公司,估计很难批下来;如果用盗版,且不说源码&资料不好搞,最重要是未来可能会有官司,现在WINDRIVER查的很严 
: ................... 



☆─────────────────────────────────────☆ 
  
 kezhou2 (kezhou2) 于  (Sat Oct 27 23:18:42 2012)  提到: 

mark一下 


☆─────────────────────────────────────☆ 
  
 offerscome (街灯※看月亮不如看我吧) 于  (Sun Oct 28 00:24:30 2012)  提到: 

芯片引脚的中断信号给过去了,操作系统还得干活啊 

除非你的“硬中断”是硬件负责把保护,切换都管起来的 

【 在 Ylong (沧海云龙) 的大作中提到: 】 
: 我在板子上加一个1us的硬时钟中断 
: 这样的话做到us级的响应毫无问题啊? 
: 所谓的Linux不支持实时控制指的是什么啊? 
: ................... 



☆─────────────────────────────────────☆ 
  
 max2008 (engineer) 于  (Sun Oct 28 01:47:48 2012)  提到: 

倾向这个说法。我的理解是,实时是指中断或高优先级任务能够立即抢到运行权,这个响应的时间是确定的,不会在任何情况下被任何其他系统任务耽误。最好还支持中断嵌套。 
【 在 feb29 (每天爱你多一些) 的大作中提到: 】 
: 所谓实时,本质上不是快慢问题,而是时间上的可预测性 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 07:08:45 2012)  提到: 

谢谢:) 

这个1us得看从哪里到哪里,别的不说,继电器动作时间1us? 

我再好好看看资料,vxworks基本不可行,想选linux+rt但也要理性,其他rtems之类的不熟悉要花点时间了解下 

【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 是做什么只需要30ms?许继的电力保护装置给我们的要求是1us 
: 如果是30ms,linux只要稍微注意些足够了。 
: 高 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 07:09:12 2012)  提到: 

谢谢 
我仔细看看 

【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: 应该对 三星 atmel 以及NXP的一些arm9支持很好了吧…… 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 07:10:22 2012)  提到: 

万分感谢 
【 在 dormouseBHU (dormouseBHU) 的大作中提到: 】 
: rtems 可以上 csdn 找 coolbacon。他是高手。 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 07:12:14 2012)  提到: 

linux还好,对rtlinux了解也很有限,需要再仔细看看 


【 在 einsnabuck (爱家爱老婆) 的大作中提到: 】 
: RTLinux华为和北电都用了好几年。只能经受业界考验的,才值得用。 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 07:13:22 2012)  提到: 

谢谢 

但我这个30毫秒不是单Linux的相应时间。。。 

【 在 hubertabc (Ludewig) 的大作中提到: 】 
: 30毫秒我觉得这些系统问题都不大,linux的问题是要自己调整下 
: linux,rtems,vxworks神马的我们都用过了, 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 07:14:32 2012)  提到: 

赞同 
可预测性最重要 

【 在 feb29 (每天爱你多一些) 的大作中提到: 】 
: 所谓实时,本质上不是快慢问题,而是时间上的可预测性 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 07:18:25 2012)  提到: 

嗯,补丁肯定是要打的,必须是硬实时,但对RTLINUX又不敢确定是否可稳定运行 

【 在 dormouseBHU (dormouseBHU) 的大作中提到: 】 
: 如果真的精通 linux 那没问题,随便用。 
: linux 的问题是,写好程序后如果性能够用那OK,如果实时性一类的有达不到的地方改起来能把你整死,让你有种推到重来的冲动。 
: 而且实时性并不是说程序要跑得多快,楼主的应用 20ms 的deadline 如果绝对不许逾越那就是硬实时,不打实时补丁的 linux 肯定不行。 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 07:31:07 2012)  提到: 

中断是有了,但想处理这个中断得在LINUX那里排队等待,所以》。。 

【 在 Ylong (沧海云龙) 的大作中提到: 】 
: 我在板子上加一个1us的硬时钟中断 
: 这样的话做到us级的响应毫无问题啊? 
: 所谓的Linux不支持实时控制指的是什么啊? 



☆─────────────────────────────────────☆ 
  
 xiaokang (GG没钱没地位,MM没照没真相) 于  (Sun Oct 28 09:06:11 2012)  提到: 

是呀。 
可是那种芯片不便宜的。 
比如,为了避免上下文切换的开销,CPU里面提供多套寄存器。 
现在楼主领导看起来就懂这个。 

【 在 offerscome (街灯※看月亮不如看我吧) 的大作中提到: 】 
: 芯片引脚的中断信号给过去了,操作系统还得干活啊 
: 除非你的“硬中断”是硬件负责把保护,切换都管起来的 



☆─────────────────────────────────────☆ 
  
 easyfish (晶鱼) 于  (Sun Oct 28 10:37:52 2012)  提到: 

那是因为linux比其他实时系统都复杂。 

搞技术的不就追求这个嘛 

【 在 dormouseBHU (dormouseBHU) 的大作中提到: 】 
: 不要张口闭口 framework,对于大多数工业控制类的应用我不推荐上个大而全的 framework。代码是否易于维护也与 framework 无关。 
: 现在的嵌入式程序员有个趋势,感觉自己不会用 linux 就低人一等,这不是什么好事。 




☆─────────────────────────────────────☆ 
  
 About2Rain (狐说) 于  (Sun Oct 28 12:37:54 2012)  提到: 

30ms,你自己的应用处理会占多少? 
能不能保证100%都在30ms内? 


我觉得你最好不要过于乐观 


【 在 leopardlee 的大作中提到: 】 
: 嗯,谢谢提醒 
: 我也在认真评估,电科院测试要求40毫秒内,我想做30毫秒左右,要求其实也不是那么高 
:  



☆─────────────────────────────────────☆ 
  
 catch22 (U2) 于  (Sun Oct 28 12:59:38 2012)  提到: 

领导对有几个arm9处理器没要求,你就底层实时性高的控制用uCOSII(基本配置也不贵),高级应用用linux呗。两个处理器的通讯就看你的需求了 
【 在 leopardlee (MHY) 的大作中提到: 】 
: 做个控制的项目 
: 平台必须是ARM9(领导定的),因为对实时性有所要求,对系统的选择有点难产了 
: VXWORKS  初始授权30万左右,我刚来这个公司,估计很难批下来;如果用盗版,且不说源码&资料不好搞,最重要是未来可能会有官司,现在WINDRIVER查的很严 
: ................... 



☆─────────────────────────────────────☆ 
  
 feb29 (每天爱你多一些) 于  (Sun Oct 28 13:28:53 2012)  提到: 

你怎么控制调度策略? 
【 在 Ylong (沧海云龙) 的大作中提到: 】 
: 我在板子上加一个1us的硬时钟中断 
: 这样的话做到us级的响应毫无问题啊? 
: 所谓的Linux不支持实时控制指的是什么啊? 
: ................... 



☆─────────────────────────────────────☆ 
  
 wrtc (平安) 于  (Sun Oct 28 15:15:18 2012)  提到: 

windows xp挺好用的 
【 在 leopardlee 的大作中提到: 】 
: 做个控制的项目 
: 平台必须是ARM9(领导定的),因为对实时性有所要求,对系统的选择有点难产了 
: VXWORKS  初始授权30万左右,我刚来这个公司,估计很难批下来;如果用盗版,且不说源码&资料不好搞,最重要是未来可能会有官司,现在WINDRIVER查的很严 
: ................... 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 16:29:03 2012)  提到: 

今天中午请了几个大牛吃饭 

大家一致认为linux完全可以胜任,实在不行加rtlinux补丁即可 

但愿事实如此 

【 在 About2Rain (狐说) 的大作中提到: 】 
: 30ms,你自己的应用处理会占多少? 
: 能不能保证100%都在30ms内? 
: 我觉得你最好不要过于乐观 



☆─────────────────────────────────────☆ 
  
 About2Rain (狐说) 于  (Sun Oct 28 16:45:15 2012)  提到: 

大牛也是分行业的 
他们懂电力的应用吗? 

而且我觉得你的出发点有问题,做这事的目的不是为了自己能学到多少东西,不是为了自己做实验 
而是为组织带来效益。这个就当我多嘴 

Linux的话,Montavista很好的 

【 在 leopardlee 的大作中提到: 】 
: 今天中午请了几个大牛吃饭 
: 大家一致认为linux完全可以胜任,实在不行加rtlinux补丁即可 
: 但愿事实如此 
: ................... 



☆─────────────────────────────────────☆ 
  
 lvys (驴子) 于  (Sun Oct 28 16:48:44 2012)  提到: 


【 在 leopardlee 的大作中提到: 】 
: 做个控制的项目 
: 平台必须是ARM9(领导定的),因为对实时性有所要求,对系统的选择有点难产了 
: VXWORKS  初始授权30万左右,我刚来这个公司,估计很难批下来;如果用盗版,且不说源码&资料不好搞,最重要是未来可能会有官司,现在WINDRIVER查的很严 
: ................... 
30ms是包括继电器动作时间的,一般的继电器要考虑7~~10ms的动作时间,你如果想做到20ms的话留给CPU的响应时间就非常少了,如果ARM9再做交采FFT计算的话最好还是别考虑linux了,继电保护是一个实时性非常强的东西。 


☆─────────────────────────────────────☆ 
  
 xyeah (neo) 于  (Sun Oct 28 16:56:36 2012)  提到: 

rtlinux不是要钱的吗? 


☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 17:11:22 2012)  提到: 

谢谢 
你这个说的比较专业 
加RTLINUX补丁呢? 

另外您推荐什么系统呢,谢谢 

【 在 lvys (驴子) 的大作中提到: 】 
: 30ms是包括继电器动作时间的,一般的继电器要考虑7~~10ms的动作时间,你如果想做到20ms的话留给CPU的响应时间就非常少了,如果ARM9再做交采FFT计算的话最好还是别考虑linux了,继电保护是一个实时性非常强的东西。 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 17:14:35 2012)  提到: 

有2个电力行业的 
都是从VXWORKS转到linux上来的 
这两个是亲师兄,应该不会忽悠我 

还有一个老师兄,40了已经,做过的东西比较杂,也说可以 

我还会认真评估,自己看看资料,接着找些靠谱的人咨询(当然包括版上各位,谢谢了),下周末确定就行 


【 在 About2Rain (狐说) 的大作中提到: 】 
: 大牛也是分行业的 
: 他们懂电力的应用吗? 
: 而且我觉得你的出发点有问题,做这事的目的不是为了自己能学到多少东西,不是为了自己做实验 
: ................... 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 17:14:53 2012)  提到: 

有不要钱的 

【 在 xyeah (neo) 的大作中提到: 】 
: rtlinux不是要钱的吗? 



☆─────────────────────────────────────☆ 
  
 Ylong (沧海云龙) 于  (Sun Oct 28 17:51:22 2012)  提到: 

我一直以为硬件中断不需要操作系统调度的 
操作系统花上几毫秒去调度,黄花菜都凉了 
【 在 feb29 (每天爱你多一些) 的大作中提到: 】 
: 你怎么控制调度策略? 




☆─────────────────────────────────────☆ 
  
 lvys (驴子) 于  (Sun Oct 28 17:55:30 2012)  提到: 


【 在 leopardlee 的大作中提到: 】 
: 谢谢 
: 你这个说的比较专业 
: 加RTLINUX补丁呢? 
: ................... 
RTLINUX我不太了解,我之前做过的继保产品都是DSP裸奔,如果你的ARM9有200M的话可以试一试ECOS。 


☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 18:00:08 2012)  提到: 

谢谢 
对我来说,选系统这一步最重要,知识也最薄弱。。。其他功能实现啥的都好说,唉 

【 在 lvys (驴子) 的大作中提到: 】 
: RTLINUX我不太了解,我之前做过的继保产品都是DSP裸奔,如果你的ARM9有200M的话可以试一试ECOS。 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sun Oct 28 18:00:50 2012)  提到: 

对linux有足够的了解,做到这个问题不大。 
【 在 leopardlee 的大作中提到: 】 
: 有2个电力行业的 
: 都是从VXWORKS转到linux上来的 
: 这两个是亲师兄,应该不会忽悠我 
: ................... 



☆─────────────────────────────────────☆ 
  
 farther (ξαγτηεγ) 于  (Sun Oct 28 18:02:31 2012)  提到: 

一般us级的延迟还可以容忍,毫秒级的确实太长了,不过操作系统一般只调度中断以外的任务吧。 
【 在 Ylong (沧海云龙) 的大作中提到: 】 
: 我一直以为硬件中断不需要操作系统调度的 
: 操作系统花上几毫秒去调度,黄花菜都凉了 




☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 18:10:10 2012)  提到: 

师兄说保护这部分linux是会比vxworks慢,但也完全满足要求,30ms左右,且任务不重时(实际上也没啥重任务),基本都在25ms以内,vxworks可以做到20ms左右,裸跑大约17ms 

但在其他方面Linux就比vxworks强太多了 

我也在看他们给的资料,继续学习:) 


【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: 对linux有足够的了解,做到这个问题不大。 



☆─────────────────────────────────────☆ 
  
 lvys (驴子) 于  (Sun Oct 28 18:35:34 2012)  提到: 


【 在 leopardlee 的大作中提到: 】 
: 谢谢 
: 对我来说,选系统这一步最重要,知识也最薄弱。。。其他功能实现啥的都好说,唉 
:  
如果是做继保产品的话操作系统倒不是什么主要的问题,只要是硬实时的系统问题都不大。 


☆─────────────────────────────────────☆ 
  
 feb29 (每天爱你多一些) 于  (Sun Oct 28 19:07:41 2012)  提到: 

处理器跑得够快,linux有优势,不过问题已经跟实时无关了 
vxworks标称是实时操作系统,linux不是 
【 在 leopardlee (MHY) 的大作中提到: 】 
: 师兄说保护这部分linux是会比vxworks慢,但也完全满足要求,30ms左右,且任务不重时(实际上也没啥重任务),基本都在25ms以内,vxworks可以做到20ms左右,裸跑大约17ms 
: 但在其他方面Linux就比vxworks强太多了 
: 我也在看他们给的资料,继续学习:) 
: ................... 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sun Oct 28 19:39:45 2012)  提到: 

Vxworks应该还能更快吧。。。 

【 在 leopardlee (MHY) 的大作中提到: 】 
: 师兄说保护这部分linux是会比vxworks慢,但也完全满足要求,30ms左右,且任务不重时(实际上也没啥重任务),基本都在25ms以内,vxworks可以做到20ms左右,裸跑大约17ms 
: 但在其他方面Linux就比vxworks强太多了 
: 我也在看他们给的资料,继续学习:) 
: ................... 



☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sun Oct 28 19:53:26 2012)  提到: 

这个主要在于系统关闭中断导致中断响应延迟。 

一般都比较难做到系统关闭中断的最大时间是恒定的,而RT-Thread中由于有定时器的存 
在,导致这部分关闭中断的时间与系统中有多少个定时器成正比(当达到100个线程时, 
这部分时间会延迟到100us)。 

Linux上应该是ms级别的。 

【 在 Ylong (沧海云龙) 的大作中提到: 】 
: 我一直以为硬件中断不需要操作系统调度的 
: 操作系统花上几毫秒去调度,黄花菜都凉了 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 19:56:59 2012)  提到: 

嗯 
估计最后还得上RTLINUX补丁 
【 在 lvys (驴子) 的大作中提到: 】 
: 如果是做继保产品的话操作系统倒不是什么主要的问题,只要是硬实时的系统问题都不大。 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 19:58:17 2012)  提到: 

其实只要在规定的时间内可靠的完成任务,就OK 

只是软实时还是没有硬实时心理踏实,所以RTLINUX估计是避免不了 

【 在 feb29 (每天爱你多一些) 的大作中提到: 】 
: 处理器跑得够快,linux有优势,不过问题已经跟实时无关了 
: vxworks标称是实时操作系统,linux不是 



☆─────────────────────────────────────☆ 
  
 hubertabc (Ludewig) 于  (Sun Oct 28 20:00:18 2012)  提到: 

都到几十毫秒量级了,还能有啥问题?需要注意的倒是任务的分配 
【 在 leopardlee 的大作中提到: 】 
: 谢谢 
: 但我这个30毫秒不是单Linux的相应时间。。。 
:  



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 20:00:34 2012)  提到: 

差不多也就这样了 

更重要的差别是VXWORKS可以很踏实,Linux弄得好虽然很稳定,但还是心虚 

【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: Vxworks应该还能更快吧。。。 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 20:02:06 2012)  提到: 

嗯 
主要还是可靠性,这对水平要求较高 

到时我会严格测试,结果会上来报告,实在不成,就打RTLINUX补丁 


【 在 hubertabc (Ludewig) 的大作中提到: 】 
: 都到几十毫秒量级了,还能有啥问题?需要注意的倒是任务的分配 



☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sun Oct 28 20:06:54 2012)  提到: 

我有些怀疑你要求的30ms时间仅仅是其中需求之一。 

我原来接触过的实时要求是因为要进行周期性采样,而采样偏差点要在1%以内,所以基本上系 
统的中断响应时间就在us级别了。 

给个RT-Thread在ARM Cortex-M3 144MHz下的指标情况: 
* 直接挂起操作进行任务上下文切换 2.791 us 
* 信号量引起的任务上下文切换 3.409 us 
* 邮箱发送引起的任务上下文切换 4.368 us 

RT-Thread 开源版本的中断响应时间,当系统存在多个任务 & 定时器时,最大的中断响应时间  
> 100us (与系统定时数目正相关,此数据是当系统中存在100个任务时的情况) 

+ 实时补丁后,中断响应时间:< 0.68 us (中断响应时间在0.34 - 0.67 us之间飘,并不恒 
定,这个是因为+实时补丁后,系统在任务切换时为了支持中断嵌套做了一次强制性的关闭总中 
断处理。除了这个地方,系统不再关闭系统的总中断了) 

所以我个人觉得,作为RTOS,任务切换至少要在us级别,中断响应在us级别算是正常的,到ms 
级别就太搓了!<这两个指标会直接影响系统对外部事件的响应时间> 

【 在 leopardlee (MHY) 的大作中提到: 】 
: 谢谢 
: 你这个说的比较专业 
: 加RTLINUX补丁呢? 
: ................... 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sun Oct 28 20:29:11 2012)  提到: 

+实时补丁后可以到这么短么? 

我记得我看的某个国际控制年会上一篇文献,Vxworks貌似在PPC604(300Mhz)的情况下, 

2,000,000次中断,中断平均频率4kHz时的情况下,中断延迟最大有13.1us,平均2us 

rtt可以到最大不到1us? 

是我的理解不对吗? 


【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 标  题: Re: 关于操作系统的选择,闹心,大牛给点指点吧 
: 发信站: 水木社区 (Sun Oct 28 20:06:54 2012), 站内 
:  
: 我有些怀疑你要求的30ms时间仅仅是其中需求之一。 
:  
: 我原来接触过的实时要求是因为要进行周期性采样,而采样偏差点要在1%以内,所以基本上系 
: 统的中断响应时间就在us级别了。 
:  
: 给个RT-Thread在ARM Cortex-M3 144MHz下的指标情况: 
: * 直接挂起操作进行任务上下文切换 2.791 us 
: * 信号量引起的任务上下文切换 3.409 us 
: * 邮箱发送引起的任务上下文切换 4.368 us 
:  
: RT-Thread 开源版本的中断响应时间,当系统存在多个任务 & 定时器时,最大的中断响应时间  
: > 100us (与系统定时数目正相关,此数据是当系统中存在100个任务时的情况) 
:  
: + 实时补丁后,中断响应时间:< 0.68 us (中断响应时间在0.34 - 0.67 us之间飘,并不恒 
: 定,这个是因为+实时补丁后,系统在任务切换时为了支持中断嵌套做了一次强制性的关闭总中 
: 断处理。除了这个地方,系统不再关闭系统的总中断了) 
:  
: 所以我个人觉得,作为RTOS,任务切换至少要在us级别,中断响应在us级别算是正常的,到ms 
: 级别就太搓了!<这两个指标会直接影响系统对外部事件的响应时间> 
:  
: 【 在 leopardlee (MHY) 的大作中提到: 】 
: : 谢谢 
: : 你这个说的比较专业 
: : 加RTLINUX补丁呢? 
: : ................... 
:  
: -- 
: - http://www.rt-thread.org 
: RT-Thread启动下一代实时操作系统的演化... 
:  
:  
※ 来源:·水木社区 http://newsmth.net·[FROM: 180.172.76.*] 




☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sun Oct 28 20:33:33 2012)  提到: 

可以做到的, 
因为这个时候系统基本上就没有关闭过中断 
(关闭中断的时间仅在任务上下文切换时,这部分时间应该是0.34us左右) 

【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: +实时补丁后可以到这么短么? 
: 我记得我看的某个国际控制年会上一篇文献,Vxworks貌似在PPC604(300Mhz)的情况 
下, 
: 2,000,000次中断,中断平均频率4kHz时的情况下,中断延迟最大有13.1us,平均2us 
: ................... 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sun Oct 28 20:35:54 2012)  提到: 

是这么计算的啊。。。那就是计算方法不同。。。 

【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 可以做到的, 
: 因为这个时候系统基本上就没有关闭过中断 
: (关闭中断的时间仅在任务上下文切换时,这部分时间应该是0.34us左右) 
: ................... 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 20:36:56 2012)  提到: 

谢谢谢谢 
好多细节我还在仔细计算 

看了你的网站,M4+RTT也是个好选择啊,呵呵 

【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 我有些怀疑你要求的30ms时间仅仅是其中需求之一。 
: 我原来接触过的实时要求是因为要进行周期性采样,而采样偏差点要在1%以内,所以基本上系 
: 统的中断响应时间就在us级别了。 
: ................... 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 20:40:01 2012)  提到: 

我也看了这个测试结果,RTLINUX也不错啊,除了重负载时比较差,但我的东西基本没有重负载 

【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: +实时补丁后可以到这么短么? 
: 我记得我看的某个国际控制年会上一篇文献,Vxworks貌似在PPC604(300Mhz)的情况下, 
: 2,000,000次中断,中断平均频率4kHz时的情况下,中断延迟最大有13.1us,平均2us 
: ................... 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sun Oct 28 20:41:31 2012)  提到: 

话说说个题外话,继电保护的市场竞争据说很激烈。。。成本是不是比较重要? 

【 在 leopardlee (MHY) 的大作中提到: 】 
: 我也看了这个测试结果,RTLINUX也不错啊,除了重负载时比较差,但我的东西基本没有重负载 




☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 20:43:35 2012)  提到: 

还好吧 
我明确的说用STM32啥的,可以省100多的硬成本,还可以节省至少三个月的开发时间,总工说无所谓。。。靠 

【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: 话说说个题外话,继电保护的市场竞争据说很激烈。。。成本是不是比较重要? 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 20:45:25 2012)  提到: 

可能我们主要是给自己的一次侧产品(也就是测量控制对象)做配套,所以对成本不敏感 

【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: 话说说个题外话,继电保护的市场竞争据说很激烈。。。成本是不是比较重要? 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sun Oct 28 20:45:56 2012)  提到: 

那看来是四方太穷。。接触他们的继电保护装置,他们的人说为了节省一个100多元的芯片,用纯软件实现了某通信协议。。 

【 在 leopardlee (MHY) 的大作中提到: 】 
: 还好吧 
: 我明确的说用STM32啥的,可以省100多的硬成本,还可以节省至少三个月的开发时间,总工说无所谓。。。靠 




☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sun Oct 28 20:47:47 2012)  提到: 

前面也有说,RT-Thread对ARM9也支持得很好。 

另外,RT-Thread是提供相对完整的POSIX接口(POSIX Thread, POSIX文件接口等)、 
BSD socket接口,所以即使使用RT-Thread,也很容易在RT-Thread与Linux间相互迁 
移。 

其实文件系统方面,我觉得RT-Thread是超越了ecos、RTEMS,因为在RT-Thread的官方 
发布中就包含了JFFS2、UFFS2、FAT、NFSv3的移植,由于许可证的原因未包含YAFFS2的 
移植(发布中带YAFFS2移植的patch)。 

然后还有个,ecos、RTEMS在驱动框架方面发展得相对慢,而RT-Thread目前已经支持了 
SDIO(可以用于连接SDIO WIFI),USB host/device stack。特别是USB host/device  
stack上,这两个老牌RTOS扯了数年都不能够完整支持,不是缺这就是缺那。 

【 在 leopardlee (MHY) 的大作中提到: 】 
: 谢谢谢谢 
: 好多细节我还在仔细计算 
: 看了你的网站,M4+RTT也是个好选择啊,呵呵 



☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sun Oct 28 20:50:55 2012)  提到: 

那你说的计算方法是? 

(1) 中断来临 --> (2) CPU响应第一条指令 --> (3) 用户中断服务例程 --> (4) 唤醒任 
务委托处理 --> (5) 脱离中断(退出中断) --> (6) 委托任务进行中断事务处理 

你指的是从哪里到哪里?我指的是从 1 --> 3。 

【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: 是这么计算的啊。。。那就是计算方法不同。。。 



☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sun Oct 28 20:53:30 2012)  提到: 

哈哈,如果你是选择Cortex-M,那么建议直接使用RT-Thread了 :-) 


【 在 leopardlee (MHY) 的大作中提到: 】 
: 还好吧 
: 我明确的说用STM32啥的,可以省100多的硬成本,还可以节省至少三个月的开发时间, 
总工说无所谓。。。靠 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 20:54:57 2012)  提到: 

赞 
我好好看看你的网站 
如果用这个的话,可以向你请教不? 

【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 前面也有说,RT-Thread对ARM9也支持得很好。 
: 另外,RT-Thread是提供相对完整的POSIX接口(POSIX Thread, POSIX文件接口等)、 
: BSD socket接口,所以即使使用RT-Thread,也很容易在RT-Thread与Linux间相互迁 
: ................... 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 20:56:01 2012)  提到: 

问题是总工非让用ARM9,保持平台的统一,唉 

我明天再劝劝:) 

【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 哈哈,如果你是选择Cortex-M,那么建议直接使用RT-Thread了 :-) 
: 总工说无所谓。。。靠 



☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sun Oct 28 20:56:49 2012)  提到: 

欢迎共同交流,开源社区需要这样的公开化交流。 


【 在 leopardlee (MHY) 的大作中提到: 】 
: 赞 
: 我好好看看你的网站 
: 如果用这个的话,可以向你请教不? 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 20:59:29 2012)  提到: 

好 

我现在还处在一切皆有可能的状态,计划下周五前决定用啥,甚至会再推迟一段时间,方向比干活重要啊 

【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 欢迎共同交流,开源社区需要这样的公开化交流。 



☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sun Oct 28 20:59:58 2012)  提到: 

RT-Thread支持包括ARM7TDMI、ARM9、ARM Cortex-M0/M3/M4, 
MIPS32、x86、blackfin、nios-ii、microblaze在内的数种CPU构架、数种芯片。 

不支持的包括 Aquamarine 他们的多核MIPS64 -_- 

【 在 leopardlee (MHY) 的大作中提到: 】 
: 问题是总工非让用ARM9,保持平台的统一,唉 
: 我明天再劝劝:) 


☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 21:03:42 2012)  提到: 

我这个东西但从性能上来说,430之类的都够用 

考虑性价比呢,STM32 LPC17XX最好 

但公司想统一平台,也不能说不对,呵呵 

【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: RT-Thread支持包括ARM7TDMI、ARM9、ARM Cortex-M0/M3/M4, 
: MIPS32、x86、blackfin、nios-ii、microblaze在内的数种CPU构架、数种芯片。 
: 不支持的包括 Aquamarine 他们的多核MIPS64 -_- 



☆─────────────────────────────────────☆ 
  
 About2Rain (狐说) 于  (Sun Oct 28 21:07:56 2012)  提到: 

如果是这样还比较靠谱 
我是担心就技术论技术 


【 在 leopardlee 的大作中提到: 】 
: 有2个电力行业的 
: 都是从VXWORKS转到linux上来的 
: 这两个是亲师兄,应该不会忽悠我 
: ................... 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Sun Oct 28 21:12:00 2012)  提到: 

但也对水平有一定要求,搞不好还要上RTLINUX补丁,技术压力也不小 

【 在 About2Rain (狐说) 的大作中提到: 】 
: 如果是这样还比较靠谱 
: 我是担心就技术论技术 



☆─────────────────────────────────────☆ 
  
 easyfish (晶鱼) 于  (Sun Oct 28 21:47:19 2012)  提到: 

电力行业也分很多种产品啊 
实时性需求都不一样 
【 在 leopardlee (MHY) 的大作中提到: 】 
: 有2个电力行业的 
: 都是从VXWORKS转到linux上来的 
: 这两个是亲师兄,应该不会忽悠我 
: ................... 



☆─────────────────────────────────────☆ 
  
 easyfish (晶鱼) 于  (Sun Oct 28 21:57:41 2012)  提到: 

为了生存问题不能支持多核心是什么意思? 
【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 有啥不能说的, 
: 不就为了生存问题不能支持多核心,MIPS64么 
: RT-Thread不是说只能支持CM3,ARM9当然也支持得很好,也有企业使用在产品上。在1.1.0 
: ................... 



☆─────────────────────────────────────☆ 
  
 fengsmth (欢迎挤上海地铁) 于  (Sun Oct 28 22:06:13 2012)  提到: 

小白,同求扫盲。 
【 在 easyfish (晶鱼) 的大作中提到: 】 
: 为了生存问题不能支持多核心是什么意思? 



☆─────────────────────────────────────☆ 
  
 easyfish (晶鱼) 于  (Sun Oct 28 22:24:53 2012)  提到: 

eCos确实是没有usb host的协议支持。 

看了你前面很多文章,相当内行。 

原来是RT-Thread的创始人,景仰一下。 
之前对RTT了解不多,一会就在进版画面上加上。 

另外,许继的保护装置准备用RTT了? 

【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 前面也有说,RT-Thread对ARM9也支持得很好。 
: 另外,RT-Thread是提供相对完整的POSIX接口(POSIX Thread, POSIX文件接口等)、 
: BSD socket接口,所以即使使用RT-Thread,也很容易在RT-Thread与Linux间相互迁 
: ................... 



☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sun Oct 28 23:02:02 2012)  提到: 

@Aquamarine 刘总来解释下吧 

【 在 easyfish (晶鱼) 的大作中提到: 】 
: 为了生存问题不能支持多核心是什么意思? 


☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Sun Oct 28 23:03:17 2012)  提到: 

许继是一个大集团, 
其中有两个公司使用了RT-Thread,都是和电力相关的。 

【 在 easyfish (晶鱼) 的大作中提到: 】 
: eCos确实是没有usb host的协议支持。 
: 看了你前面很多文章,相当内行。 
: 原来是RT-Thread的创始人,景仰一下。 
: ................... 



☆─────────────────────────────────────☆ 
  
 starts (不死鸟) 于  (Sun Oct 28 23:08:23 2012)  提到: 

我本来也想说20ms算不上什么实时要求的. 不过怕被人抬杠, 没敢说 
【 在 Ylong (沧海云龙) 的大作中提到: 】 
: 所谓的Linux不支持实时,是指的用户态还是核心态啊? 
: 如果指的核心态的话,那么多高速硬件设备是怎么跑的呢? 
: 不过20ms也算不上实时要求 



☆─────────────────────────────────────☆ 
  
 EuroPad (好奇的中年 | 不断的犯错,又不断的远离) 于  (Sun Oct 28 23:50:28 2012)  提到: 


        关注 

【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 标  题: Re: 关于操作系统的选择,闹心,大牛给点指点吧 
: 发信站: 水木社区 (Sun Oct 28 23:02:02 2012), 站内 
:  
: @Aquamarine 刘总来解释下吧 
:  
: 【 在 easyfish (晶鱼) 的大作中提到: 】 
: : 为了生存问题不能支持多核心是什么意思? 
: -- 
: - http://www.rt-thread.org 
: RT-Thread启动下一代实时操作系统的演化... 
:  
:  
※ 来源:·水木社区 http://newsmth.net·[FROM: 180.172.76.*] 




☆─────────────────────────────────────☆ 
  
 Bonaparte (苍天) 于  (Mon Oct 29 00:27:06 2012)  提到: 


本来有确定期限的都是实时,你能保证Linux在繁重任务下依旧能正确采集 
20ms间隔的信号? 

【 在 starts (不死鸟) 的大作中提到: 】 
: 我本来也想说20ms算不上什么实时要求的. 不过怕被人抬杠, 没敢说 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Mon Oct 29 11:14:07 2012)  提到: 


刚才和领导汇报了下 

竟然同意用正版VXWORKS了。。。。。。 


谢谢各位了,虽然没用成LINUX(包括rtlinux,rtai等实时改造),rtems,rtt等等,但真的学了不少东西,再次感谢 


【 在 leopardlee (MHY) 的大作中提到: 】 
: 做个控制的项目 
: 平台必须是ARM9(领导定的),因为对实时性有所要求,对系统的选择有点难产了 
: VXWORKS  初始授权30万左右,我刚来这个公司,估计很难批下来;如果用盗版,且不说源码&资料不好搞,最重要是未来可能会有官司,现在WINDRIVER查的很严 
: ................... 



☆─────────────────────────────────────☆ 
  
 wukuan (从地狱到天堂) 于  (Mon Oct 29 13:06:33 2012)  提到: 

哈,我第一感觉也是,控制到20ms应该还算好吧,注意一下任务的负荷有没有极端情况。 

【 在 starts (不死鸟) 的大作中提到: 】 
: 我本来也想说20ms算不上什么实时要求的. 不过怕被人抬杠, 没敢说 




☆─────────────────────────────────────☆ 
  
 cppgx (s# 巛) 于  (Mon Oct 29 16:57:25 2012)  提到: 

嗯,一时还真懵住了,想不出来楼长是干什么的。 

40ms这要求不高不低,两个周期。 

【 在 easyfish (晶鱼) 的大作中提到: 】 
: 电力行业也分很多种产品啊 
: 实时性需求都不一样 




☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Mon Oct 29 17:32:30 2012)  提到: 

当时我这个写的有些模糊 

是说从采样 计算 到最后继电器动作共计40ms内 

实际最低要求在500us左右 

【 在 cppgx (s# 巛) 的大作中提到: 】 
: 嗯,一时还真懵住了,想不出来楼长是干什么的。 
: 40ms这要求不高不低,两个周期。 



☆─────────────────────────────────────☆ 
  
 dormouseBHU (dormouseBHU) 于  (Mon Oct 29 20:28:41 2012)  提到: 

同关注 

【 在 EuroPad 的大作中提到: 】 
: 关注 



☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Tue Oct 30 13:33:17 2012)  提到: 

500us,如果真按照你原始说的30ms,估计到最后会郁闷得一塌糊涂 

【 在 leopardlee (MHY) 的大作中提到: 】 
: 当时我这个写的有些模糊 
: 是说从采样 计算 到最后继电器动作共计40ms内 
: 实际最低要求在500us左右 



☆─────────────────────────────────────☆ 
  
 leopardlee (MHY) 于  (Tue Oct 30 13:56:38 2012)  提到: 

嗯 
开始说的太泛泛了,误导了大家@@ 

等我搞定VXWORKS&项目,一定用一下RTT,给国产做点贡献 

【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 500us,如果真按照你原始说的30ms,估计到最后会郁闷得一塌糊涂 



☆─────────────────────────────────────☆ 
  
 ffxz (非飞·奋发中) 于  (Tue Oct 30 15:06:13 2012)  提到: 

都这么关注啊, 

本想让Aquamarine说说的,看来他还是有些事情不想说,那么这里就大致说说吧,  
Aquamarine就职于国内做多核MIPS64芯片的*企业单位,他们有RTOS的需求。 

可是呢,对于多核心的RTOS并没那么简单,特别还是苛刻的实时要求时就更不简单了。想 
让RT-Thread能够支持多核心64位MIPS处理器,显然还需要大量的工作要做,从64位的 
MIPS,到多核心的CPU调度算法等等,在无资金的情况下这个精力暂时投不起,投不下去 
(RT-Thread Developer也是人,不是只做research而不吃饭)。 

【 在 dormouseBHU (dormouseBHU) 的大作中提到: 】 
: 同关注 
: : 



☆─────────────────────────────────────☆ 
  
 easyfish (晶鱼) 于  (Tue Oct 30 18:27:22 2012)  提到: 

哦,是难度的问题,还以为是有黑幕遭遇不公正待遇了呢,那没什么不能说的啊 

多核MIPS64*企业单位,龙芯? 
【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 都这么关注啊, 
: 本想让Aquamarine说说的,看来他还是有些事情不想说,那么这里就大致说说吧,  
: Aquamarine就职于国内做多核MIPS64芯片的*企业单位,他们有RTOS的需求。 
: ................... 



☆─────────────────────────────────────☆ 
  
 happymarried (fibbit) 于  (Sat Nov  3 21:52:10 2012)  提到: 

profibus? 
【 在 nuptguizi (此人白字容) 的大作中提到: 】 
: 标  题: Re: 关于操作系统的选择,闹心,大牛给点指点吧 
: 发信站: 水木社区 (Sun Oct 28 20:45:56 2012), 站内 
:  
: 那看来是四方太穷。。接触他们的继电保护装置,他们的人说为了节省一个100多元的芯片,用纯软件实现了某通信协议。。 
:  
: 【 在 leopardlee (MHY) 的大作中提到: 】 
: : 还好吧 
: : 我明确的说用STM32啥的,可以省100多的硬成本,还可以节省至少三个月的开发时间,总工说无所谓。。。靠 
:  
:  
: -- 
:  
※ 来源:·水木社区 newsmth.net·[FROM: 118.26.190.*] 




☆─────────────────────────────────────☆ 
  
 lester98 (奶瓶) 于  (Sat Nov  3 23:13:20 2012)  提到: 

景仰一下大牛. 
真想忽悠公司在后面的龙芯芯片里用RTT了.同时搭配我现在搞的Linux,做一套高低端兼容的跨平台跨OS的软件平台出来. 
【 在 ffxz (非飞·奋发中) 的大作中提到: 】 
: 都这么关注啊, 
: 本想让Aquamarine说说的,看来他还是有些事情不想说,那么这里就大致说说吧,  
: Aquamarine就职于国内做多核MIPS64芯片的*企业单位,他们有RTOS的需求。 
: ................... 



☆─────────────────────────────────────☆ 
  
 nuptguizi (此人白字容) 于  (Sat Nov  3 23:27:22 2012)  提到: 

呵呵。行家。是的。 

【 在 happymarried (fibbit) 的大作中提到: 】 
: profibus? 





luck851 Re: [合集] 关于操作系统的选择,闹心,大牛给点指点吧 2012-11-05 21:48:33
发信人: luck851 (luck851), 信区: Embedded 
标  题: Re: [合集] 关于操作系统的选择,闹心,大牛给点指点吧 
发信站: 水木社区 (Mon Nov  5 21:48:33 2012), 站内 

rt-linux已经被风河收购现在是商用的,免费的硬实时的只要rtai和xenomai,其实这三个原理都一样,我现在在做mpc8377(powerpc)下的xenomai移植和驱动开发(实时驱动RTDM),我测试的xenomai的实时型还是不错的,中断延时大部分在1US左右,最大的中断延时不到5us(1亿次中断),实时任务调度应用层直接调度误差在十几微妙,要结合驱动用硬件定时器调度误差能到2us左右。 
-- 

※ 来源:·水木社区 http://newsmth.net·[FROM: 61.50.131.*] 

leopardlee Re: [合集] 关于操作系统的选择,闹心,大牛给点指点吧 2012-11-07 11:48:30
发信人: leopardlee (MHY), 信区: Embedded 
标  题: Re: [合集] 关于操作系统的选择,闹心,大牛给点指点吧 
发信站: 水木社区 (Wed Nov  7 11:48:30 2012), 站内 

Re 
感谢 
【 在 luck851 (luck851) 的大作中提到: 】 
: rt-linux已经被风河收购现在是商用的,免费的硬实时的只要rtai和xenomai,其实这三个原理都一样,我现在在做mpc8377(powerpc)下的xenomai移植和驱动开发(实时驱动RTDM),我测试的xenomai的实时型还是不错的,中断延时大部分在1US左右,最大的中断延时不到5us(1亿次中断),实时任务调度应用层直接调度误差在十几微妙,要结合驱动用硬件定时器调度误差能到2us左右。 

-- 

※ 来源:·水木社区 http://newsmth.net·[FROM: 114.253.103.*]