[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google SOC project tinyRTEMS
- Date: Sat, 22 Mar 2008 10:16:53 +0800
- From: rayx.cn at gmail.com (Ray)
- Subject: Google SOC project tinyRTEMS
Hi, YanMiao, Joel Sherrill
I can offer some help in this ?tiny? project if any students interested in this.
I believe Joel also implied that we also need add some configure options that a user can choose from when he|she want to enable the file system extra. If we accomplish the 3 topic Joel gave, RTEMS can be as small as uC-OSII in a 32-bit system.
BTW, there might something else to do e.g. 8bit or 16bit Object-ID. In a word, we want the RTEMS a more configure-able system.
We can break the work done and make some schedule for this.
Just keep in mind, the application will be frozen in Mar.24, hurry up!
Thanks & Best Regards!
Ray, rayx.cn at gmail.com
----- Receiving the following content -----
From: Joel Sherrill
Time: 2008-03-21, 21:17:43
Subject: Re: Google SOC project tinyRTEMS
>> Hello all,
>> I am interest in tinyRTEMS project, I have read the wiki page,
>> and there are a lot of work has been done. I would like to know what
>> is the direction of Tiny RTEMS project.
>As stated, its goal is to shrink the minimum footprint of an RTEMS
>and a number of issues have already been addressed. Many of the issues are
>fairly subtle and if you are new to RTEMS might be hard to figure out.
>One of the larger issues left and probably the only one worth even thinking
>about as a GSOC project are the last three on the list.
>*disable newlib reentrancy (which might already be partially there)
>*"device table filesystem". Functionality similar to how device names were
>handled in RTEMS 4.0.0. Now we have a real POSIX style filesystem with
>devices. Then we had a lookup table which mapped device names into
>major/minor. So when you call open(), the device name isn't looked up
>in a filesystem, it is looked up in a table of strings.
>Many of the TinyRTEMS ideas require the addition of application time
>configuration to select the run-time capabilities. This one is a bit harder
>because it spans the IO and filesystem infrastructure. You will have to
>the size of the minimum, hello and ticker executables and work to eliminate
>filesystem code you are replacing with a lighter alternative.
>In minimum, you want to push to have NO filesystem and IO code.
>In hello, you want the "device name lookup".
>Together the list above looks to be about 1/3-1/2 of the code in the minimum
>executable on the ARM/Thumb rtl22xx_t BSP I use as a reference. So even
>you might only save 8-12K total, you are moving from ~24K to 12-16K minimum.
>Does that make sense?
>NOTE: Many space based systems using RTEMS do not use the filesystem and
>hack it out anyway. This is just providing this reduced functionality
>a real configure option.
>> rtems-users mailing list
>> rtems-users at rtems.com
>Joel Sherrill, Ph.D. Director of Research & Development
>joel.sherrill at OARcorp.com On-Line Applications Research
>Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
>rtems-users mailing list
>rtems-users at rtems.com