起初RT-Thread是一个实时的内核(全抢占优先级调度，调度器时间复杂度O(1))，但在发展过程中，RT-Thread实时操作系统得到了来自全国嵌入式开发工程师的鼎力支持，为RT-Thread添砖加瓦，现在它不仅仅是一款高效、稳定的实时核心，也是一套面向嵌入式系统的软件平台，覆盖了全抢占的实时操作系统内核，小巧而与底层具体实现无关的文件系统，轻型的TCP/IP协议栈以及轻型的多窗口多线程图形用户界面。
RT-Thread是一个平台，您可以把您的创意汇聚在一起，小平台大社区，RT-Thread的开发人员就在您的身边。
- 中文名
- RT-Thread RTOS
- 性 质
- 开源实时操作系统
- 开发者
- RT-Thread工作室
- 时 间
- 2006年上半年
开发者自述
1、诞生
一切东西还得从头谈起。
RT-Thread RTOS，Kernel部分完成于2006年上半年，其IPC部分甚至是年中时才具备相应的雏形。最开始时是因为要为朋友做一个小型的手持设备，而我本人起初又是另一国内老牌RTOS：DOOLOO RTOS开发人员，但这个团队在2005年底已经解散。但朋友的系统要上，用ucos吗，一不熟悉，二看不上。答应朋友的事，总得有解决方法吧，即使是原来的DOOLOO RTOS，因为其仿VxWorks结构，导致它的核心太大，包括太多不必要的东西（一套完整的libc库），这些方案都否决了。怎么办？当时朋友那边也不算太急，先自己写一套内核吧。这个就是源头！（后来虽然朋友的项目夭折了，但这套OS则保留下来了，并开源了，万幸）
当然RT-Thread和原来的DOOLOO RTOS差别还是很大的。DOOLOO RTOS是一种类VxWorks风格的，而RT-Thread则是一种类NucluesPlus风格的，小型、实时、可剪裁。这三个方面RT-Thread可以骄傲的说做得比DOOLOO RTOS都要好很多，小型：RT-Thread核心能够小到4K ROM，1K RAM；实时：线程调度核心是完全bitmap方式，计算时间是完全固定的；可剪裁性，配置文件rtconfig.h包含多种选项，对Kernel细节进行精细调整，对各种组件（文件系统，使用EFSL、ELM FatFs；网络协议栈，finsh shell）进行可选配置。
2、艰难的发展期
在第一个公开板发布后（0.1），RT-Thread意识到了一个问题，光有核心不行。别人如何使用：虽然采用了doxygen风格的注释，并自动产生相应的API文档，但能够使用的人寥寥，有这个功底的人不见得认可你的系统，没相应功底的人也玩不转你的系统。所以下一个系列，考虑如何让系统能够支持更多的平台。首选ARM，为什么？应为ARM正处于发展的前期，使用的人也广泛，而RT-Thread第一个支持的平台就是s3c4510，这个是lumit开源项目赠送的平台。在其后，支持了包括s3c44b0，AT91SAM7S64，AT91SAM7X256，s3c2410，AT91SAM9200，coldfire，x86等一系列平台，编译器统一使用GCC，这个时期无疑是最艰难的时期（真的艰难吗？呵呵，但肯定是迷茫的），这个就是0.2.0、0.2.1、0.2.3、0.2.4版本等，不同的版本支持不同的平台。
猜猜我这段时间是干什么工作的？不知道大家对这个领域是否熟悉，手机2G，3G协议栈开发。每天都和协议栈打交道，而且最痛苦的是上千页的25.331 RRC协议，都是英文的，所以RT-Thread算做是工作之外的苦中作乐吧。而也正是这个时候，shaolin同学出现了，帮助完成了RT-Thread/x86的移植，他当时还是学生。
这其中还有一件郁闷的事，当时RT-Thread团队还有几个人，只不过主要是shaolin和我。当0.2.3发布时，我建议开始微内核的道路，嗯，可能很多人还比较困惑，RT-Thread后面跟着的为什么是“启动下一代RTOS演化”，当时就是因它而感慨：把微内核引入进来，把内核态和用户态分开来，并且建立一个类似于L4的微内核。当然最重要的是，其中有一个强实时核心。而且L4实际上是把页表操作放到内核之外的，如果内核是一个强实时内核将对整个系统的实时性提升很大，而因为微内核的缘故，也能够运行linux的应用程序，并且当时RT-Thread也提出了一种，线程即IPC的概念。。。只是，最后的提案被大家否决了。团队开始有数人，只是能够坚持的没几个。
3、一年增加0.0.1
本人很早就接触了Linux，算是国内资深的Linux接触者（早期也算一个Linux开发人员吧），KDE 1.0几乎是看着发展起来的（大家有谁用过RedHat 5.1？）。个人算是很多方面有一些自由软件的习惯：软件的版本号是非常重要的一个标志，宁愿增加一个细微的版本号也不轻易的增加一个大的版本号，因为大的版本号是需要对用户负责的。1.0版本更代表了系统的稳定性，健全性。例如mplayer到1.0版本就经历众多小版本，0.99的beta版本亦无数。
RT-Thread也把这点体现得淋漓尽致，0.2.2到0.2.3一个版本的增加，整整花了一年多的时间。但这个小版本号的增加，却带来了开源社区嵌入式环境中最完善的TCP/IP协议栈：LwIP。当然，开始时并不算稳定。在这几个版本中，RT-Thread也终于从迷茫中走出来，RT-Thread需要自己的特色，一个单独的RTOS Kernel没太大的用处，因为你并没有上层应用代码的积累，并且一些基础组件也非常重要，有这些基础组件基本上意味着，在这个平台上写代码，这些代码就是你的，甚至是你哪天也可以把它放到另外一个硬件平台上运行。
同样，0.2到0.3版本号的变更，花费的时间会更长^-^ 版本号的长短，是和计划的feature实现是密切相关的，没到设定的目标如何可能进行发布呢？
4、Cortex-M3的变革
RT-Thread的变革因为Cortex-M3而来，因为ST的STM32使用的人太广了，当然还有非常重要的一点。RT-Thread已经开始支持Keil MDK，armcc了。GNU GCC确实好，并且也由衷的推崇它，使用它，只是调试确实麻烦，阻碍了更多人使用它（ARM平台上）。当RT-Thread + Cortex-M3 + Keil MDK碰撞在一起的时候，火花因它而生，越来越多人使用RT-Thread了，当然这和RT-Thread厚积薄发是离不开的，因为这个时候，RT-Thread已经有一个稳定的内核，shell方式的调试利器finsh，DFS虚拟设备文件系统，以及LwIP协议栈。而RT-Thread/GUI则在密集的移植到CM3上，RT-Thread/GUI成型于2008年底，但为了Cortex-M3分支，这个组件停下来很多，但这种停留是值得的。另外就是特别感谢UET赠送的STM32开发板了，RT-Thread/STM32的分支都是在UET赠送的STM32开发板上验证的。
5、RT-Thread为什么是对象化的设计方法
可能这个话题太偏技术化了，说说其他，呵呵。
面向对象编程有它的好处，例如继承。可以让具备相同父类的子类共享使用父类的方法，基本可以说是不用写代码就凭空多出了很多函数，何乐而不为呢。另外，对象的好处在于封装。当一个对象封装好了以后，并测试完成后，基本上就代表这个类是健全的，从这个类派生的子类不需要过多考虑父类的不稳定性。
这里着重提提另外一个人，我工作后的第三年，曾向当时的同事也是好友，L.Huray学习面向对象的实时设计方法：Octpus II。深刻体会到了面向对象设计的好处（需求分析，体系结构设计，子系统分析，子系统设计，测试，实时性分析），但鉴于嵌入式系统中C++的不确定性，所以个人更偏向于使用C来实现。所以，L.Huray算是我的老师了，一直希望能够有时间把他老人家的思想更进一步的发扬光大，希望以后有这个机会。（Octpus I最初起源于Nokia，然后由M.Award, L.Huray发展成Octpus II，现在几乎见不到踪影了，唉）。
RT-Thread RTOS，Kernel部分完成于2006年上半年，其IPC部分甚至是年中时才具备相应的雏形。最开始时是因为要为朋友做一个小型的手持设备，而我本人起初又是另一国内老牌RTOS：DOOLOO RTOS开发人员，但这个团队在2005年底已经解散。但朋友的系统要上，用ucos吗，一不熟悉，二看不上。答应朋友的事，总得有解决方法吧，即使是原来的DOOLOO RTOS，因为其仿VxWorks结构，导致它的核心太大，包括太多不必要的东西（一套完整的libc库），这些方案都否决了。怎么办？当时朋友那边也不算太急，先自己写一套内核吧。这个就是源头！（后来虽然朋友的项目夭折了，但这套OS则保留下来了，并开源了，万幸）
当然RT-Thread和原来的DOOLOO RTOS差别还是很大的。DOOLOO RTOS是一种类VxWorks风格的，而RT-Thread则是一种类NucluesPlus风格的，小型、实时、可剪裁。这三个方面RT-Thread可以骄傲的说做得比DOOLOO RTOS都要好很多，小型：RT-Thread核心能够小到4K ROM，1K RAM；实时：线程调度核心是完全bitmap方式，计算时间是完全固定的；可剪裁性，配置文件rtconfig.h包含多种选项，对Kernel细节进行精细调整，对各种组件（文件系统，使用EFSL、ELM FatFs；网络协议栈，finsh shell）进行可选配置。
2、艰难的发展期
在第一个公开板发布后（0.1），RT-Thread意识到了一个问题，光有核心不行。别人如何使用：虽然采用了doxygen风格的注释，并自动产生相应的API文档，但能够使用的人寥寥，有这个功底的人不见得认可你的系统，没相应功底的人也玩不转你的系统。所以下一个系列，考虑如何让系统能够支持更多的平台。首选ARM，为什么？应为ARM正处于发展的前期，使用的人也广泛，而RT-Thread第一个支持的平台就是s3c4510，这个是lumit开源项目赠送的平台。在其后，支持了包括s3c44b0，AT91SAM7S64，AT91SAM7X256，s3c2410，AT91SAM9200，coldfire，x86等一系列平台，编译器统一使用GCC，这个时期无疑是最艰难的时期（真的艰难吗？呵呵，但肯定是迷茫的），这个就是0.2.0、0.2.1、0.2.3、0.2.4版本等，不同的版本支持不同的平台。
猜猜我这段时间是干什么工作的？不知道大家对这个领域是否熟悉，手机2G，3G协议栈开发。每天都和协议栈打交道，而且最痛苦的是上千页的25.331 RRC协议，都是英文的，所以RT-Thread算做是工作之外的苦中作乐吧。而也正是这个时候，shaolin同学出现了，帮助完成了RT-Thread/x86的移植，他当时还是学生。
这其中还有一件郁闷的事，当时RT-Thread团队还有几个人，只不过主要是shaolin和我。当0.2.3发布时，我建议开始微内核的道路，嗯，可能很多人还比较困惑，RT-Thread后面跟着的为什么是“启动下一代RTOS演化”，当时就是因它而感慨：把微内核引入进来，把内核态和用户态分开来，并且建立一个类似于L4的微内核。当然最重要的是，其中有一个强实时核心。而且L4实际上是把页表操作放到内核之外的，如果内核是一个强实时内核将对整个系统的实时性提升很大，而因为微内核的缘故，也能够运行linux的应用程序，并且当时RT-Thread也提出了一种，线程即IPC的概念。。。只是，最后的提案被大家否决了。团队开始有数人，只是能够坚持的没几个。
3、一年增加0.0.1
本人很早就接触了Linux，算是国内资深的Linux接触者（早期也算一个Linux开发人员吧），KDE 1.0几乎是看着发展起来的（大家有谁用过RedHat 5.1？）。个人算是很多方面有一些自由软件的习惯：软件的版本号是非常重要的一个标志，宁愿增加一个细微的版本号也不轻易的增加一个大的版本号，因为大的版本号是需要对用户负责的。1.0版本更代表了系统的稳定性，健全性。例如mplayer到1.0版本就经历众多小版本，0.99的beta版本亦无数。
RT-Thread也把这点体现得淋漓尽致，0.2.2到0.2.3一个版本的增加，整整花了一年多的时间。但这个小版本号的增加，却带来了开源社区嵌入式环境中最完善的TCP/IP协议栈：LwIP。当然，开始时并不算稳定。在这几个版本中，RT-Thread也终于从迷茫中走出来，RT-Thread需要自己的特色，一个单独的RTOS Kernel没太大的用处，因为你并没有上层应用代码的积累，并且一些基础组件也非常重要，有这些基础组件基本上意味着，在这个平台上写代码，这些代码就是你的，甚至是你哪天也可以把它放到另外一个硬件平台上运行。
同样，0.2到0.3版本号的变更，花费的时间会更长^-^ 版本号的长短，是和计划的feature实现是密切相关的，没到设定的目标如何可能进行发布呢？
4、Cortex-M3的变革
RT-Thread的变革因为Cortex-M3而来，因为ST的STM32使用的人太广了，当然还有非常重要的一点。RT-Thread已经开始支持Keil MDK，armcc了。GNU GCC确实好，并且也由衷的推崇它，使用它，只是调试确实麻烦，阻碍了更多人使用它（ARM平台上）。当RT-Thread + Cortex-M3 + Keil MDK碰撞在一起的时候，火花因它而生，越来越多人使用RT-Thread了，当然这和RT-Thread厚积薄发是离不开的，因为这个时候，RT-Thread已经有一个稳定的内核，shell方式的调试利器finsh，DFS虚拟设备文件系统，以及LwIP协议栈。而RT-Thread/GUI则在密集的移植到CM3上，RT-Thread/GUI成型于2008年底，但为了Cortex-M3分支，这个组件停下来很多，但这种停留是值得的。另外就是特别感谢UET赠送的STM32开发板了，RT-Thread/STM32的分支都是在UET赠送的STM32开发板上验证的。
5、RT-Thread为什么是对象化的设计方法
可能这个话题太偏技术化了，说说其他，呵呵。
面向对象编程有它的好处，例如继承。可以让具备相同父类的子类共享使用父类的方法，基本可以说是不用写代码就凭空多出了很多函数，何乐而不为呢。另外，对象的好处在于封装。当一个对象封装好了以后，并测试完成后，基本上就代表这个类是健全的，从这个类派生的子类不需要过多考虑父类的不稳定性。
这里着重提提另外一个人，我工作后的第三年，曾向当时的同事也是好友，L.Huray学习面向对象的实时设计方法：Octpus II。深刻体会到了面向对象设计的好处（需求分析，体系结构设计，子系统分析，子系统设计，测试，实时性分析），但鉴于嵌入式系统中C++的不确定性，所以个人更偏向于使用C来实现。所以，L.Huray算是我的老师了，一直希望能够有时间把他老人家的思想更进一步的发扬光大，希望以后有这个机会。（Octpus I最初起源于Nokia，然后由M.Award, L.Huray发展成Octpus II，现在几乎见不到踪影了，唉）。
（作者原文：实时线程操作系统（RT-Thread）4年开发历程 乐与苦）
简单比较
1 、任务管理及调度：
uCOS - 256优先级抢占式调度，不允许相同优先级任务存在
2、 同步/通信机制：
uCOS -semaphore,mutex, mailbox, message queue, event。mailbox只能存放1条消息
3、内存管理：
uCOS - 固定大小内存块管理
4、定时器：
RT-Thread - 挂接到系统OS定时器的硬定时器
uCOS - 只能使用OSTimeDly进行时间间隔处理
5、中断嵌套：
RT-Thread - 允许
uCOS - 允许
6、源码许可证：
RT-Thread - 遵循GPLv2+许可证。可用于商业产品（只需要注明使用了RT-Thread）
uCOS - 商业收费
版本发布
发布时间：11/04/2014
RT-Thread 2.0.0发布候选版本（release candidate），同时发布v1.2.3稳定版本
随着RT-Thread功能越来越多，如何发布版本也成为一件头疼的事情，因为需要仔细对比最近三个月来的修改记录。这次的发布距离上一次beta版本依然是三个月的时间，但按照发布计划已然推迟了一个月进行发布。
在这三个月中，开源社区上也发生了很多有趣的事情：
- RT-Thread做为一个开源组织参与的CSDN开源夏令营结出了丰硕的果实：
- 由hduffddybz参与的IPv6协议栈移植（最新版本的lwIP-head版本移植）在这次发布中已经包括进来，从而能够在使用RT-Thread的小型设备上实现TCP/IP v4/v6双栈的支持；
- 由wzyy2参与的GDB stub实现，也完美的支持BeagleBoneBlack开发板和STM32F4平台；
当前智能化设备是一个备受关注的领域，针对这一领域的特点，RT-Thread也相应的做出了积极的响应，所以这个版本开始加入sensor的应用框架（APP/算法 <--> sensor framework <--> RT-Thread device driver <--> 硬件外设）。希望在小型化的RT-Thread操作系统基础上融合智能化相关的技术，让RT-Thread成为这方面可选的OS系统之一。RT-Thread操作系统的sensor框架也尝试新的实现方式，即采用C++的方式来实现（当然也会考虑C方面的兼容，无疑C++的面向对象特性会更好，所以最终选择了C++），在这个基础上也可能融合其他的一些生态技术，例如ARM mbed平台上的一些社区组件技术。所以这个发布版本中既包括sensor框架，也包括了C++底层的一些基础支撑。
这个版本是RT-Thread 2.0.0系列正式版本的候选版本，正式版本预计会在年底正式发布，距离正式版本还会加入更完善的一些支撑（例如各种传感器驱动）。也计划2014年11月22日，在上海浦东举行RT-Thread嵌入式系统沙龙活动，欢迎大家关注并参与进行RT-Thread方方面面的技术交流。具体时间、地点再另行通知，欢迎关注 @RT-Thread 微博获得最新的消息。
背景成长
记录下RT-Thread0.3.x的成长
先解释几个常见问题：
1. RT-Thread从哪里而来？
RT-Thread RTOS，Kernel部分完成于2006年上半年，创始人源于国内一老牌RTOS：DOOLOO RTOS，甚至是BSP 一些结构都源于DOOLOO RTOS。但与DOOLOO RTOS明显不同的是，Kernel完全重新编写，突出的是实时性和小而灵活，并且引入了内核 的对象模型以摒弃内核对象的与动态内存管理器无关化。
2. RT-Thread用于商业产品&工程，版权如何界定？
RT-Thread RTOS内核部分完全由我们编写，无其他版权问题，可以放心在商业产品 & 工程中使用。对于把RT-Thread使用于商业产品中，我们承诺永久不收费（使用人拥有使用权，使用用途责任请自行承担）。另外有两点需要注意：
- RT-Thread RTOS代码原始版权属于RT-Thread所有。
- 在商业产品 & 工程中使用RT-Thread RTOS，请在产品说明书上明确说明使用了RT-Thread，如有串口输出，请在系统启动显示RT-Thread的版本信息。如使用了RT-Thread RTGUI，请保留RT-Thread LOGO。
3. RT-Thread RTOS由谁开发，由谁维护？
目前RT-Thread RTOS由国内RT-Thread工作室开发及维护
4. RT-Thread RTOS是否已经在产品中使用？稳定度 & BUG情况如何？
目前已经有数家公司使用RT-Thread RTOS做为他们的系统平台，在上面进行产品开发，稳定性表现不错。
就如同没有100%的完美事物一样，BUG是存在的，反馈上来我们会努力尽快修正。
5. 我能加入到RT-Thread的开发者队伍中吗？
能！
我们欢迎任何对RTOS感兴趣的人，不管你是学生或资深嵌入式系统开发工程师。RT-Thread的开发人员通常依赖于论坛、邮件、GTalk进行联系交流，由于目前上海的开发人员比较多一些，所以会不定期的在上海举行开发者聚会。
6. RT-Thread依靠什么持续发展下去，能够盈利吗？
目前RT-Thread的发展主要依赖于大家的兴趣爱好，大多数都是在业余时间进行开发的。以后会通过技术支持、组件定制、组件开发、辅助工具等 方式进行盈利。从几大开源软件来看，商业支持是软件持续发展不可或缺的一部分，所以我们希望能够有更多的公司选择RT-Thread RTOS做为系统平 台，这个对于公司、对于整个RT-Thread社区都是双赢的局面。对于公司，能够获得免费的RTOS套件，同时也能够推动着这个RTOS套件不断的朝着 稳定的方向发展。对于我们，有公司支持的发展无疑会令RT-Thread的发展更上一层楼，当然也意味着以后的支持费用有着落啦。
=========
问题完了，开始进入0.3.x系列的主题。在对外发布上，相信大家已经看到了，RT-Thread已经进入了0.3.x的密集发布周期。RT- Thread/STM32F103VB已经发布了0.3.0系列的3个beta版本，RT-Thread/STM32F103ZE已经发布了0.3.0系 列的2个beta版本，RT-Thread/LPC2148已经发布了一个0.3.0系列的beta版本。接下来会考虑发布RT-Thread/LM3S 的第一个beta版本(汗一个，刚发过了的板子有些硬件问题，返修了)...
这些版本，大多数上会包含：Kernel + FinSH shell + Filesystem + LwIP等。
0.3.0系列，RT-Thread还包括两大内容：
- 编程指南文档
- RTGUI图形界面系统
编程指南一直在修订，比较遗憾文笔有限，所以文档还请大家不要太挑剔，有什么建议欢迎大家提出来。关于编程指南，还要提一句的是，这份文档是一份 编程的指南，在RT-Thread上编程需要考虑的地方都会提出来。但是，它并不是一份代码分析的文档，虽然它可能会提到内部的一些大致结构框架，但它不 会对代码进行一行行分析，所以请大家多多注意。
另外的RTGUI组件，会是以后的重点任务，目前的打算是在现有的STM32F103ZE开发板上实现一套可用的手持终端设备，当然也依然延续 RT-Thread的习惯，这套东西会以开源的形式释放出来。在s3c2410/2440上，这套GUI表现得是相当不错的，面向对象的设计，独立的控件 对象模型，留给了用户最大的可扩展性。
其他的，caoxulong的x86分支在整理完毕后也会放到0.3.0这个分支上来，通过这个分支大家可以完全摒弃开发板，在PC或 VMWare/QEMU上体验RT-Thread。LPC系列分支，苦于目前开发板不足，所以进展慢一些，上次发布的RT-Thread /LPC2148 0.3.0 beta1也只能包含SD卡、以太网口驱动框架，这个系列会把 wyoujtg/风城少主 的LPC2106的移植合并进 来。
文件系统这块现在代码已经发布出来了，其实里面还包括另外一个分支的：DFS-FAT，这个分支就如同DFS一样，是我们自己编写的，也能够支持NandFlash等介质上的坏块管理，写了很多个测试例子在测，等通过压力测试后会取代目前的DFS-EFSL发布出来。