RT-Thread RTOS

2018/03/20 14:24
阅读数 190
RT-ThreadRTOS是一款来自中国的开源实时操作 系统,由RT-Thread工作室的专业开发人员开发、维护。
起初RT-Thread是一个实时的内核(全抢占优先级调度,调度器 时间复杂度O(1)),但在发展过程中,RT-Thread实时操作系统得到了来自全国 嵌入式开发工程师的鼎力支持,为RT-Thread添砖加瓦,现在它不仅仅是一款高效、稳定的实时核心,也是一套面向嵌入式系统的软件平台,覆盖了全抢占的实时操作系统内核,小巧而与底层具体实现无关的文件系统,轻型的TCP/IP协议栈以及轻型的多窗口 多线程 图形用户界面
RT-Thread是一个平台,您可以把您的创意汇聚在一起,小平台大社区,RT-Thread的开发人员就在您的身边。
 
中文名
RT-Thread RTOS
性    质
开源实时操作系统
开发者
RT-Thread工作室
时    间
2006年上半年

开发者自述

编辑
1、诞生
一切东西还得从头谈起。
  RT-Thread RTOS,Kernel部分完成于2006年上半年,其IPC部分甚至是年中时才具备相应的雏形。最开始时是因为要为朋友做一个小型的手持设备,而我本人起初又是另一国内老牌RTOS:DOOLOO RTOS开发人员,但这个团队在2005年底已经解散。但朋友的系统要上,用 ucos吗,一不熟悉,二看不上。答应朋友的事,总得有解决方法吧,即使是原来的DOOLOO RTOS,因为其仿VxWorks结构,导致它的核心太大,包括太多不必要的东西(一套完整的libc库),这些方案都否决了。怎么办?当时朋友那边也不算太急,先自己写一套内核吧。这个就是源头!(后来虽然朋友的项目夭折了,但这套OS则保留下来了,并开源了,万幸)
  当然RT-Thread和原来的DOOLOO RTOS差别还是很大的。DOOLOO RTOS是一种类VxWorks风格的,而RT-Thread则是一种类NucluesPlus风格的,小型、实时、可剪裁。这三个方面RT-Thread可以骄傲的说做得比DOOLOO RTOS都要好很多,小型:RT-Thread核心能够小到4K ROM,1K RAM;实时:线程调度核心是完全 bitmap方式,计算时间是完全固定的;可剪裁性,配置文件rtconfig.h包含多种选项,对Kernel细节进行精细调整,对各种组件(文件系统,使用 EFSL、ELM FatFs;网络 协议栈,finsh shell)进行可选配置。
  2、艰难的发展期
  在第一个公开板发布后(0.1), RT-Thread意识到了一个问题,光有核心不行。别人如何使用:虽然采用了 doxygen风格的注释,并自动产生相应的API文档,但能够使用的人寥寥,有这个功底的人不见得认可你的系统,没相应功底的人也玩不转你的系统。所以下一个系列,考虑如何让系统能够支持更多的平台。首选ARM,为什么?应为ARM正处于发展的前期,使用的人也广泛,而RT-Thread第一个支持的平台就是s3c4510,这个是lumit开源项目赠送的平台。在其后,支持了包括s3c44b0,AT91SAM7S64, AT91SAM7X256s3c2410,AT91SAM9200,coldfire,x86等一系列平台,编译器统一使用GCC,这个时期无疑是最艰难的时期(真的艰难吗?呵呵,但肯定是迷茫的),这个就是0.2.0、0.2.1、0.2.3、0.2.4版本等,不同的版本支持不同的平台。
  猜猜我这段时间是干什么工作的?不知道大家对这个领域是否熟悉,手机2G,3G协议栈开发。每天都和协议栈打交道,而且最痛苦的是上千页的25.331 RRC协议,都是英文的,所以RT-Thread算做是工作之外的苦中作乐吧。而也正是这个时候,shaolin同学出现了,帮助完成了RT-Thread/x86的移植,他当时还是学生。
  这其中还有一件郁闷的事,当时RT-Thread团队还有几个人,只不过主要是shaolin和我。当0.2.3发布时,我建议开始 微内核的道路,嗯,可能很多人还比较困惑, RT-Thread后面跟着的为什么是“启动下一代RTOS演化”,当时就是因它而感慨:把微内核引入进来,把内核态和 用户态分开来,并且建立一个类似于L4的微内核。当然最重要的是,其中有一个强实时核心。而且L4实际上是把 页表操作放到内核之外的,如果内核是一个强实时内核将对整个系统的实时性提升很大,而因为 微内核的缘故,也能够运行linux的应用程序,并且当时RT-Thread也提出了一种,线程即IPC的概念。。。只是,最后的提案被大家否决了。团队开始有数人,只是能够坚持的没几个。
  3、一年增加0.0.1
  本人很早就接触了 Linux,算是国内资深的Linux接触者(早期也算一个Linux开发人员吧),KDE 1.0几乎是看着发展起来的(大家有谁用过RedHat 5.1?)。个人算是很多方面有一些自由软件的习惯:软件的 版本号是非常重要的一个标志,宁愿增加一个细微的版本号也不轻易的增加一个大的版本号,因为大的版本号是需要对用户负责的。1.0版本更代表了系统的稳定性,健全性。例如mplayer到1.0版本就经历众多小版本,0.99的beta版本亦无数。
   RT-Thread也把这点体现得淋漓尽致,0.2.2到0.2.3一个版本的增加,整整花了一年多的时间。但这个小版本号的增加,却带来了 开源社区 嵌入式环境中最完善的 TCP/IP协议栈LwIP。当然,开始时并不算稳定。在这几个版本中,RT-Thread也终于从迷茫中走出来,RT-Thread需要自己的特色,一个单独的RTOS Kernel没太大的用处,因为你并没有上层应用代码的积累,并且一些基础组件也非常重要,有这些基础组件基本上意味着,在这个平台上写代码,这些代码就是你的,甚至是你哪天也可以把它放到另外一个硬件平台上运行。
  同样,0.2到0.3版本号的变更,花费的时间会更长^-^ 版本号的长短,是和计划的feature实现是密切相关的,没到设定的目标如何可能进行发布呢?
  4、Cortex-M3的变革
  RT-Thread的变革因为Cortex-M3而来,因为ST的STM32使用的人太广了,当然还有非常重要的一点。RT-Thread已经开始支持Keil MDK,armcc了。GNU GCC确实好,并且也由衷的推崇它,使用它,只是调试确实麻烦,阻碍了更多人使用它(ARM平台上)。当RT-Thread + Cortex-M3 + Keil MDK碰撞在一起的时候,火花因它而生,越来越多人使用RT-Thread了,当然这和 RT-Thread厚积薄发是离不开的,因为这个时候,RT-Thread已经有一个稳定的内核,shell方式的调试利器finsh,DFS虚拟设备文件系统,以及 LwIP协议栈。而RT-Thread/GUI则在密集的移植到CM3上,RT-Thread/GUI成型于2008年底,但为了Cortex-M3分支,这个组件停下来很多,但这种停留是值得的。另外就是特别感谢UET赠送的STM32开发板了,RT-Thread/STM32的分支都是在UET赠送的STM32开发板上验证的。
  5、RT-Thread为什么是对象化的设计方法
  可能这个话题太偏技术化了,说说其他,呵呵。
   面向对象编程有它的好处,例如继承。可以让具备相同父类的子类共享使用父类的方法,基本可以说是不用写代码就凭空多出了很多函数,何乐而不为呢。另外,对象的好处在于封装。当一个对象封装好了以后,并测试完成后,基本上就代表这个类是健全的,从这个类派生的子类不需要过多考虑父类的不稳定性。
  这里着重提提另外一个人,我工作后的第三年,曾向当时的同事也是好友,L.Huray学习 面向对象的实时设计方法:Octpus II。深刻体会到了面向对象设计的好处( 需求分析,体系结构设计,子系统分析,子系统设计,测试,实时性分析),但鉴于嵌入式系统中C++的不确定性,所以个人更偏向于使用C来实现。所以,L.Huray算是我的老师了,一直希望能够有时间把他老人家的思想更进一步的发扬光大,希望以后有这个机会。(Octpus I最初起源于Nokia,然后由M.Award, L.Huray发展成Octpus II,现在几乎见不到踪影了,唉)。
