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: Jonathan Larmour <jlarmour at redhat dot com>
- Cc: Nick Garnett <nickg at redhat dot com>, ecos-discuss at sources dot redhat dot com
- Date: Mon, 3 Dec 2001 10:16:17 -0600
- Subject: Re: [ECOS] Changing system timer resolution
- References: <NFBBJGOLDDDGJPLCMJKNCEIFCCAA.jura@intesis.hr> <1006968670.7768.10.camel@hermes> <3C083779.1BA45145@redhat.com> <wwgy9kkcz0r.fsf@balti.cambridge.redhat.com> <3C0B72B8.BE286B54@redhat.com>
On Mon, Dec 03, 2001 at 12:40:24PM +0000, Jonathan Larmour wrote:
> > > I think I'd probably accept a (carefully written) patch avoiding the
> > > problems I mention above.
> > >
> >
> > What we can do now is add a simple convertor that takes a time in
> > seconds and nanoseconds and converts it to ticks. A convertor in the
> > opposite direction would be good for completeness, but is not as
> > useful. There are already such convertors in the POSIX package.
>
> I thought we were talking about _sub_-tick resolution? And gettimeofday-ish
> functionality?
I think we're talking about several different things at this point:
1) Changing the tick period and having everything "just work"
2) Providing converter routines for use when you don't know at compile
time what the tick period is.
3) Providing sub-tick read-current-time resolution.
4) Providing sub-tick event/alarm scheduling.
It sounds like 1) is already there, 2) isn't hard, 3) is already there.
However, 4) is hard if you try to use the eCos clock/timer system. If
somebody really does need 4) the easiest thing may be to use a dedicated
hardware timer and a custom driver that maintains a linked list of
delay/event pairs.
--
Grant Edwards
grante@visi.com