> ----------
> From: [EMAIL PROTECTED][SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 26, 1999 7:23 AM
> To: Basham, Richard R
> Cc: 'RT-Linux'
> Subject: RE: [rtl] [Q] About achieving 1 mks of execution period
>
>
>
> On Tue, 26 Jan 1999, Basham, Richard R wrote:
>
> > I have ported a few real time DOS programs to RT Linux and it is
> > fairly easy once you have the RT Linux machine setup. I won't go into
> > all of the details of setting up the Linux machine because there are
> > many steps involved. However, the instructions are clear. Here is the
> > basic outline of converting a real time DOS program. I won't go into
> > the details because they a presented quite well in the examples
> > provided with RT Linux.
>
> Well, I have one RT Linux box already ;)
>
> >
> > 1. I am assuming that you have been using hardware interrupts to get
> > 1ms periodic rates for the real time portion of your task. All you
> > have to do is put the real time part of your dos code into an RT
> > module. Creating an RT module is explained quite clearly in the
> > examples provided with RT Linux.
>
> Ok, which is better on your opinion to get an hardware interrupt or to
> make a single periodic task ? In which case there will be the shortest
> execution time ?
>
>
I have found that the periodic task scheduler works quite well for 1 ms tasks where
the task runs in the 250 us time frame. This leaves machine time for other tasks.
However, if you are looking for absolute best possible speed interrupts are better.
In a previous e-mail sent to this board it was determined that there is a way to speed
up interrupt handling also. The following is an excerpt from that e-mail. This is
the result of a long discussion so you might want to go back and read the chain of
messages.
****** start of other e-mail *********
>> I ran the same test on exactly the same hardware (dual boot) running LynxOS.
>> With LynxOS the time between IT Handler and RT_Task (that is a kernel thread
>> for LynxOS) is in the range 10-15 usecs. [20-25 for RTL].
>> My question is then, is there any possible optimization in the rt_sched
>> to get a better response time ?
>
>It's most likely the unecessary timer overhead in the scheduler -- uncessary
>for your example.
>Try putting rt_set_periodic_mode (LATCH) into your example init code.
>
>You are using 9J right?
I tried it! Worked GREAT!!!!
The scheduler latency time went down to a 3-5 usecs, which is just plain great.
Thanks a lot for the hint!
--
Frédéric.R.R.Roussel
Sr.Software Engineer -°) (°-
[EMAIL PROTECTED] /\\ Join the penguin force //\
(650) 286 7208 _\_v The Linux G3N3R4T!ON v_/_
********** end of other e-mail **********
> >
> > 2. The foreground or non-real-time part of your program runs as a
> > separate task in Linux user space. You can send messages between the
> > foreground task using fifo's or shared memory.
>
> The next question : when I do the critical job in rt-module and a fifo
> handler is executed - what I will have ?
>
>
The fifo gets created with a buffer length specified by the programmer. There are two
fifo's, one for transmitting information from rt module to user space and the other
for transmitting data from user space to rt module. You can have more than two if
desired. The fifo buffer stores the information written to it until the receiving
process reads the data from the fifo. However, if the fifo buffer is sized too small
a fifo-over-run will occur. An error flag is generated if this occurs. The size
depends entirely on how often data is written to it -vs- how often data is read from
it.
> > >
>
> Thanks for reply.
>
> >
>
> Rus
>
>
Rich
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
