Clock and Hardware Timer usage

[Joel Sherrill]

Cedric Aubert wrote:
> 
> Hi,
> 
> I have some question about the use of hardware timer
> by RTEMS.
> 
> I read documentation (4.6.0pre2) of the timer, clock
> and rtc.
> 
> To work, I have understand that :
> 
> - RTEMS need a tick OS (for example 10ms but hardware
> timer can have 1ms or
> less resolution).

I think this is a possibility I have considered in the past.
There are a handful of possible requirements here so let's
see if I can state them all and see what the goal is.

  + one timer for wall-time/TOD updates
  + another timer for timeouts
  + syncing wall-time TOD to RTC HW

A simple starting spot for a solution is to divide the current 
rtems_clock_tick() into two routines (names are up for discussion): 

  + rtems_clock_tick_TOD() 
  + rtems_clock_tick_intervals()

Leave rtems_clock_tick with its current behavior for compatability.
A BSP will either call the current tick or the pair of the above if
it has independent timers.

The bigger problem is that there is an assumption of one tick 
quantum and both delays and TOD operations are based upon the 
same quantum.  It all goes back to the configuration table
parameter microseconds_per_tick.  I think you would have to 
do some analysis to make sure that you don't have a bigger
problem.  It is possible that it might require two time quantums
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.

--joel