Garth,
The PID task must start and finish within the 1ms period you mention if the data you
are gathering is to be valid for the PID every cycle. Unless this PID has low
priority and can tolerate jitter caused by higher priority real-time tasks I would put
the PID code into the ISR. By doing this you can remove the steps of rt_task_wakeup
and rt_task_suspend. Normally there would be no application running on your computer
that has a higher priority to you than your real-time task other than another
real-time task. (otherwise why have one) Furthermore, you could probably get away
with a periodic task instead of an ISR because the process is periodic in nature.
However, since you already have that working and the interrupt is being generated by
the card that gathers the data you are assured that the data is ready when the task
begins. I would just put the PID code in the ISR and let it go at that.
I hope this helps,
Rich
> ----------
> From: Garth Gaddy[SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, July 15, 1999 9:28 AM
> To: [EMAIL PROTECTED]
> Subject: [rtl] non periodic task
>
> I have been reading the list for some time now and finally have begun implementation
>of RTLinux, so now I have a question.
>
> I am doing servo control with Servo-to-go board which generates an interrupt (irq
>5). I have the interrupt service routine working fine. It executes about 25us after
>the interrupt line goes low (pt A to pt B). On a scope it looks something like this:
> A
> IRQ5 > —-------------| |------------------------
> | |
> |______________|
>
> Digital out B
> turned on at |--------------------|
> start of isr then | 15us |
> off at end —------------------------------------------------| isr
>|---------------------------------------
>
> My intent is to use the isr to only collect the encoder and analog input data from
>the STG board, not to do any pid or trajectory computations. Those two things I want
>to do right after the isr in a PID task but not during the isr. I am assuming it
>would be bad form to do so. Since interrupts are disabled the isr should be kept as
>short as possible. BTW comments on my assumptions are welcome.
>
> My questoin is this, what is the best way to cause the PID task to execute right
>after the isr has completed?
>
> I currently have the PID task initialized in the isr modules init code. This sets
>it up and puts it into a wait condition. Then at the end of the isr I issue a
>rt_task_wakeup. The PID task executes and at the end of it's code I issue a
>rt_task_suspend. The sequence starts all over again the next time the isr runs (1
>khz).
>
> Is there a better way to do this? A faster way to do this? I don't want the PID
>task running in a periodic fashion, but instead immediately after the isr.
>
> Any help or comments are appreciated
>
> Thanks,
>
> Garth Gaddy
> [EMAIL PROTECTED]
>
> --- [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/
>
--- [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/
