本文转载至:
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!