Re: [ECOS] Changing system timer resolution

[Jesper Skov <jskov at redhat dot com>]

On Mon, 2001-12-03 at 17:16, Grant Edwards wrote:
> 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.

I think all you really need is duplicate the existing kernel RTC setup,
but use a higher frequency interrupt to drive the DSR doing the
clocking. All the infrastructure is in place - the only thing needed is
the code to setup the details (and of course the necessary interrupt
source on the platform).

The kernel 100Hz clock will still drive timeslicing - but alarm
scheduling would (I think) happen whenever the scheduler lock is
released and a new high priority thread is ready to run. All you have to
do is be careful about selecting the correct thread priorities.

Uh, or so I would think... :)

Jesper