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外的一个有益补充!

©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值