Clock and Hardware Timer usage

[Joel Sherrill]

Cedric Aubert wrote:
> 
> > > 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
> ?

It isn't for synchronization or precision.  It is to
fire events that occur on second boundaries.  RTEMS has
interval based timers and wall-time based timers.  Without
updates to the wall-time side of the internal timers, 
you won't trigger events.  For example, these two services
require this type of input:

http://www.oarcorp.com/rtemsdoc-current/html/c_user/c_user00078.html
http://www.oarcorp.com/rtemsdoc-current/html/c_user/c_user00137.html

When a user actually obtains the time, it is OK to get the
at least the fractional portion of the system time from
hardware.

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

That's OK for gets and sets but misses events triggered from
wall-time.  

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

Agreed.

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

Whatever portion of the TOD is obtained from the 
hardware timer should be the same regardless of
hardware.  So there should only be two modes of
operation -- fractional portion updated in software
and fractional portion maintained in hardware.

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

This sounds right for a separate TOD timer except the
need to do something about the timer events that can fire
on 1 second boundaries.  The above gives you a separate TOD
timer which maintains an accurate TOD.

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

That is the big deal.  And the scheme for doing this should
(somehow) not add burden for not using it.  Hopefully it is
a BSP choice that is clear to make.

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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985