Re: [ECOS] Changing system timer resolution

[Jonathan Larmour <jlarmour at redhat dot com>]

Nick Garnett wrote:
> 
> Jonathan Larmour <jlarmour@redhat.com> writes:
> 
> > Nick Garnett wrote:
> 
> > > Well, any public conversion routines should clearly use the clock
> > > convertors, and not reinvent it all. The POSIX library does exactly
> > > this.
> >
> > The convertors are primarily intended for converting ticks of a certain
> > frequency into ticks of a different frequency, but I suppose this could at
> > least make something that works.
> 
> Not at all. Take a look at the POSIX code for how they are used to do
> arbitrary time conversions.

What it wouldn't make something that works? ;-) I was agreeing with you :).

> >
> > Except that functions like gettimeofday() are meant to be fast, and the
> > paranoia of the clock convertors (because they don't know the order of
> > magnitude of either resolution - the convertor or converted) is overkill in
> > this situation.
> 
> There are no execution time requirement on gettimeofday(), it is not
> meant, in UNIX/POSIX, to act as a realtime timer.

Yes, but it provides an interface we can use to do this. And people do
assume that gettimeofday() is fast. People use it so much in timing loops
that it needs to be.
 
> All the paranoia is in creating the set of factors to use, which you
> do once. The actual conversion is just a set of multiplies and
> divides, and is as fast as the ALU can go.

True. Fairy nuff.
 
> > > The issues in getting a better-than-interrupt-frequency clock
> > > resolution are many and complex, it is not amenable to a quick fix,
> > > but requires a major restructuring of the whole eCos
> > > timer/clock/alarm/timeout mechanism. I would not like to see some
> > > ad-hoc implementation cobbled together to do this. hal_delay_us() is
> > > designed to operate only in polled systems, where interrupts are
> > > disabled - either in redboot or device driver ISRs.
> >
> > No it isn't! :-) Have a look in hal/common/current/src/hal_if.c.
> 
> There is no way that the code there can deal with the accuracy issues
> I mentioned. It does not cope with what would happen if this code were
> preempted for more than one (eCos clock) tick.

Yep, I agree, but I don't think it's quite as bad as you think. You can
schedule an alarm for interrupt tick time minus two and then busy
HAL_CLOCK_READ until you get there. If you're pre-empted then, well, that's
just tough and a "feature" of real-time systems.
 
> Sub-tick resolution is not something we can address now, I would
> oppose the incluson of any quick fix to do this. If users want to
> cobble something together themselves, so be it, but I don't want it in
> the main sources. The kernel APIs are all designed to work in ticks,
> adding random bits of API that work in other units is inconsistent and
> would be incompatible with future plans.

Then we'd need to have some future plans for them to be incompatible with
;).
 
> As far as gettimeofday()-like functionality is concerned, that would
> require proper wall clock support, which is not present in all
> platforms.

A lot of times I see gettimeofday used, it is for when a program to manage
time-related things itself (although I tend to see this more on *nix
systems). As such, only relative offsets are frequently required.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine