[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I want to participate in GSoC from RTEMS
- Date: Thu, 20 Mar 2008 10:36:14 +0530
- From: madhusudancs at gmail.com (Madhusudan C.S)
- Subject: I want to participate in GSoC from RTEMS
The issue at hand is that RTEMS does need the capability
> to give as accurate as possible time stamps at the API
> level. Given that we are lean and mean, we don't waste
> precision -- if it is available at the bottom of the software,
> the user is going to get portable access to it.
> Some background for Madhusudan.
> + Unlike GNU/Linux. Most RTEMS users have their own
> unique hardware platforms and provide their own device
> drivers. Each Board Support Package (BSP) includes a
> clock tick device driver. This is the source of all time
> information in RTEMS.
> + The user writes an application and configures many
> tunable parameters including the nanoseconds per
> clock tick.
+ The BSP's clock tick driver uses this to program the
"This program" confused me a bit. Please help me. Is it the program that I
have to write now or user's application??
+ In RTEMS prior to 4.8, all time was based on the "clock tick".
> When a tick interrupt occurs, the interrupt handler calls
> rtems_clock_tick to "increment the time by the configured
> nanoseconds per tick"
> + In 4.8 and newer, the same use of tick but now we can
> ask the BSP for "nanoseconds since last tick" and get a
> more accurate timestamp. This is an optional capability
> and RTEMS assumes 0 nanoseconds when this is not
> available and you end up with the pre-4.8 time is only
> accurate to a clock tick behavior.
Thanks a lot I understood this part.
+ When this change was made, the internal time structure
> was changed to struct timespec. This is nanosecond accurate
> but terribly inefficient to do math with. Some RTEMS applications
> run on space based hardware which is VERY VERY slow to
> survive radiation. At 10-15 Mhz (YEP!) some time operations
> went up by ~20-30 microseconds. Since we use this to timestamp
> context switches, this is just flat horrible.
> + On 32-bit CPUs, Sixty-four bit math is heavier than 32-bit math
> but it is WAY better than struct timespec math.
Sorry I did not understand this part. How can you do Sixty-four bit math on
a 32-bit CPUs. Please guide me.
> Right now, we just declare struct timespecs in the supercore
> to hold time. In retrospect, this was a bad decision and not
> in keeping with the rest of RTEMS. We usually add "classes"
> and provide very opaque routines to deal with things. So
> this is adding a new class and cleaning up things to use it.
Ok I roughly understood what you are trying to explain me in theory. I
still donno how it can be implemented in the code. I hope that is the whole
part of this project for GSoC, planning and designing how to do it and
accomplishing it through code.
There are 18 files in the supercore which reference
> struct timespec. RTEMS has only 1 function per file.
> A few of those are .h files.
Yeah I saw most of the files. Thanks a lot for giving me the pointers,
otherwise I would have spent a lot of time searching these files.
> This is not a huge project -- but it is a critical one.
> I really want to see this happen and will help you
> write up a proposal.
> FWIW this is important enough that I was tempted to
> start it when I updated the description for SOC.
> It is a critical item.
I hope I can make this project happen this summer. I want to be a part of
RTEMS from now onwards(I think I am already and I hope community would
accept this), not just this summer or during GSoC duration. Please help me
get going guys.
Thanks and regards,
-------------- next part --------------
An HTML attachment was scrubbed...