Re: [ECOS] Suitability of eCos

[Grant Edwards <grante@visi.com>]

On Tue, Jan 16, 2001 at 05:34:01PM +0530, Pamulapati, Indrasena (CTS) wrote:

> But does'nt the tick duration also determine the smallest addressable time
> unit.

Maybe not.

If you've got an extra hardware counter/timer, you can generally
configure it to cause an interrupt at a particular point in the
future.  The resolution of that "delay" period is determined by
the counter hardware and is independant of the rate at which
system-tick/scheduler interrupt occurs.

The most convenient situation would be to have a seperate
timer/counter for each possible parallel usage, but it's also
possible to simulate multiple counters by keeping a list of
pending delays and at each interrupt, set up the counter for
the interval until the next pending delay is to expire.

This technique will provide an interrupt at the end of each
delay period with extremely good accuracy without generating
excessive overhead.

You can start data transfer directly in the counter/timer ISR
or you can wake up a task and have it initiate the transfer.
Tasks waiting on events from ISRswill wake up whenever they
need to (assuming they are the highest priority runnable task)
independant of when the system-tick/scheduler interrupts happen.

Writing a "delay" device driver with a simple API which
consists of a single entry-point which blocks for a specified
period of time would be a fairly straight-forward task if you
wanted to try to isolate the various device drivers from each
other by passing control through user-tasks..

-- 
Grant Edwards
grante@visi.com