嵌入式os的选择

原文地址：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.*]