Clock and Hardware Timer usage

[gregory.menke at gsfc.nasa.gov]

Victor V. Vengerov writes:
 > Cederic,
 > 
 > Cedric Aubert wrote:
 > 
 > >
 > >To me, hardware need to RTEMS for all software kind of
 > >use :
 > >
 > >- one varying HW interval timer
 > >- one RTC
 > >
 > >That all.
 > >
 > I have missed part of discussion, but I'll add my 2 kopeyki.
 > 
 > Consider following:
 > - not every hardware has RTC, although it may keep clock
 >   (think about CD/cassete player which is running in low-power
 >    mode when turned off and handle timer interrupts to keep
 >    clock)
 > - Frequently, RTC chip has so simple interface that it is hard to
 >   use from software efficiently. There are   many RTC chips
 >   which are I2C/SPI accessible. Access to them is slow enough
 >   to perform it in everyday operations. I beleive, even access to
 >   PC clock may be slow enough: although it has simple I/O port
 >   interface, actual delays may be hidden in hardware.
 > 
 > So, even if your concept is correct, it may be hard to apply it
 > to the current state of technology.
 > 
 > Please, sorry if my comment do not fit into context of this
 > discussion: I have not read/understand it completely.

My interpretation is he's suggesting that wall-clock related timer
functions should operate off a different timer than the OS time quanta
tick.  I think this suggests each bsp would make a decision on how to
implement it, either continue to use the time quanta tick or use some
local RTC function or alternative timer to do it.  To me the problem
seems to be there are no cross-bsp guarantees that anything better
than the OS quanta tick will be used.  However, I think it might be
useful to decouple application timer manipulation from the time quanta
ticks. 

Gregm