RT-thread国产实时操作系统概述
RT-Thread实时操作系统是一个分层的操作系统，它包括了：
• 组件层components，这些是基于RT-Thread核心基础上的外围组件，把一些功能模块划分成独立的一个个组件模块，做到组件与组件之间的低耦合，组件内部的高内聚。
例如文件系统，命令行shell接口，lwIP轻型TCP/IP协议栈，GUI图形用户界面等。
• 硬实时内核kernel，这层是RT-Thread的核心，包括了内核系统中对象的实现，例如多线程及其调度，信号量，邮箱，消息队列，内存管理，定时器等实现。
•分支接口porting，主要由libcpu以及不同硬件平台的bsp构成，即RT-Thread支持的一个个芯片移植，外设驱动等
在官网http://www.rt-thread.org/下载RT-Thread v2.0.0正式版，解压后：
bsp： 针对各个具体开发板、平台的目录，其中包含相应的Keil工程文件（如果包含了Keil MDK的移植）
components：各个组件，如dfs/drivers/finsh/gdb/libc/libdl/net/vbus/vmm等
documentation/examples：辅助文档以及一些内核、组件的测试实例
include：包含了RT-Thread内核头文件
libcpu： 面向各个芯片cpu移植的代码
src：包含了RT-Thread内核源文件
tools：支持各种集成开发环境的python文件，如常见的iar.py/keil.py/sconsui.py/vs2012.py
v2.0.0版本相对v1.2.x版本，又加入众多新功能，有些很有趣，有些很实用：
1. 设备驱动框架在v2.0.0版本中进一步完善。DeviceDriver在RT-Thread中类似抽象的驱动框架层，初衷是，向应用层（或组件）提供标准统一的接口，向下（底层硬件）提供简化的编程模型，在v2.0.0版本中，新添加了：SPI NorFlash（ATMEL/SST/华邦等厂家），SPI ETH（ENC28J60），SPI WiFi（RW009）等的驱动，这些驱动依赖于RT-Thread的SPI抽象模型，提供了抽象、无需修改的外设驱动代码；类似的，建立在I2C驱动框架上，v2.0.0版本也引入了sensor的驱动框架，并提供了MPU6050、BMI055等传感器的驱动；作为杂类设备的尝试，GPIO(IO pin)的抽象框架也终于在这个版本提出来了，以后点灯简单啦！
2. 在1.x系列版本中，USB device/host框架支持得一般，不能说非常棒，而在v2.0.0版本中，USB框架通过逐步的重构，也开始走向成熟，在服务公司里也应用到多个项目，多个处理器上；
3. 为了方便的切换不同的编译器平台，在v2.0.0版本中也把原来的minilibc/newlib/armlibc用统一的宏替换：RT_USING_LIBC。老版本的代码迁移过来，请注意下使用新的、统一的宏：RT_USING_LIBC。同时也加入了IAR的dlib，这样当配置中打开LIBC时，scons将会自动根据你当前使用的编译器来自动选择不同libc库的移植；
4. GDB stub，这部分是CSDN编程夏令营活动的成果之一，一直觉得类似夏令营的活动很好，可以拉近学生和开发者的距离。通过这个组件，终于可以让RT-Thread可以进行软件方式的调试了，虽然是命令行方式的GDB，但它也有很多图形化前端配合来进行源码级的调试仿真；
5. lwIP相关的更新。这个貌似有很多，引爆点应该说是一个很热门的词：物联网。围绕着这个，v2.0.0版本中加入了RW009这样的简单易用的Wi-Fi网卡驱动，IPv4/v6双协议栈的支持，DHCP server，甚至是NAT这样的地址转换实现，哦，用RT-Thread来做小路由，网关变成了可能。哦，RT-Thread的目标并不是物联网，更重要的是它是一套基础性的软件平台。
6. 随着Linux/RT-Thread同时执行的方式，相应的VMM组件，VBUS组件也在这个版本上发布出来。VMM组件更多的侧重于单核，Linux/RT-Thread双系统并行执行以获得更好的实时性，而VBUS组件则解决了Linux/RT-Thread双系统之间的数据通信问题。两者是相辅相成的。这两个组件要求的技术性也更高，一般用于一些可靠性要求非常高的场合。在RT-Thread 2.0.0版本中也终于支持了LPC4357这样的小异构系统（LPC4357中包含了ARM Cortex M4/M0两个异构核心），实现了M4/M0上分别运行RT-Thread系统，两者之间则通过VBUS进行通信。所以，对多系统/VBUS感兴趣的同学可以从LPC4357上入手。
在开发的过程中也出现了一个附加品，QEMU/realview上模拟执行RT-Thread（或者Linux/RT-Thread）的BSP，它可以让未经修改的标准QEMU，去软件仿真模拟执行RT-Thread，或更进一步，执行Linux/RT-Thread。
RT-Thread v2.1.0 roadmap
下一个版本应该是一个小版本，不可能总是类似原来，每次都出大版本很多人来询问过下一个版本的计划是什么。其实我想说，RT-Thread是一个开源社区，RT-Thread的后续发展在社区，属于每一个社区参与者，你想在里面加入什么样的功能，做好哪部分的工作，关键在于每个社区的参与者。只要符合RT-Thread的东西（例如许可证上没有冲突），我也没理由不把它放到RT-Thread开发主干上来。所以我下面提及的更多代表的是我个人的一些想法，社区还是需要更多的多样性，社区是属于你的，只要你参与进去做！
1. CloudIDE，这个是托管在http://lab.rt-thread.org/cloudide 上（可能因为备案的问题暂时不通）的在线方式的集成开发环境，嗯，有些类似mbed但是希望有自己的特色，以及希望它是属于国内的Online IDE，速度能够快些。这部分也在密集的进行改版，演变成多标签页编辑方式；配合Wi-Fi入门套件，进行在线方式更新固件；加入开发者间的代码片段，组件分享功能；集成文档帮助等信息等等；创建这个的初衷是希望新手入门能够方便些，而不是受搭建开发环境的困扰，需要的只是一个浏览器。Wi-Fi入门套件，暂时称为ART-wifi吧，简单的名字就是一个称呼，名字而已。
2. 去年12月份上海嵌入式沙龙活动中，weety提到了POSIX兼容性的问题，导致Linux的一些程序并不那么容易移植过来（或者说后续的代码一致性），这里主要问题在于BSD socket接口是完全属于lwIP协议栈，而和RT-Thread的文件接口没关系，所以在RT-Thread上没有socket/file descriptor/device间的select/poll/read/write等调用；另外一个隐含问题是，POSIX实现也不是那么标准，可能里面还有一些坑等。这个问题是一个大问题，因为关键点在于，大家既然选择了开源的系统，那么他肯定也考虑到开源生态很好，有很多的资源可以使用，可以左右逢源。。。所以，RT-Thread也需要以更开放的姿态来解决这个问题，使得它能够更开放，增强POSIX标准本身的亲和力。相类似的，它也应该更好地支持一些C++标准，基础设施RT-Thread已经提供了，后面如何去应用，那么就看用户的想法、创新性有多大了。
3. 一些重型平台的支持，例如市场上新出的一些堆叠封装了SDRAM/DDR的ARM9，Cortex-A8/9，MIPS32/64，甚至是x86，这个肯定也会逐步地演变成RT-Thread的目标硬件平台，但是这个投入也会比较重。如果上面的第二项解决了，也不是不可能，首要解决的是底层驱动的问题，这样后续就比较容易和上面的组件、应用粘合起来。
好了，以下是想到的无责任feature list，感兴趣的同学可以来认领：
* CloudIDE相关
– 完善NAT功能，把ART-wifi变成一个Wi-Fi中继（路由）。
– 期待在CloudIDE上分享MQTT组件，CoAP组件；
– 期待把ART-wifi变成一个Wi-Fi/6LoWPAN网关。
– 期待把ART-wifi变成一个Wi-Fi/nRF51822 6LoWPAN网关，Wi-Fi/nRF51822 BLE网关；
– 期待把ART-wifi变成一个多轴飞控，并跑一些PX4的算法代码；
– 期待在CloudIDE上分享乐联网物联网接入组件；
– 期待在CloudIDE上分享yeelink物联网接入组件；
– 期待在CloudIDE上分享SSL组件；
– 期待在CloudIDE上分享阿里云，机智云，百度云，腾讯云等等接入组件；
– 更多的传感器驱动，例如气压计，温度计，光照，9轴传感器等；
– 期待在CloudIDE上加载RealBoard 4088 APP开发功能；
– 期待在CloudIDE上加入图形用户界面设计功能；
– 期待把CloudIDE变成本地化的桌面应用程序；
* POSIX相关
– 针对lwIP实现DFS上相应的lwIP fs接口，让DFS的fd和lwIP socket关联起来；实现select/poll接口；
– 更好的把device接口和DFS devfs融合起来；协同实现好select功能；
– 加入更多POSIX相关接口，包括但不限制于aio，signal等功能；
– 整理DeviceDriver框架，让device接口，和各自设备驱动接口分离开来。应用程序更多的倾向于使用device接口，固件开发可以使用设备驱动接口；
* 其它
– openbsd的TCP/IP协议栈移植；openbsd POSIX外围接口移植；
– canopen组件；
– ARM Cortex-A8/A9 + M4/M3的多系统（硬件）平台；
– 其他一些硬件移植；
以上摘自http://www.rt-thread.org/phpBB3/topic3965.html
与v2.0.0RC版本相比，主要有以下改进：
内核
console以RT_DEVICE_FLAG_STREAM参数打开字符设备；
在rt_memheap_free中加入更多的断言检查；
组件
更新RW009驱动以支持Wi-Fi SoftAP模式（aozima）；
修正sensor框架的一些问题，并加入C API接口（睿赛德服务公司提供）；
加入MPU6050 sensor的代码（bernard, Coing）；
加入BMI055 sensor的代码（Coing）；
当未使能heap时，修正finsh/msh中list_memheap的问题；
修正LIBC编译的警告；
加入IAR dlib相关的移植，使得应用能够使用标准的API接口；
修正YMode握手时可能引起的竞争问题（grissiom）；
更新FreeType版本到2.5.4
单独把C++的全局对象初始化放到cplusplus_system_init函数中，并在初始化线程中调用；
finsh中以RT_DEVICE_FLAG_STREAM参数打开字符设备；
添加VBUS组件用于Linux与RT-Thread系统之间，RT-Thread与RT-Thread系统之间通信（睿赛德服务公司捐赠）；
增加lwIP/NAT组件，可以做多个网口间的地址转换（Hicard）；
增加lwIP/DHCP服务端，用于向客户端分配IP地址（睿赛德服务公司提供）；
BSP
修正LPC4357串口驱动初始化时过早打开中断的问题（nongxiaoming）；
重写LPC4357串口驱动，并让芯片上M4/M0核心分别都执行RT-Thread系统，两核心之间以VBUS组件进行系统间通信（睿赛德服务公司捐赠）；
新增RX移植（limxuzheng）；
新增NuMicro M051 Series移植，支持GCC、Keil MDK编译器（bright-pan）；
新增LPC54102移植（Coing）；
移除STM32F4 BSP中不需要的RT_TIMER_TICK_PER_SECOND配置（pangweishen）；
在Linux Clang编译分析中，强制以32位模式进行编译（grissiom）；
修正STM32F103中串口驱动中断过早打开的问题（armink）；
工具
增加scons中的MD5支持（bright-pan）；