Bill Couture wrote :

> It's actually about 300us out of the 500us between TMR1
> interrupts.
> And, yes, it does have to be done in the interrupt.
> As noted elsewhere, I could use the TMR1IF flag to poll
> when the PID loop needs to execute, but I found that the
> resultant jitter could be seen (and heard!) in the
> mechanical system.

Note that it isn't a choice between doing *everything* in
the ISR and doing *nothing* in the ISR (with regard to the
TMR1 iterrupt).

Let the TMR1IF generate an interrupt (as now). Then in the ISR
just set your own "PID-flag" saying that your PID routine has
to be run now (or rather "soon"). Then leave the ISR and
let your main-loop detect your PID-flag and run the PID
code. During that time, you are able to service other
interrupts like the UART receive interrupt. Make sure that
you make *that* ISR code as short as possible also (just
saving the received byte) so you don't hold up your
PID calculations unnecessarily.

When your PID code is finished, your mail-loop will detect
that there was a byte recevied (through a similiar user-defined
"byte-received-flag"), and your main code can go on
processing *that* task (and still be able to response to
other interrupts).

As have been said many time before, running tasks
*inside* an ISR, doen't give your PIC more processing
cycles to use, it just prevents the PIC from responding
to *other* interrupts during that time...

Use the interrupt sub-system to just *detect* that something
some to be done, then let your main code do the actual
processing. You'll get a much smoother flow in your
application and less chance to "miss" an event.

Best Regards
Jan-Erik.

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu