RT-Thread创始人熊谱翔: 我和Linux、嵌入式实时操作系统RT-Thread
本文转载至：http://www.rt-thread.org/dynamic/78.html
接触Linux
说起Linux应该从我在校园时期说起。我是在山城——重庆邮电学院念的书，1998年时宿舍伙伴一起凑的钱买的电脑，因为对各种软件感兴趣，所以也装了各种操作系统，DOS，Windows，Linux，FreeBSD等都装过，当时觉得能够在Dos/Windows之外接触到一种全新的操作系统非常兴奋，特别是（带源码的）软件还这么多，记得最初接触的是SlackwareLinux，并且是在电脑城卖光盘的地方翻出来的。
重庆邮电学院是邮电类院校，所以很早的就有了校内电话，然后还在校内开通了几个公开上网电话，经由学校的Internet出口，记得当时总出口只有128kbps，而当时我还自己购买了一个36.6kbps的小猫用来上网。因为上网的电话号码就这么几个，所以开通后不久就演变成大家去抢号上网，我记忆中最深的就是用Linux去拨号上网，因为它有自动重播的功能，所以一般总能够抢到：-)
当然因为要在Linux下上网的缘故，我也加入了Linux早期的中文化道路，中文显示，中文输入等。当然随之而来的驱动问题很困扰，网卡如何驱动，显卡/声卡如何驱动。也是KDE桌面环境最早的一批玩家，当KDE1.0（还是beta版本？）发布时，从国外先弄个什么远程上传工具把KDE软件包传回国内，然后再把它拖到教育网来，那个时候这些（特别是国外）数据流量可是硬生生的钱啊！穷学生都把钱拿去上网了……
初创RT-Thread
毕业后我的工作也基本上是和设备打交道，从最初在上海贝尔阿尔卡特时的VxWorks，到后来的NucleusPlus/ThreadX，可以说基本处于嵌入式设备及实时操作系统环境中，当然在这个过程中依然关注着Linux，关注着开源的发展。
后来因为朋友项目的缘故，于2005年时动了自己写一个嵌入式实时操作系统的念头。为什么自己写？当时的实时系统情况是：
* 商业的VxWorks，价格昂贵，个人使用可能性太低；
* 开源的ecos、rtems等。但这类开源操作系统对编译器依赖性太强，导致想使用硬件仿真器太麻烦了。另外ecos的C++代码对编译器会更挑；rtems其实是一套相对庞大的系统，对于小资源的芯片（例如微控制器类芯片）资源占有太过厉害。
* 半开源的商业性ucos-ii操作系统；ucos-ii在国内用得非常多，功能简单基本上可以认为是一个实时核心。因为我习惯于Linux/Unix的代码风格，所以对ucos-ii的代码风格极为强烈的不习惯，所以完全可以说，如果不是因为个人更喜欢Linux/Unix代码风格的习惯，或许就不会有RT-Thread诞生了。
RT-Thread最初的目标是一个开放、开源的嵌入式实时操作系统：
* 简单，小巧；
觉得这句话说得非常好：Simplethings should be simple, complex things should be possible. 在RT-Thread中，如果能够以一个简单的方式来实现绝不把它弄复杂了；相应的，RT-Thread的一些组件也按照这样的方式实现，并不是耦合在一起。当一个个简单的组件组合在一起时，能够实现复杂的功能：小，可以适配一些资源有限的芯片，大，可以满足一定的功能性需求。
* 开放，社区化的系统；
RT-Thread首先是一个面向开发者的系统，它是以社区化方式进行推动、发展演化。同样的，能够把开发者们认为适合的，方便的，优秀的东西放在里面，让开发者们用得顺手！因为这个也在开发者中留下不错的口碑。
再续Linux的梦想
Linux是一个伟大的操作系统，很多地方都充满着魅力，工作以来也一直遗憾没有更多的机会接触到LinuxKernel。在Marvell的时光则是做基带处理器的系统软件平台。现代手机芯片多是基带处理器+应用处理器的架构，在应用处理器中跑着Linux/Android，并提供完备的支撑；而基带处理器则运行着实时操作系统。
这类主要从几个方面考虑：
1. Linux的实时性并不好，包括打上实时补丁的Linux同样如此，顶多只能称为软实时，并且实时指标也非常不理想。
2. Linux的功耗并不容易控制，应用处理器的功耗同样也比较高。
当然Linux也带来了很多的优点，例如很好的生态环境，完善的功能等。
由于企业方面的需求，同时包括我们也有想法尝试下这个方向（希望能够更多的接触到一些LinuxKernel），所以我们最终也在RTOS+ Linux的方向上进行了大量的深度挖掘，并最终得以用于实际产品中。
1. 单核双系统；
最初的考虑是以单核双系统的方式进行，并以QEMU能够模拟执行的ARMCortex-A8做为最初的平台进行汇编级，指令级的调试。
由于实时性是主要考虑的方面，所以类似于在单核上是让RT-Thread来主管整个系统，中断也完全由RT-Thread来进行接管，而Linux下类似于看到的是虚拟的中断系统（当然它最终也会反映到实际的中断控制器上）。整体架构上来说，是把Linux这个OS整体做为一个低优先级的任务放在RT-Thread的实时调度环境中执行起来，两个操作系统间的资源（内存，外设驱动等）隔离访问。当需要进行两个操作系统的数据交互时，通过一套我们自行实现的双系统间通信进制VBUS来进行。
2. 双核双系统；
单核双系统相对来说，对Linux Kernel的修改还是比较大（又有说，相对Linux实时补丁，Xenomai等实现，这些修改不过九牛一毛），特别是在中断处理上。这种方式也估计就是Linux实时补丁的麻烦之处吧，维护性会很成问题。当单核双系统实现之后，实际上双核双系统也就水到渠成了，当然这个的核心所在则是双系统间通信的VBUS机制。
双核双系统是在双核或多核上同时运行两个操作系统，相互之间运行相对独立，把一个双核的芯片独立的拆分成两个单独的芯片来使用。这种方式对LinuxKernel来说几乎无修改，例如Zynq上的SMP双核Cortex-A9，在上面执行RT-Thread/Linux只需要加入一个Linux Kernel Module即可，而完全不需要修改LinuxKernel代码。
不管是单核双系统还是双核双系统，其中的VBUS是共用的，VBUS被实现成一个数据包复用通信系统，让不同的系统服务能够在上面进行通信、沟通，同时VBUS上也实现了QoS的机制，让高优先级的数据能够先行送达到对端。这样在VBUS之上可以搭建起RT-Thread与Linux间的桥梁，例如分布式的文件系统，虚拟网络驱动等。
再泛一些，通过VBUS也能够实现类似板载CPU+ MCU的分离式多系统结构。这类异系统架构方式，为实时控制提供了一种简洁的解决方案，由Linux处理富功能性，RT-Thread处理实时控制部分。而依据不同的芯片情况，实时控制部分可以保持在1us– 10us的实时抖动范围内。这种方式依然遵循着我们最初的目标：简单，高维护性的目标！
对RT-Thread未来的思考
RT-Thread经过近10年的发展，它已经演变成了一套成熟的内核系统、系统软件平台，被一些企业所接受，其中不乏一些大公司，被用于多种产品并经过大量产品出货量验证。有的时候也感叹，无心插柳柳成荫，希望RT-Thread能够在以后的历史长河中留下一笔。
未来，RT-Thread依然会按现有的步伐，以社区方式发展，以每年一个大版本的方式往前推进，同时每个季度追加补丁小版本的方式进行发布。而VBUS也希望有机会能够进入到Linux Kernel Upstream中，让Linux与RT-Thread能够更融洽的相处，紧密合作。
物联网，智能设备是目前及未来的发展方向，摩尔定律也会在这类芯片上发挥作用。如百度IoT战略说的：“连接”是IoT的基础；“数据”是IoT的价值；“智能”是IoT的核心。RT-Thread会在物联网中以自身的特点，在资源有限的MCU/MPU环境中提供多连接性支持，提供智能化支持。今年（2015年）年末，RT-Thread的新版本也将提供更完备的POSIX兼容接口支持，让一些类Linux/Unix应用（特别是一些网络相关的开源软件）能够在轻型的，芯片资源要求更低的RT-Thread系统上执行起来。RT-Thread将会是物联网世界中Linux外的一个有益补充！
欢迎关注Linuxer —— Linux开发者的自媒体。我们的特点是：没有资金，没有稿费，没有回报！just for fun!