发新话题
打印

[内核开发] rt-thread 移植

rt-thread 移植

国产嵌入式实时操作系统, 开源软件,使用完全免费

256个优先级,
允许存在相同优先级线程
线程数不限制
允许动态创建/删除线程
支持优先级反转

LwIP协议栈支持
文件系统支持
RTGUI

www.rt-thread.org

大家有兴趣一起把他移植到W90P710来呀

TOP

一定要顶起,下面是RT-Thread的一些介绍,如果对RT-Thread比较熟悉的话,几个小时可以完成移植工作。

RT-Thread RTOS,这是一款由国内RT-Thread工作室开发的开源实时操作系统。起初RT-Thread是一个实时的内核(全抢占优先级调度,调度器时间复杂度O(1)),但在发展过程中,RT-Thread实时操作系统得到了来自全国嵌入式开发工程师的鼎力支持,为RT-Thread添砖加瓦,现在它已慢慢变成一个完善的、全功能的操作系统:文件系统,网络协议栈,图形界面组件。。。只有您想不到,没有您做不到:RT-Thread是一个平台,您可以把您的创意汇聚在一起,小平台大社区,RT-Thread的开发人员就在您的身边。

RT-Thread与ucos比较:
任务管理及调度:
RT-Thread 32/256可选优先级抢占式调度,线程数不限,相同优先级线程时间片轮转调度;支持动态创建/销毁线程
ucos 256优先级抢占式调度,不允许相同优先级任务存在

同步/通信机制:
RT-Thread 支持semaphore, mutex, mailbox, message queue,  event。mailbox可存储多条消息,任务等待可按优先级进行排队。
ucos semaphore,mutex, mailbox, message queue, event。mailbox只能存放1条消息

内存管理:
RT-Thread 固定分区内存管理,小内存系统动态内存管理,大内存系统SLAB内存管理
ucos 固定大小内存块管理

定时器:
RT-Thread 挂接到系统OS定时器的硬定时器
ucos 只能使用OSTimeDly进行时间间隔处理

中断嵌套:
RT-Thread 允许
ucos 允许

源码许可证:
RT-Thread GPL + 可用于商业产品(只需要注明使用了RT-Thread)
ucos 商业收费

体积(典型配置,ARM7TDMI):
RT-Thread 8k ROM, 2K RAM
(RT-Thread/STM32包含完整的STM32固件,体积大些)

RT-Thread主要支持的平台:
STM32F103VB/STM32F103ZE
AT91SAM7S/7X
S3C2410
x86-IA32

RT-Thread/STM32F103VB 0.3.0 beta3更改记录:
- 内核,添加IAR EWARM 5.x工程,在内核定义中做相应的平台定义;
- 添加文件系统组件DFS,DFS是一套虚拟文件系统(类似Linux的VFS,但几乎不占用空间)
- 添加文件系统DFS-EFSL:把著名的FAT文件系统实现EFSL引入到DFS中,同时对它的不足进行修改:重写文件系统缓冲层;添加多扇区读写支持。(我们自己实现的DFS-FAT还在进行压力测试中,测试完毕后也会放出)
- STM32固件库更新到2.0.3patch1

RT-Thread/STM32F103VB 0.3.0 beta2更改记录:
- 修正message queue创建时内存分配的问题。
- 修正pendsv异常优先级过高的问题。
- 更改rt_console_puts为rt_hw_console_output,并由各个board自行实现,如果设置rt_hw_console_output为空函数,那么rt_kprintf将自动不起作用。
- 设备驱动框架中添加两个回调函数,设置回调函数的接口为:
  * rt_device_set_rx_indicate,rx_indicate回调函数在设备驱动收到数据时调用,以通知上层应用有多少字节大小的数据已经接收(上层应用此时可以主动调用rt_device_read进行接收)。
  * rt_device_set_tx_complete,tx_complete回调函数在驱动设备完成数据写入时调用,以通知上层应用数据已经写入完成(如果数据是动态申请的,可以在此时释放)。
设备驱动框架内部相关调用实现:
  * rt_device_open/close,如果驱动设备是DMA接收模式,那么调用open将打开DMA开始进行接收,close则关闭DMA。
  * rt_device_read,设备驱动从设备中读取(轮询模式),或从已经接收到的buffer中读取(接收中断模式、DMA接收模式)
  * rt_device_write,设备驱动往设备中写入数据(轮询模式),或挂接到链表中,等待DMA传输完成(如果当前DMA没使能,那么使能DMA直接进行发送)。
- STM32串口设备,实现在libcpu\stm32\serial.c中,发送支持轮询,DMA发送;接收支持轮询,中断接收,DMA接收等方式。
  * 串口设备的注册在bsp\stm32f103vb\usart.c中,当前默认注册为
    + uart1, 轮询发送,中断接收, 中断接收通知指向finsh,rt_hw_console_output则轮询发送(不产生中断)。
    + uart2, DMA接收,轮询发送
    + uart3, 中断接收,DMA发送
- bsp\stm32f103vb\application.c是几个串口设备的使用例子。

