Clock and Hardware Timer usage
cedric_aubert at yahoo.fr
Tue Jul 1 15:23:57 UTC 2003
Thanks for your respond.
> I think this is a possibility I have considered in
> There are a handful of possible requirements here so
> see if I can state them all and see what the goal
> + one timer for wall-time/TOD updates
> + another timer for timeouts
> + syncing wall-time TOD to RTC HW
In fact, I think, but may be I am wrong, that one of
the best solution will
- one timer for timeslice (only for periodic task on
- one timer for timeouts
- TOD should not depend of the tick count, but only on
RTC + the current
value of a timer
To be sure I am right in my explanation, ticks for me
it's the number of
timer IT(Timer IRQ) since the
system boot up.
So each time we need TOD we read the timer, no need to
read again the RTC or
may be sometime.
for the both timer, the "timer for timeslice" should
have a periodic IT for
example 10ms or other
depend of need.
The "timer for timeout" should not have a period IT
like the first, so no
ticks count for this one.
They are no sence to count a number of this timer IT
if it isn't periodic.
But use this timer
only for the upper priority timeout (of course the
And an other solution, should be very good to lower
performance system, it's
to have only the
"timeout timer" and program the timeslice period with
a timeout like the
other timeout in fact.
- Only one timer (like now)
- Can have TOD the best resolution possible (timer
resolution can't do more
- Can have better resolution for timeout without
For example (with one 1ms timer step) :
- Timeslice period at 10ms
- Timeout at 1ms step
- TOD at 1ms
> A simple starting spot for a solution is to divide
> rtems_clock_tick() into two routines (names are up
> + rtems_clock_tick_TOD()
> + rtems_clock_tick_intervals()
Still be period for the both, still have a performance
little CPU system.
> Leave rtems_clock_tick with its current behavior for
> A BSP will either call the current tick or the pair
of the above if
> it has independent timers.
I don't really understand what you mean below, may be
my RTEMS knwonledge
is to poor. :-)
> The bigger problem is that there is an assumption of
> quantum and both delays and TOD operations are based
> same quantum. It all goes back to the configuration
> parameter microseconds_per_tick. I think you would
> do some analysis to make sure that you don't have a
> problem. It is possible that it might require two
> to be specified.
> Also there is a "ticks watchdog chain" and a
"seconds watchdog chain".
> The processing of the seconds watchdog chain will
have to be tied to
> the TOD timer not processed as an element of the
ticks chain every
> "ticks per second".
> It sounds complicated but I think it is just a
matter of getting
> a few core things reworked correctly.
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
More information about the users