This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Changing system timer resolution
- From: Grant Edwards <grante at visi dot com>
- To: Gary Thomas <gthomas at redhat dot com>
- Cc: Jurica Baricevic <jura at INTESIS dot hr>,eCos Discussion <ecos-discuss at sources dot redhat dot com>
- Date: Wed, 28 Nov 2001 11:39:59 -0600
- Subject: Re: [ECOS] Changing system timer resolution
- References: <NFBBJGOLDDDGJPLCMJKNCEIFCCAA.jura@intesis.hr> <1006968670.7768.10.camel@hermes>
On Wed, Nov 28, 2001 at 10:31:07AM -0700, Gary Thomas wrote:
> > > It would be awfully nice if there were a simple way for an
> > > application to determine the system timer tick resolution (e.g.
> > > macros/functions to convert back and forth between
> > > seconds<->ticks and ms<->ticks). I know this information is
> > > available, but it's buried pretty deeply and is difficult to
> > > use.
> >
> > I absolutely agree with the statement above. Currently, I am using some
> > "home-made" calculations and macros in my applications (i.e. for
> > cyg_thread_delay()) and they look quite awkward. Some 'easy to use'
> > conversion between real time and system tick in any form (API, macro) would
> > be quite useful.
>
> > Digression:
> > Also, it would be nice to have some high-resolution performance counter for
> > more precise time handling. For example, microsecond handling is quite
> > common in today's RTOS applications. The high-resolution counter shouldn't
> > be limited by system timer tick resolution, but with the underlying hardware
> > clock resolution.
>
> This is already available using the HAL_CLOCK_READ() functionality.
> Look for examples of how to use it in the 'tm_basic.cxx' test program.
I think that only solves one side of the problem. The other
side is when you want an event to happn 7354us from now.
--
Grant Edwards
grante@visi.com