简而言之,RT-Thread/STM32F103VB 0.3.0 beta3是一个RTOS + Shell(finsh) + VFS(DFS + EFSL(FAT16/32)),并且文件系统已在万利STM32开发板SPI SDCard上验证通过(大范围的SD/MMC卡还有待验证)。

有用的链接:
RT-Thread官方网站:http://www.rt-thread.org
RT-Thread官方论坛:http://www.rt-thread.org/phpbb/
内核API在线文档:http://www.rt-thread.org/rt-thread/rttdoc_0_2_3
RT-Thread编程指南(未完成):http://www.rt-thread.org/phpbb/viewtopic.php?f=2&t=195

到目前为止,不管您是使用RealView MDK还是IAR EWARM,您都可以尝试使用RT-Thread。

TOP

RT-Thread + LwIP,强大的优化
如果要在小型设备上跑TCP/IP协议栈,体积无疑是一个重要的衡量指标。如果<1k RAM,毫无疑问uip是首选。
但uip的功能限制也蛮多的,和RTOS配合不是太好(如果要在2K RAM上跑RTOS,估计也够残废了),实时性也比较低(其中关中断用于做数据保护)
但RAM是32K - 64K的系统呢,似乎LwIP和ucip不错。BSD TCIP/IP协议栈就不要想了,RTEMS就是用的BSD TCP/IP协议栈移植,体积是比较庞大的。ecos选择要好些,有LwIP和BSD TCP/IP协议栈的选择。
网上的资料显示,LwIP的体积大约在几十K的RAM和40K左右的ROM,这个和RT-Thread/AT91SAM7X256 0.2.4版本给出的指标是比较一致的,64K SRAM用来跑LwIP,剩余的就不多了(10K左右)。而ucip则绑定到了那个收费的ucos-ii。
RT-Thread 0.3.0版本的协议栈用的依然是LwIP,但做了改进,效果非常明显,而且依然保留了RTOS的特性。RT-Thread 选择LwIP是有原因的,首先是它的功能,其次是它的体积。功能上满足大多数嵌入式设备的需求,同时体积也比较小,在优化的情况下,体积更进一步缩小了。
RT-Thread 0.3.0 + LwIP指标:(无shell,无文件系统的情况,最大32线程优先级)
5K SRAM静态占用,3K RAM动态占用(ping设备时)。
STM32F103VB(128K Flash, 20K SRAM)上跑RT-Thread + LwIP + Web Server没问题。

TOP

RT-Thread 成功移植到W90P745上。等把网络和USB驱动般过去就放上来

TOP

这个可以顶!期待你的745-rt code
请不要在短消息里面问我技术性的问题.
请不要把你的问题作为附件,下载是个很糟糕的事情.
请不要加我的MSN和QQ的时候不标注原因.
欢迎任何热爱和从事嵌入式行业的人与我交流

TOP

效率真高啊......

TOP

[文档] RT-Thread实时操作系统编程指南

官方论坛已经发布了 RT-Thread实时操作系统编程指南初稿(v1.0)

写文档是一个工程师的基本功,但写一份好的文档对一个工程师是一项非常大的考验,很多人觉得RT-Thread缺少文档,希望这份文档能够弥补RT-Thread这方面的欠缺。有什么建议请提出来,希望书中每个地方都能够做到咬文嚼字。对于RT-Thread实时操作系统中不明白的地方也请提出来,这样可以把这部分迷惑的地方加入到文档中进行详细解析,让后来的人更加容易理解。

TOP

来自RT-Thread的朋友,欢迎欢迎!
我一生中最幸运的两件事
  一件,是时间终于将我对你的爱消耗殆尽
  一件,是很久很久以前有一天,我遇见你……

TOP

呵呵,多谢,跑你们地盘混来了。

TOP

原来酷酷的小苦在这边当主管啊,初来匝道还请多多提携:-)

TOP

回复 10# 的帖子

让你见笑了!^_^
我一生中最幸运的两件事
  一件,是时间终于将我对你的爱消耗殆尽
  一件,是很久很久以前有一天,我遇见你……

TOP

当初想参与RT来着,但是没有时间,mcuos也来的少了。现在混linux社区,作华邦arm的linux maintainer,无论来自哪里,大家多多交流。
请不要在短消息里面问我技术性的问题.
请不要把你的问题作为附件,下载是个很糟糕的事情.
请不要加我的MSN和QQ的时候不标注原因.
欢迎任何热爱和从事嵌入式行业的人与我交流

TOP

[公布]RT-Thread代码仓库地址

[公布]RT-Thread代码仓库地址

顺从大家的意见,采用google svn来做为RT-Thread的代码管理仓库,google上项目的地址是:
http://code.google.com/p/rt-thread

包含数个已经发布的bsp,不过目前只包含Keil ARMCC的工程,Makefile可能会大改,所以暂时没放上,需要代码提交权,请联系我。
官方网站:www.rt-thread.org

TOP

