Clock and Hardware Timer usage

[Cedric Aubert]

> > So each time we need TOD we read the timer, no
need to
> > read again the RTC or
> > may be sometime.
>
> To simplify math, would this RTC tick source produce
a 1 Hz
> tick?

No need for this. Or I don't see why for synchronise
RTC and TOD ?
If is this, to often sync for my opinion.
If it's a increment the TOD, you should have a TOD
with a precision
of 1s, very bad TOD in my mind, TOD could have a
precision of the ns, did it
?

>
> Remember that RTEMS has "interval timers" and "TOD
timers".
> You can schedule an event for a "when".  And that is
> (I think) always considered to be a second boundary.
> See rtems_task_wake_when() and
rtems_timer_fire_when() for
> examples.
>

Ok.

> Having a more accurate TOD is a big deal.  And
having the
> ability to update TOD separate from interval timers
could
> be a big deal.

It is exactly what I have in mind. HW RTC have
(frequently)
a precision of 1 second. HW Timer have some ms or ns
precision.

>
> Right now, cpukit/score/src/coretodtickle.c is
assumed to
> run once per second.  It is scheduled using the
ticks
> watchdog chain.  Having the ability to have a 1 Hz
> separate event to update TOD and getting partial
seconds
> from a HW device might be an improvement.  It would
trade
> off the overhead of managing the per_second_handler
with
> the overhead of taking another interrupt once per
second.

Ok it's mandatory to have a HW Timer IT (IRQ) at the
half
of the max value of the timer, to assume rollover of
the timer.
We could use this lowest frequency interrupt to assume
the TOD
increment. May be more or less than a second, depend
of the HW Timer
in my mind, it's not important here for the TOD
because in my mind
when we need TOD, we should read the current HW Timer
value to
update TOD. So TOD should be at 1 ns precision.

>
> I have always had a gut feeling that supporting a
varying
> HW interval timer that we could reprogram based upon
the
> number of ticks until the next event would be the
biggest
> win.  Then there wouldn't be any "tick interrupts"
until
> you really had one.  The cost would be that any time
the
> head of the ticks chain was altered, the HW timer
would have
> to be reprogrammed.  With TOD processing enabled,
this could
> reduce the interrupt rate for ticks down to once per
second
> with no other events.

In fact it's exactly what I want to do. Ok each time
we need to
reprogramme the HW timer IT value. But it's very more
optimize
compare to have a periodic IT Timer at 1 ms or less.

>
> I suppose it is also possible to change the TOD
behavior so
> it is more optional.  Right now, it is always
running even if
> no onen ever uses it.

Each time RTEMS need TOD (or USER) we read the HW
Timer (not the RTC each
time)
for have a TOD with a precision at ns.

To my mind :

- Read RTC only one time at boot up. -> Write RTC
Value to TOD ( at 1 sec )
- Should have at less a interrupt at a half of the max
HW Timer Value (to
assume rollover). -> Update TOD ( at 0.5 Max value )
- Write TOD by System -> Write TOD from param ( at 1
ns ), Write TOD to RTC
( at 1 sec )
- Read TOD by System -> Read Current HW Timer Value to
Update TOD ( at 1
timer step )


It should be optionnal usage of timer and the TOD of
course.
Because compatibility with old BSP should be a big
deal.

Sincerely


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com