From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Skov To: "Pamulapati, Indrasena (CTS)" Cc: Jesper Skov , ecos-discuss@sources.redhat.com Subject: RE: [ECOS] Suitability of eCos Date: Tue, 16 Jan 2001 04:52:00 -0000 Message-id: <14948.17360.591260.628772@thinktwice.zoftcorp.dk> References: <8F1D166D08ACD41196EE00B0D020944B82983A@CTSINENTSXUB> X-SW-Source: 2001-01/msg00256.html >>>>> "Pamulapati," == Pamulapati, Indrasena (CTS) 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