看看,跟freertos比怎样?

和FreeRTOS相比，核心实现的功能是差不多的

如果扩展开一些，RT-Thread开发中的版本能够支持动态模块加载，虚拟文件系统，GUI。这些是FreeRTOS所不具备的，但RTOS本身就是一个可定制非常高的系统，所以虽然RT-Thread外围有一些组件，但并不一定就非得使用。

转的别人的ucos vs freertos
==========================
FreeRTOS 和uC/OS-II的简单比较
http://www.stmfans.com/bbs/viewthread.php?tid=2512&highlight=freertos
这是两种RTOS, 现在粗略比较一下。
freeRTOS比uCOS II优胜的地方：
1。内核ROM和耗费RAM都比uCOS 小，特别是RAM。 这在单片机里面是稀缺资源，uCOS至少要5K以上， 而freeOS用2~3K也可以跑的很好。
2。freeRTOS 可以用协程（Co-routine），减少RAM消耗（共用STACK）。uCOS只能用任务（TASK，每个任务有一个独立的STACK）。
3。freeRTOS 可以有优先度一样的任务，这些任务是按时间片来轮流处理，uCOSII 每个任务都只有一个独一无二的优先级。因此，理论上讲，freeRTOS 可以管理超过64个任务，而uCOS只能管理64个。
4。freeRTOS 是在商业上免费应用。uCOS在商业上的应用是要付钱的。
freeRTOS 不如uCOS的地方：
1。比uSOS简单，任务间通讯freeRTOS只支持Queque， Semaphores， Mutex。 uCOS除这些外，还支持Flag, MailBox.
2。uCOS的支持比freeRTOS 多。除操作系统外，freeRTOS只支持TCPIP， uCOS则有大量外延支持，比如FS， USB， GUI， CAN等的支持
3。uCOS可靠性更高，而且耐优化，freeRTOS 在我设置成中等优化的时候，就会出问题。

我以前写的比较说明：
===================
对FreeRTOS一直不是太了解，看到这份帖子，正好也可以比较下RT-Thread的情况：

接上面的文章，
1、RAM，ROM情况
RT-Thread，最小型配置，～ 8K ROM，～ 3K RAM
但32位以外的单片机没试过，不知道是否还有可优化的地方

2、RT-Thread只能使用线程方式的任务，需要为每个不同的线程开辟相应的栈空间，一个线程的控制块代价是128字节

3、RT-Thread也能够使用优先级相同的线程，优先级相同的线程按照时间片轮转进行调度

4、RT-Thread同样是免费的，并在0.2.4版本以后提供免费的技术支持(仅包括内核、移植、相关的组件)！

文中说的不如的地方，
1、RT-Thread提供完整的任务间通信机制，semaphore，mutex，mailbox，message queue，event（类似ucos中的flag）
和商业实时操作系统NucluesPlus相比，缺少pipe、signal的支持。也缺少NucluesPlus中的HISR支持。

2、RT-Thread目前只能提供有限的组件支持，0.2.4版包括TCP/IP和finsh shell。0.3.0版中包括 filesystem和GUI --> 下一步0.3.0马上就要开始进入beta发布周期了，文件系统和GUI的代码也很快逐步和大家见面。动态模块加载应该也是在0.3.x系列版本中和大家见面。

3、RT-Thread的可靠性显然还没ucos高，但用得多了可靠性也会慢慢提升上去，报出了的bug我们会及时修正。

ffxz,你是参与RT-Thread设计的吗？呵呵，能否将你移植到STM32上的代码发一份给我呢？就是对NANDFLASH的文件系统那个。谢谢哈，还有有RT-Thread的简介呀什么的，看你说得哪么好，也想看看。qinshi198612@163.com

RT-Thread和NucleusPlus的比较
任务调度
NU+ 全抢占式调度，256优先级，相同优先级时间片轮转调度，隐含idle任务，能动态创建/删除任务
RTT 全抢占式调度，256优先级，相同优先级时间片轮转调度，显式idle任务(因为是显式的，需要分配一些栈空间)，能动态创建/删除任务(应该说更为彻底，栈空间和TCB占用空间都会被自动释放)
内存管理
NU+ 支持分区内存管理
RTT 支持静态内存池管理
这个实质上是一个东西，不同的实现罢了
NU+ 支持动态内存管理，如本篇文章开始所说，它的算法是很有缺陷的！
RTT 支持小内存管理及大内存SLAB算法管理
任务间通信
邮箱
NU+ 16字节固定大小信件支持，发送操作带SUSPEND标识(及如果邮箱中已经有邮件，调用线程会被挂起)
RTT 4字节固定大小信件支持，信件多少由创建时决定
队列
NU+ 4字节对齐不固定大小消息支持，发送操作带SUSPEND标识(及如果队列已满，调用线程会被挂起)
RTT 非对齐、不固定大小消息支持
管道
NU+ 非对齐、不固定大小消息支持，发送操作带SUSPEND标识(及如果队列已满，调用线程会被挂起)
RTT 无
信号量
NU+ 优先级翻转支持(?有些不确定)
RTT 无优先级翻转保护
Mutex
NU+ 无
RTT 优先级继承方式以防止优先级翻转的情况发生
Event
NU+ 支持
RTT 支持
Signal
NU+ 支持(也称为异步事件)
RTT 无
HISR
这个是NucleusPlus中比较特殊的一种机制，在NU+中，中断服务例程(NU+称之为LISR)是基本不允许使用OS的组件，而是激活一个HISR 作为代理来处理。HISR是不允许被阻塞(允许被另一个更高优先级的HISR抢占或被LISR打断)，但可以发送一些消息或事件给其他任务。
RT- Thread中相对应的，在中断服务例程中允许使用OS中一些非阻塞的调用，同样它也不会被阻塞。如果要实现类似NU+的HISR，也可以在系统中创建一些超高优先级的线程，例如优先级为0 - 8的线程，那么在中断服务例程中发生消息或事件过去，在离开中断服务例程后肯定会执行到这些高优先级的线程。当然这个会有些伪，因为它们依然是允许被阻塞的。

引用第 20 楼 qinshi1208于2009-04-30 01:01:08发表:
ffxz,你是参与RT-Thread设计的吗？呵呵，能否将你移植到STM32上的代码发一份给我呢？就是对NANDFLASH的文件系统那个。谢谢哈，还有有RT-Thread的简介呀什么的，看你说得哪么好，也想看看。qinshi198612@163.com 


我没说过我已经完成了NandFlash文件系统的开发啊，我上面提问问大家一般在NandFlash上用什么文件系统，但没人回答我。我们是计划移植YAFFS2到RT-Thread中，因为RT-Thread中包含了虚拟文件系统层，它就类似于Linux一样可以让多种不同介质上的多种不同文件系统和平相处。
 
另外如果移植YAFFS2，20k SRAM的STM32肯定是跑不起来的，至少需要64k SRAM的STM3F103Z系列。不过既然有了NandFlash，也应该是Z系列了，20k SRAM的STM32还没外接的接口。
 
RT-Thread的大本营在http://www.rt-thread.org 您可以在上面获得更多的资料文档。

收一个来试试再说

看看再说，支持国产！！

好下载下来看一看.

谢谢 先拿回去慢慢看

顶一顶！

今晚http://www.rt-thread.org 主站将发布RT-Thread/STM32F103VB 0.3.0 beta3版本了，一个历程碑的发布。

呵呵，学习先

从来没用过操作系统，如果能用在新产品上，可以说服公司给点赞助，毕竟是国产。
给我来一份儿ZET6的系统，ground@vip.163.com
先谢了。
（估计是第一个吃螃蟹的人。。。。。。）