On Fri, 6 Nov 1998, Peter Wurmsdobler wrote:
> Good morning, José Daniel Muñoz Frías,
>
> > I don't understand your problem. When an rt-linux task is started, it
> > can not be preempted by any Linux task.
> As I had understood, even RT-Linux remains multitasking, i.e.
> at each sample hit -for a discrete time control- the running
> task is preempted and the RT-control task starts after the
> context switch. If this RT-task is finished, any other process
> is scheduled by the dispatcher. At the next sample hit, the
> RT-control restarts (T=discrete time, t= continuous time,
> p= process):
> T k k+1
> t ||----------|---------|-----------|---------------||-------->
> p preemption RT preemption any processes preemption
> for RT process for any for RT
> process processes process
>
Just to clear this up, (1) you are thinking of periodic tasks (2) you are
suggesting that the RT process above does an rt_task_wait() not that it is
"preempted for any process" because rt-tasks can only be preempted by
other rt-tasks of higher priority, not by linux processes, (3) you are
worried that the preemption for k+1 will not occur with enough fidelity,
that is, the context switch time after some other task is too long.
> Thus you can see, that for high frequencies, there is only
> little space for the RT-process itself, because the preemtion
> of the running process takes too much time -> trashing. The
> introduced time delay is not desired with feed back control.
>
>
> If however things with RT-Linux look like that:
> T k k+1
> t ||----------|---------|-----------||------>
> p preemption RT wait RT
> for RT process for next process
> process starts sample hit resumes
>
> and the RT-process takes over the machine without any
> other process running, then I am content. Perhaps now
> it is a little bit clearer, where my problems are.
What is the processor doing during the wait? Are you suggesting that
cpu cycles in the "wait for next sample hit" be idle? Perhaps a single
tasking system (like DOS) would be better for this as there certainly
is some "jitter" around the k+1 time in rt-linux, it just turns out
that for many applications it is not significant.
For the input part of the control problem you can often rely on the
DAQ card to provide the rigorous timing between samples, this doesn't
really help for very rigid output of the control response however.
I'm working on a pretty demanding feedback application, among other
projects, right now.
My plan is to couple several ADC conversions to a hardware clock which
will generate interrupts, these interrupts will be serviced by an
rt-linux ISR (interrupt task) which will do a few quick PID calcs and
output 2 dwords to a DIO board. The period for this task should be less
than 50 microseconds. I do have some scope traces available online for
a period task (http://www.med.uvm.edu/~gaffney/scope.html) if you would
like to look at them. The jitter seen in these traces is somewhat severe
and will improved by use of an interrupt driven task. The periodic tasks
shown in the traces are scheduled off of the Intel 8354 timer chip which
Victor Yodaiken has indicated can take upwards of 10 microseconds to
reprogram. There is interest in changing the timer to depend on the APIC
timer of newer Intel cpus (which on PPros run at clock speed).
-Don
--- [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/