引用:
原帖由 osboy 于 2009-7-1 21:31 发表
当初想参与RT来着,但是没有时间,mcuos也来的少了。现在混linux社区,作华邦arm的linux maintainer,无论来自哪里,大家多多交流。
原来是这么着的啊,呵呵,以后还有机会!

初步的了解了一下W90P710,uclinux可能算不上一个很好的配套OS吧,占用资源多,用于做产品很多东西可能还需要自己亲自搭,虽然新唐能够提供配套的uclinux。

最近我在慢慢理理RT-Thread针对内存超过1M的系统。前段时间比较忙,后面几周可能会空闲些,因为单位里应用处理器这一块小组内还比较弱,所以有打算也在上面把一个完整的RT-Thread搭建起来,并加入flash文件系统(还得兼容老的应用处理器上的Linux文件系统),增强finsh shell。如果RT-Thread能够比较好的解决flash文件系统的问题,RT-Thread在W90P710上还是很有比较广阔的空间,再加上原本的GUI、LwIP,小型的应用基本上应该足够了。

哦,对了,tl590,能透露下你的移植基于什么环境吗?Keil ARMCC 还是 GCC?

TOP

对于RT来说,他应该是和ucos,freertos之类的一个级别的RTOS吧,uclinux对系统的需求就大些,看样子rt对内存的需求还比较大,或者说你们把它定位成和uclinux一个级别?

对于我们的 710来说,我移植过ucosii,freertos,uclinux,甚至是t-kernel的BSP都跑过,除了tk之外没有成气候,其他的都有客户在用来出产品了,但是就我们目前另一款比较流行的arm7 NUC501来说就rt-thread跑不起来恐怕,因为只有32K的内存,我在上面用的是freertos和ucosii。

号外:大侠们都从哪过来的?看来和兄弟小苦很熟?
我也曾经热爱写自己的rtos,也出了几个版本,不过没有坚持下来,因为要作的事情太多。
请不要在短消息里面问我技术性的问题.
请不要把你的问题作为附件,下载是个很糟糕的事情.
请不要加我的MSN和QQ的时候不标注原因.
欢迎任何热爱和从事嵌入式行业的人与我交流

TOP

32k不能跑RT-Thread?呵呵,RT-Thread的资源需求是:8k ROM,2K RAM。

目前已经有用户在STM32上用RT-Thread做产品了,一般是20K RAM,大一些的话是64K RAM。例如上面shaolin说的:
RT-Thread 0.3.0 + LwIP指标:(无shell,无文件系统的情况,最大32线程优先级)
5K SRAM静态占用,3K RAM动态占用(ping设备时)。
STM32F103VB(128K Flash, 20K SRAM)上跑RT-Thread + LwIP + Web Server没问题。

另外,RT-Thread和ucos、ecos技术指标的对比情况:
基本任务测试 RTT/ecos 1.40倍,RTT/ucos 1.00倍
协作调度测试 RTT/ecos 1.20倍,RTT/ucos N/A (ucos不支持协作式调度)
抢占调度测试 RTT/ecos 1.33倍,RTT/ucos 1.38倍
同步处理测试 RTT/ecos 1.86倍,RTT/ucos 1.44倍
中断处理测试 暂时无数据
中断抢占测试 暂时无数据
内存分配测试 RTT/ecos 2.50倍,RTT/ucos 1.28倍

体积上5项测试上,RTT/ecos 0.65倍,RTT/ucos 0.30倍
即,RTT只有ecos 0.65的体积大小,ucos 0.30的体积大小

结论是在相同环境下运行ThreadX的Benchmark套件得出的,相同的硬件环境,相同的编译器,相同的优化选项,相同Benchmark代码。

这套benchmark基本的设计原则是在相同的时间内做一个计数值递增。例如做切换测试:运行多个线程,让它们做切换,然后在各自的上下文环境中做计数,一定时间后得出计数值的多少。这样比较各个系统的计数值情况得出结果。大体思路是这样,具体代码我没仔细看。

基本任务测试 RTT/ecos 1.40倍,RTT/ucos 1.00倍
这个意思就是,RTT的计数值是ecos的计数值1.40倍,ucos的1.00倍

例如相同时间内,RTT的是1400次,ecos是1000次,ucos是1401次。

TOP

RT-Thread是设计成可拆卸可剪裁的,所以也能够支持一些内存比较大的系统。特别是内存大了后,内存管理器将转而使用一个优化过后的slab内存管理器,这个内存管理器的分配速度是非常恐怖的(对linux熟悉应该会知道,源于相类似的算法),速度都快赶过固定内存池分配速度了。

另外就是目前RT-Thread的GUI组件只能支持framebuffer的方式,也只能在内存大一些的系统上使用。

目前针对于内存丰富一些的系统,个人感觉优化还不够,所以才会在上面继续做优化,需要在一些关键的地方使用红黑树、hash表等一类的基本优化算法。不管最终RT-Thread发展成如何,它都会依赖于其中的rtconfig.h配置文件,对各种组件做剪裁,形成一套细粒度、全功能的实时操作系统。

TOP

发新话题
最近访问的版块