Clock and Hardware Timer usage

Cedric Aubert cedric_aubert at
Wed Jul 2 07:19:38 UTC 2003

> > 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
> 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.


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

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

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

Ok it's mandatory to have a HW Timer IT (IRQ) at the
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
> HW interval timer that we could reprogram based upon
> number of ticks until the next event would be the
> win.  Then there wouldn't be any "tick interrupts"
> you really had one.  The cost would be that any time
> 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
> 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
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
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
Because compatibility with old BSP should be a big


Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

More information about the users mailing list