RT-Thread v2.0.0版本回顾及后续规划

发布于 2015-02-02 16:14:30 浏览：7553 订阅该版

v2.0.0版本回顾

v2.0.0的正式版本历时一年多，终于正式发布了。这一年多来也经历了很多的事，例如年中时深圳的嵌入式沙龙，得到深圳同学们的大力支持，与会人数大大超过我们的预期；暑期参与CSDN的编程夏令营活动，让一些同学从学生时期就开始参与；10月份时，服务公司牵头参与到ST的全国巡演会中为RT-Thread布道；12月份上海的嵌入式沙龙上，能够邀请到宋宝华老师这样的Linux内核大牛为大家带来实时Linux主题的分享等等！这一年，谢谢大家，谢谢大家对RT-Thread的热情支持！

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

下一个版本应该是一个小版本，不可能总是类似原来，每次都出大版本 [s:158] 很多人来询问过下一个版本的计划是什么。其实我想说，RT-Thread是一个开源社区，RT-Thread的后续发展在社区，属于每一个社区参与者，你想在里面加入什么样的功能，做好哪部分的工作，关键在于每个社区的参与者。只要符合RT-Thread的东西（例如许可证上没有冲突），我也没理由不把它放到RT-Thread开发主干上来。

所以我下面提及的更多代表的是我个人的一些想法，社区还是需要更多的多样性，社区是属于你的，只要你参与进去做！

1. CloudIDE，这个是托管在http://lab.rt-thread.org/cloudide 上（可能因为备案的问题暂时不通）的在线方式的集成开发环境，嗯，有些类似mbed [s:161] 但是希望有自己的特色，以及希望它是属于国内的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的多系统（硬件）平台；
  - 其他一些硬件移植；