[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Clock and Hardware Timer usage
- Date: Thu, 3 Jul 2003 08:48:32 -0700 (PDT)
- From: cedric_aubert at yahoo.fr (Cedric Aubert)
- Subject: Clock and Hardware Timer usage
> -----Original Message-----
> From: gregory.menke at gsfc.nasa.gov
[mailto:gregory.menke at gsfc.nasa.gov]
> Sent: Thursday, July 03, 2003 5:02 PM
> To: cedric_aubert at yahoo.fr
> Subject: RE: Clock and Hardware Timer usage
> Cedric Aubert writes:
> > >
> > > My interpretation is he's suggesting that
> > related timer
> > > functions should operate off a different timer
> > the OS time quanta
> > > tick.
> > Yes, should be that, or more interesting use the
> > HW Timer for walltime
> > and OS time quanta tick with some timer queue
> > management.
> I think it would be a mistake to further involve the
OS quanta tick in
> TOD issues as the OS tick is fundamentally critical.
It's exactly what I don't want to do. The TOD is not a
we only had to read in the HW counter timer current
value to increase
TOD ticks without increase the OS tick for critical
But can't increase TOD without HW counter timer,
should be with
OS tick resolution only without a counter.
> > > I think this suggests each bsp would make a
> > on how to
> > > implement it, either continue to use the time
> > tick or use some
> > > local RTC function or alternative timer to do
> > Should be for compatibility reason mandatory to
> > choice of how to
> > use the HW Timer, periodic IT like known, or
> > IT period.
> > For me the concept of RTC is simple. I think that
> > RTEMS have it today.
> > Read HW timer to update TOD, when you need it, is
> > easy.
> Sure, but the problem is how to manage accuracy on
all the different
> boards. Perhaps it would be enough to specify some
> interval, say seconds- leaving systems with
appropriate hardware to do
> better. Then systems with no RTC or other timer
resources could still
> base their TOD off the quanta tick
Yes that is what I have in mind. Read my other email
> > > To me the problem
> > > seems to be there are no cross-bsp guarantees
> > anything better
> > > than the OS quanta tick will be used.
> > I don't really understand what you mean here.
> > for my english :-)
> I'll try another way. Each bsp would have to
implement the TOD timer
> ticks and RTC support on the local hardware, so it
will be important
> to ensure each implementation of the TOD timer meets
> This seems like a device driver kind of issue.
Perhaps it could be
> implemented as a task that sleeps on hardware timer,
calls the user's
> TOD functions and manages whatever local RTC
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!