(作者原文:实时线程操作系统( RT-Thread)4年开发历程 乐与苦)

简单比较

编辑
1 、任务管理及调度:
RT-Thread - 32/256可选 优先级 抢占式调度, 线程数不限,相同优先级线程 时间片轮转调度;支持动态创建/销毁线程。
uCOS - 256优先级抢占式调度,不允许相同优先级任务存在
2、 同步/通信机制:
RT-Thread - 支持 semaphore, mutex, mailbox, message queue, event。mailbox可存储多条消息,任务等待可按 优先级进行排队。
uCOS -semaphore, mutex, mailbox, message queue, event。mailbox只能存放1条消息
3、 内存管理
RT-Thread -固定分区内存管理,小内存系统动态内存管理,大内存系统 SLAB内存管理
uCOS - 固定大小内存块管理
4、 定时器
RT-Thread - 挂接到系统OS定时器的硬定时器
uCOS - 只能使用 OSTimeDly进行时间间隔处理
5、 中断嵌套
RT-Thread - 允许
uCOS - 允许
6、源码许可证:
RT-Thread - 遵循GPLv2+许可证。可用于商业产品(只需要注明使用了RT-Thread)
uCOS - 商业收费

版本发布

编辑
发布时间:11/04/2014
RT-Thread 2.0.0发布候选版本(release candidate),同时发布v1.2.3稳定版本
随着 RT-Thread功能越来越多,如何发布版本也成为一件头疼的事情,因为需要仔细对比最近三个月来的修改记录。这次的发布距离上一次beta版本依然是三个月的时间,但按照发布计划已然推迟了一个月进行发布。
在这三个月中, 开源社区上也发生了很多有趣的事情:
  • 阿嘉的使用 RT-Thread四轴飞行器毕业设计惊艳亮相,采用了1个STM32F4 + 8个STM32F1进行飞行控制,总计9个MCU的另类实现方式;沿循四轴飞行器的路线,与国内匿名团队合作,采用RW009 Wi-Fi控制的迷你四轴飞行器也在稳步推进过程中。
  • RT-Thread做为一个开源组织参与的 CSDN开源夏令营结出了丰硕的果实:
    • 由hduffddybz参与的IPv6协议栈移植(最新版本的lwIP-head版本移植)在这次发布中已经包括进来,从而能够在使用RT-Thread的小型设备上实现TCP/IP v4/v6双栈的支持;
    • 由wzyy2参与的GDB stub实现,也完美的支持BeagleBoneBlack开发板和STM32F4平台;
  • CSDN开源夏令营其他的成果,例如bluedroid移植也有了初步的成果,希望能够在后续的版本(可能会是2.1.0系列版本?)包含进来。CSDN开源夏令营是一次非常棒的活动,能够让学生提前进入实战,了解软件开发的初步知识。对 开源社区来说,也是一次非常有益的社区互动活动。希望明年这个活动可以继续,关注 RT-Thread嵌入式开发的同学可以关注明年的动向。
