This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Suitability of eCos


Hi Jesper,

Yes, the tick duaration controls the kernel scheduler and I dont need
scheduling at that rate.
But does'nt the tick duration also determine the smallest addressable time
unit.
What i mean is:

Let us consider the duration of a tick to be a reasonable value of
10millisec.
Now, if I want to send some data at, say 20ms from the start of a reference
point,
I will give a delay of 2ticks from the reference point and as u mentioned
send an interrupt to the driver after 2ticks.

Now, what if I want to send the data after 1 ms from the reference point. I
will not be able to specify the number of ticks I have to wait if tick
duration is 10ms. So what I thought was, I can decrease the tick duration to
less that 1ms, say 0.5ms and give a delay of 2ticks and then send the
interrupt. But this I guess will adversly affect the performance of the
system.

Jesper, actually I am quite a newbie wrt drivers and rtos's.
	Can you elaborate on
	 "Drivers doing IO should be driven separately, relying on device
interrupts, not scheduler interrupts, for state transitions." based on the
problem I mentioned above. I guess this may solve my problem.
 
Regards,
Indrasena

  

> -----Original Message-----
> From:	Jesper Skov [SMTP:jskov@redhat.com]
> Sent:	Tuesday, January 16, 2001 4:14 PM
> To:	Pamulapati, Indrasena (CTS)
> Cc:	ecos-discuss@sources.redhat.com
> Subject:	Re: [ECOS] Suitability of eCos
> 
> >>>>> "Pamulapati," == Pamulapati, Indrasena (CTS)
> <pindrase@chn.cognizant.com> writes:
> 
> Pamulapati,> the overhead involved in processing the tick.  But my
> Pamulapati,> application requires tick duration as low as a
> Pamulapati,> 100microseconds. I need to address such low time
> Pamulapati,> resolutions.
> 
> As Ramana pointed out, the tick duration controls little more than
> the kernel scheduler in eCos. Surely you don't need thread scheduling
> at that rate!?!
> 
> Drivers doing IO should be driven separately, relying on device
> interrupts, not scheduler interrupts, for state transitions.
> 
> But without further information about your application my comments
> above are just guesses and may not actually apply...
> 
> Jesper

This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly 
prohibited and may be unlawful.

		Visit us at http://www.cognizant.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]