RT-Thread创始人技术历程：从Linux情结到RTOS，及面向物联网的跨界思考

说起与 Linux 的渊源，可以追溯到我的大学时代。1998 年，我和宿舍同学凑钱买了第一台电脑，出于对软件的好奇，尝试安装了各种操作系统，DOS、Windows、Linux、FreeBSD 等都有涉猎。第一次接触带完整源码的全新操作系统，那种兴奋感至今难忘，最早接触的发行版是 Slackware Linux，还是在电脑城的光盘堆里翻出来的。

重庆邮电学院是邮电类院校，很早就有了校内电话和几个公开的上网拨号口，学校的总出口带宽仅有 128kbps。当时我自己买了一个 36.6kbps 的“小猫”用于上网。由于号码有限，很快就演变成“抢号大战”。记忆最深的就是用 Linux 的自动重拨功能去拨号，因为它总能帮我抢到线路，这算是我第一次体验到开源工具的“威力”。

为了在 Linux 下顺畅使用，我也加入了早期的 Linux 中文化工作，折腾中文显示和输入法。当然，驱动问题始终是个困扰，网卡、显卡、声卡的驱动如何配置是当时的日常。我也是 KDE 桌面环境最早的一批国内用户，当 KDE 1.0（还是 Beta 版？）发布时，想方设法从国外把软件包拖回国内教育网，那个时候的流量可是真金白银，穷学生的钱基本都贡献给上网费了。

RT-Thread 的诞生

毕业后的工作一直与嵌入式设备打交道，从最初在上海贝尔阿尔卡特使用 VxWorks，到后来的 Nucleus Plus/ThreadX，始终身处嵌入式实时操作系统（RTOS）的环境中。与此同时，我也一直关注着 Linux 和开源生态的发展。

2005 年，因为一个朋友的项目契机，我萌生了自己写一个嵌入式实时操作系统的想法。为什么要自己写？当时 RTOS 领域的现状是这样的：

• 商业系统：如 VxWorks，价格昂贵，个人开发者难以触及。
• 开源系统：如 eCos、RTEMS。但这类系统对编译器依赖性太强，想用硬件仿真器调试非常麻烦。eCos 的 C++ 代码对编译器更挑剔；RTEMS 则相对庞大，对于资源有限的微控制器（MCU）来说占用过多。
• 半开源系统：如 uC/OS-II，在国内应用广泛，但其本质上是一个实时内核，功能较为简单。我个人更习惯于 Linux/Unix 的代码风格，对 uC/OS-II 的风格不太适应。可以说，如果不是因为个人对代码风格的偏好，或许就不会有 RT-Thread 了。

RT-Thread 创立之初的目标就很明确：打造一个开放、开源的嵌入式实时操作系统。

• 简单与小巧
  “Simple things should be simple, complex things should be possible.” 这句话深得我心。在 RT-Thread 的设计中，能用简单方式实现的绝不弄复杂。同时，各个组件以松耦合方式构建，当这些简单的组件组合起来时，就能实现复杂的功能。这种设计让它既“小”得足以适配资源受限的芯片，也“大”得可以满足一定的功能性需求。
• 开放与社区化
  RT-Thread 首先是面向开发者的系统，它通过社区协作的方式推动和发展。目标是将开发者们认为合适、便捷、优秀的东西吸纳进来，让系统更顺手。这样的理念也为 RT-Thread 在开发者群体中赢得了不错的口碑。

再续 Linux 梦想：RT-Thread 与 Linux 的融合

Linux 是一个充满魅力的伟大操作系统，工作后我一直遗憾没有更多机会深入 Linux 内核。后来在 Marvell 工作时，负责基带处理器的系统软件平台。现代手机芯片多是“基带处理器 + 应用处理器”的架构，应用处理器跑 Linux/Android，提供丰富的功能支撑；而基带处理器则运行实时操作系统。

这种架构分离主要出于几点考虑：

1. Linux 的实时性欠佳，即便是打了实时补丁的 Linux，其“硬实时”指标也不理想，更多被视为“软实时”系统。
2. Linux 的功耗控制相对复杂，应用处理器的功耗也较高。

