有操作系统,但离自制有些越来越远了。
RT-Thread,源自中国的开源物联网操作系统。最初是2006年开始的,只有一个多任务调度,多线程模式。然后逐步完善内核周边,嗯,当时弄明白了开/关中断,多线程的同步、互斥、通信就迎刃而解了。
一些使用RT-Thread的案例也可以在RT-Thread网站上找到。
RT-Thread一开始是一个很简单的操作系统,因为它集成基本的多任务功能,所有的功能都通过编译器编译在一起,形成一个“可执行程序”(可执行的内核),代码都运行在内核态。这样的方式在RTOS挺普遍的,FreeRTOS是这样,早期的VxWorks也是这样。有历史原因,而技术上,RTOS比较少使用MMU(或者仅配置成1:1模式),这样也就不存在当程序或数据还未准备好时,触发缺页中断,而在中断或高优先级任务上下文中去load代码或复制数据(这个对实时性会造成致命的影响,行为没有确定性)。
这也让大多数人觉得RTOS是很简单的系统,甚至不称之为操作系统。
不过RT-Thread一直是从用户实际需求出发,希望RT-Thread能够广泛应用起来(这也是RT-Thread为什么开源的原因之一)。在实时内核的基础上,把命令行,文件系统,网络协议栈,POSIX API都增加上,形成一份基础型的平台(目前RT-Thread每次发布的,就是这样一套基础物联网操作系统平台)。这样的方式可以很紧凑,资源占用上也可以做得更棒,开发简单,容易上手,可以说这是一份典型的面向XIP执行芯片的操作系统(XIP执行,即代码直接在Flash上执行,而不类似Linux基本完全在RAM中执行)。
不过这样换个场景就会面临一定的问题:当功能多了后,这个编译在一起的内核程序也就逐渐增大。例如内核+文件系统+网络协议栈+图形UI+音频流框架+云服务接入等等,这个内核程序尺寸可能已经要超过Linux内核,在一些ARM9/11,Cortex-A处理器上有这么多功能需求是很可能的。瓶颈也随之出现:对于Cortex-A处理器,一般代码都需要在RAM上执行,而随着内核增大加载到RAM中的时间变得超长。为了这些需求,2019年以来,RT-Thread一直在做突破,首先是把内核和应用分离,同时降低内核程序的尺寸……不过完全采用微内核的架构,IPC性能将是非常大的挑战性。到2019年底再看,期待RT-Thread的新架构内核平台!
一直希望大家可以一起来完善(个人的力量太渺小了),所以诞生之初就以开源的方式发展,从0,从第一行代码开始一步步发展。从google code的svn,到 github的仓库。linus大神的git真好用,原来svn要各自分别提交代码很麻烦,谁来提交,代码也很容易冲突,没法很好管理;而在git/github上,大家可以提PR上来,然后维护人可以review代码,进行评论,Request changes或Approve,让大家(开发者)可以协同起来一起开发。到现在,对RT-Thread贡献代码的开发者也超过200+。随着大家贡献代码的增多,如何维护代码始终是大问题,好在git上可以挂hook,把持续集成和自动化测试钩上,错或对,一目了然。每年RT-Thread也会有开发者大会,希望可以在会上倾听更多开发者的声音。
RT-Thread一直以开源、社区化方式发展,在这10+年的历史中,也有无数的用户把RT-Thread用于他们的产品中,到今年(2019年),使用RT-Thread的设备数量也过亿台。宽松的商业使用也反馈在源代码的许可协议中,从最初的GPLv2+许可协议,到现在的Apache License v2.0,都愈发宽松。
回到问题,RT-Thread已经脱离了自制操作系统的范畴(我本人的代码提交数已经降到21%),越来越社区化。开源、开放、社区化是RT-Thread的主旋律。