RT-Thread 创始人熊谱翔：我和 Linux、嵌入式实时操作系统 RT-Thread

我和 Linux、嵌入式实时操作系统 RT-Thread

—— RT-Thread创始人熊谱翔，2015 年

接触 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 是一个伟大的操作系统，很多地方都充满着魅力，工作以来也一直遗憾没有更多的机会接触到 Linux Kernel。在 Marvell 的时光则是做基带处理器的系统软件平台。现代手机芯片多是基带处理器+应用处理器的架构，在应用处理器中跑着 Linux/Android，并提供完备的支撑；而基带处理器则运行着实时操作系统。

这类主要从几个方面考虑：

1. Linux 的实时性并不好，包括打上实时补丁的 Linux 同样如此，顶多只能称为软实时，并且实时指标也非常不理想。
2. Linux 的功耗并不容易控制，应用处理器的功耗同样也比较高。

当然 Linux 也带来了很多的优点，例如很好的生态环境，完善的功能等。

由于企业方面的需求，同时包括我们也有想法尝试下这个方向（希望能够更多的接触到一些 Linux Kernel），所以我们最终也在 RTOS + Linux 的方向上进行了大量的深度挖掘，并最终得以用于实际产品中。

单核双系统

最初的考虑是以单核双系统的方式进行，并以 QEMU 能够模拟执行的 ARMCortex-A8 做为最初的平台进行汇编级，指令级的调试。

由于实时性是主要考虑的方面，所以类似于在单核上是让 RT-Thread 来主管整个系统，中断也完全由 RT-Thread 来进行接管，而 Linux 下类似于看到的是虚拟的中断系统（当然它最终也会反映到实际的中断控制器上）。整体架构上来说，是把 Linux 这个 OS 整体做为一个低优先级的任务放在 RT-Thread 的实时调度环境中执行起来，两个操作系统间的资源（内存，外设驱动等）隔离访问。当需要进行两个操作系统的数据交互时，通过一套我们自行实现的双系统间通信进制 VBUS 来进行。

双核双系统

单核双系统相对来说，对 Linux Kernel 的修改还是比较大（又有说，相对 Linux 实时补丁，Xenomai 等实现，这些修改不过九牛一毛），特别是在中断处理上。这种方式也估计就是 Linux 实时补丁的麻烦之处吧，维护性会很成问题。当单核双系统实现之后，实际上双核双系统也就水到渠成了，当然这个的核心所在则是双系统间通信的 VBUS 机制。

双核双系统是在双核或多核上同时运行两个操作系统，相互之间运行相对独立，把一个双核的芯片独立的拆分成两个单独的芯片来使用。这种方式对 Linux Kernel 来说几乎无修改，例如 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外的一个有益补充！