RE: [ECOS] Suitability of eCos

[Jesper Skov <jskov at redhat dot com>]

>>>>> "Pamulapati," == Pamulapati, Indrasena (CTS) <pindrase@chn.cognizant.com> writes:

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

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

If you want to busywait, use the uS delay function instead.

But as Björn Stenberg pointed out, you probably want a high-speed
timer to driver things instead of relying on the kernel scheduler
timer.

Pamulapati,> Jesper, actually I am quite a newbie wrt drivers and
Pamulapati,> rtos's.  Can you elaborate on "Drivers doing IO should be
Pamulapati,> driven separately, relying on device interrupts, not
Pamulapati,> scheduler interrupts, for state transitions." based on
Pamulapati,> the problem I mentioned above. I guess this may solve my
Pamulapati,> problem.
 
If you want to do something from a reference point, in context of a
real-time OS, isn't that something pushing data out or reading data
from some device? Audio for instace?

Anyway, most hardware controllers that deal with large amounts of
data throughput have means to interrupt the CPU on completion of a
task. That is, instead of doing this:

 CPU:  send data1, wait 20ms, send data2, wait 20ms, send data3...

(which I think is what you suggest) you get:

 CPU:  idle.......|            | idle.... | 
 IRQ:               send data1              send data2

device interrupt: X                       X


Hope that makes sense. In words: when the CPU is interrupted, send the
next datum. When not sending data, the CPU idles.  Whether that
interrupt comes from the driver handling the data, or a high-speed
timer doesn't really matter.

Jesper