当前智能化设备是一个备受关注的领域,针对这一领域的特点,RT-Thread也相应的做出了积极的响应,所以这个版本开始加入sensor的应用框架(APP/算法 <--> sensor framework <--> RT-Thread device driver <--> 硬件外设)。希望在小型化的RT-Thread操作系统基础上融合智能化相关的技术,让 RT-Thread成为这方面可选的OS系统之一。RT-Thread操作系统的sensor框架也尝试新的实现方式,即采用C++的方式来实现(当然也会考虑C方面的兼容,无疑C++的面向对象特性会更好,所以最终选择了C++),在这个基础上也可能融合其他的一些生态技术,例如ARM mbed平台上的一些社区组件技术。所以这个发布版本中既包括sensor框架,也包括了C++底层的一些基础支撑。
这个版本是RT-Thread 2.0.0系列正式版本的候选版本,正式版本预计会在年底正式发布,距离正式版本还会加入更完善的一些支撑(例如各种传感器驱动)。也计划2014年11月22日,在上海浦东举行 RT-Thread嵌入式系统沙龙活动,欢迎大家关注并参与进行RT-Thread方方面面的技术交流。具体时间、地点再另行通知,欢迎关注 @RT-Thread 微博获得最新的消息。

背景成长

编辑
记录下 RT-Thread0.3.x的成长
先解释几个常见问题:
1. RT-Thread从哪里而来?
RT-Thread RTOS, Kernel部分完成于2006年上半年,创始人源于国内一老牌RTOS:DOOLOO RTOS,甚至是BSP 一些结构都源于DOOLOO RTOS。但与DOOLOO RTOS明显不同的是,Kernel完全重新编写,突出的是实时性和小而灵活,并且引入了内核 的对象模型以摒弃 内核对象的与 动态内存管理器无关化。
2. RT-Thread用于商业产品&工程,版权如何界定?
RT-Thread RTOS内核部分完全由我们编写,无其他版权问题,可以放心在商业产品 & 工程中使用。对于把RT-Thread使用于商业产品中,我们承诺永久不收费(使用人拥有使用权,使用用途责任请自行承担)。另外有两点需要注意:
- RT-Thread RTOS代码原始版权属于RT-Thread所有。
- 在商业产品 & 工程中使用RT-Thread RTOS,请在产品说明书上明确说明使用了RT-Thread,如有串口输出,请在系统启动显示RT-Thread的版本信息。如使用了RT-Thread RTGUI,请保留RT-Thread LOGO。
3. RT-Thread RTOS由谁开发,由谁维护?
目前RT-Thread RTOS由国内RT-Thread工作室开发及维护
4. RT-Thread RTOS是否已经在产品中使用?稳定度 & BUG情况如何?
目前已经有数家公司使用RT-Thread RTOS做为他们的系统平台,在上面进行产品开发,稳定性表现不错。
就如同没有100%的完美事物一样,BUG是存在的,反馈上来我们会努力尽快修正。
5. 我能加入到 RT-Thread的开发者队伍中吗?
能!
我们欢迎任何对RTOS感兴趣的人,不管你是学生或资深 嵌入式系统开发工程师。RT-Thread的开发人员通常依赖于论坛、邮件、 GTalk进行联系交流,由于目前上海的开发人员比较多一些,所以会不定期的在上海举行开发者聚会。
6. RT-Thread依靠什么持续发展下去,能够盈利吗?
目前RT-Thread的发展主要依赖于大家的兴趣爱好,大多数都是在业余时间进行开发的。以后会通过技术支持、组件定制、组件开发、辅助工具等 方式进行盈利。从几大开源软件来看,商业支持是软件持续发展不可或缺的一部分,所以我们希望能够有更多的公司选择RT-Thread RTOS做为系统平 台,这个对于公司、对于整个RT-Thread社区都是双赢的局面。对于公司,能够获得免费的RTOS套件,同时也能够推动着这个RTOS套件不断的朝着 稳定的方向发展。对于我们,有公司支持的发展无疑会令RT-Thread的发展更上一层楼,当然也意味着以后的支持费用有着落啦。
=========
问题完了,开始进入0.3.x系列的主题。在对外发布上,相信大家已经看到了, RT-Thread已经进入了0.3.x的密集发布周期。RT- Thread/STM32F103VB已经发布了0.3.0系列的3个beta版本,RT-Thread/STM32F103ZE已经发布了0.3.0系 列的2个beta版本,RT-Thread/LPC2148已经发布了一个0.3.0系列的beta版本。接下来会考虑发布RT-Thread/LM3S 的第一个beta版本(汗一个,刚发过了的板子有些硬件问题,返修了)...
这些版本,大多数上会包含:Kernel + FinSH shell + Filesystem + LwIP等。
0.3.0系列, RT-Thread还包括两大内容:
- 编程指南文档
- RTGUI图形界面系统
编程指南一直在修订,比较遗憾文笔有限,所以文档还请大家不要太挑剔,有什么建议欢迎大家提出来。关于编程指南,还要提一句的是,这份文档是一份 编程的指南,在RT-Thread上编程需要考虑的地方都会提出来。但是,它并不是一份代码分析的文档,虽然它可能会提到内部的一些大致结构框架,但它不 会对代码进行一行行分析,所以请大家多多注意。
另外的RTGUI组件,会是以后的重点任务,目前的打算是在现有的STM32F103ZE开发板上实现一套可用的手持终端设备,当然也依然延续  RT-Thread的习惯,这套东西会以开源的形式释放出来。在 s3c2410/2440上,这套GUI表现得是相当不错的,面向对象的设计,独立的控件 对象模型,留给了用户最大的 可扩展性
其他的,caoxulong的x86分支在整理完毕后也会放到0.3.0这个分支上来,通过这个分支大家可以完全摒弃开发板,在PC或 VMWare/ QEMU上体验RT-Thread。LPC系列分支,苦于目前开发板不足,所以进展慢一些,上次发布的 RT-Thread /LPC2148 0.3.0 beta1也只能包含SD卡、以太网口驱动框架,这个系列会把 wyoujtg/风城少主 的LPC2106的移植合并进 来。
文件系统这块现在代码已经发布出来了,其实里面还包括另外一个分支的:DFS-FAT,这个分支就如同DFS一样,是我们自己编写的,也能够支持NandFlash等介质上的坏块管理,写了很多个测试例子在测,等通过压力测试后会取代目前的DFS-EFSL发布出来。
展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部