当然，Linux 带来了无与伦比的生态优势和完备的功能。由于企业需求和自身技术探索的愿望（希望能更深入接触 Linux 内核），我们在 RTOS + Linux 的融合方向上进行了深度挖掘，并最终成功应用于实际产品。

具体实现上，我们探索了两种路径：

1. 单核双系统
最初的设想是在单核上运行双系统，我们选择了 QEMU 可模拟的 ARM Cortex-A8 平台进行指令级的调试。为了保证实时性，我们让 RT-Thread 主管整个系统，接管所有中断，而 Linux 则运行在一个虚拟的中断环境中。从架构上看，是将整个 Linux 操作系统作为一个低优先级的任务，调度到 RT-Thread 的实时调度器中运行，两个系统间的资源（内存、外设）被隔离。当需要进行数据交互时，则通过我们自研的双系统间通信机制 VBUS 来完成。

2. 双核双系统
单核双系统方案对 Linux 内核的修改仍然较大（当然，相比 Linux 实时补丁、Xenomai 等实现，这些改动算是“九牛一毛”），尤其是在中断处理部分，这也是传统 Linux 实时化方案维护性差的主要原因。在完成单核方案后，双核双系统便水到渠成，其核心依然是 VBUS 通信机制。

双核双系统是在多核 CPU 上同时运行两个独立的操作系统，相当于将一个多核芯片拆分成两个独立的芯片来使用。这种方式对 Linux 内核几乎无需修改。例如，在 Zynq 平台的双核 Cortex-A9 上运行 RT-Thread 和 Linux，只需加载一个 Linux 内核模块即可，完全无需改动内核代码。如果您对 操作系统 内核级的交互机制感兴趣，可以在我们的社区找到更多深度讨论。

无论是单核还是双核方案，VBUS 都是共用的核心。VBUS 被实现为一个数据包复用的通信系统，不同的系统服务可以基于它进行通信。VBUS 还实现了 QoS 机制，确保高优先级数据能够优先送达。在 VBUS 之上，可以构建起连接 RT-Thread 与 Linux 的桥梁，例如分布式文件系统、虚拟网络驱动等。

更进一步，通过 VBUS 甚至可以模拟实现“板载 CPU + MCU”的分离式异构系统架构。这类方案为实时控制提供了一种简洁的解决方案：由 Linux 处理富功能应用，RT-Thread 处理高实时性控制。根据不同的芯片性能，实时控制部分的抖动可以控制在 1us – 10us 的范围内。这种方式始终遵循我们最初的目标：简单、高可维护性。

对 RT-Thread 未来的思考

RT-Thread 经过近十年的发展，已经演变为一个成熟的内核和系统软件平台，被众多企业（包括一些大型公司）接受，用于各种产品并经过了海量出货的验证。有时也不禁感慨“无心插柳柳成荫”，希望 RT-Thread 能在技术发展的历史长河中留下自己的印记。

未来，RT-Thread 将继续以社区化的方式，按照每年一个大版本、每季度一个补丁小版本的节奏稳步推进。我们也希望 VBUS 机制有机会进入 Linux 内核主线，让 Linux 与 RT-Thread 能够更融洽、紧密地协作。

物联网和智能设备是当前及未来的明确方向，摩尔定律也将继续在这些领域发挥作用。正如百度 IoT 战略所言：“连接”是 IoT 的基础，“数据”是 IoT 的价值，“智能”是 IoT 的核心。RT-Thread 将以其自身特点，在资源有限的 MCU/MPU 环境中，提供强大的多连接支持与智能化支持。在后续版本中，RT-Thread 也将提供更完备的 POSIX 兼容接口，让一些类 Linux/Unix 的应用（尤其是网络相关的开源软件）能够在更轻量、资源要求更低的 RT-Thread 系统上运行。在物联网的世界里，RT-Thread 希望成为 Linux 之外的一个有益补充。对于从事 C/C++ 开发的嵌入式工程师来说，掌握 RT-Thread 无疑能拓宽其技术栈和解决复杂问题的能力。

技术的道路总是充满交汇与融合，从对 Linux 的初识情怀，到打造 RT-Thread 的实践，再到探索两者结合的创新架构，这一历程反映了嵌入式系统发展的一个侧面。在 云栈社区 中，也有许多开发者分享着他们在 RTOS、Linux 以及两者融合应用上的经验与见解。