Re: [ECOS] Changing system timer resolution

[Jonathan Larmour <jlarmour at redhat dot com>]

Nick Garnett wrote:
> 
> Jonathan Larmour <jlarmour@redhat.com> writes:
> 
> > I think some care would need to be taken that overflow, underflow and loss
> > of precision is avoided though - there can be both very big and very small
> > numbers involved! Look at the hoops the "clock convertors" have to go
> > through in kernel/current/src/common/clock.cxx for example! Although it
> > wouldn't be as extreme as that fortunately.
> 
> 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.

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.

> > I think we are pretty close to that in the delay_us function (currenbtly it
> > is purely a busy poll). The only problem is that that function doesn't have
> > an exposed (kernel C) API. As Jurica mentions, perhaps gettimeofday() would
> > be adequate, although by doing that, you'll probably pull in POSIX baggage,
> > so for now a kernel C API function may be better. "All" it would have to do
> > is call CYGACC_CALL_IF_DELAY_US(usecs) from hal_if.h. Although that does
> > rely on virtual vector support. Hmm...
> 
> 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.

The only optimization would be what I suggested before which is to delay
for a number of whole clock ticks first until woken up, before using
HAL_CLOCK_READ in a busy loop type way.

> > 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?

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