From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Edwards To: "Pamulapati, Indrasena (CTS)" Cc: Jesper Skov , ecos-discuss@sources.redhat.com Subject: Re: [ECOS] Suitability of eCos Date: Tue, 16 Jan 2001 11:26:00 -0000 Message-id: <20010116133059.A18824@visi.com> References: <8F1D166D08ACD41196EE00B0D020944B82983A@CTSINENTSXUB> X-SW-Source: 2001-01/msg00268.html 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