> In our application, phase lag was a serious problem.  There can also
> be a problem with when interrupts occur.  Since there are a limited
> number of timers to play with and we have to keep things on schedule,
> the "best" solutions are:
>   1) interrupt is at 2Khz, read current inputs and set outputs based on
>       previous interrupt.  Unacceptable due to phase lag.
>
>   2) interrupt is at 4Khz, alternating interrupts read inputs and set
>       outputs.  Better (though not very good) phase lag, but interrrupt
>       overhead is getting significant.
>
>   3) interrupt is a higher multiple of 2Khz, reading inputs and setting
>       outputs on appropriate interrupts.  Good resolution on phase
>       lag, but interrupt overhead has changed timing (increased phase
>       lag) with respect to just doing the entire PID in the isr.
>

save/restore etc omitted for clarity of exposition

InterruptHandler:
    incf      Phase,F
    btfss    Phase,0
    goto    get_inputs

    .... update outputs ....
    .... adjust timer to go off in 'n' uSec, relative to last interrupt ....
    retfie

get_inputs:
    .... fetch inputs ...
    ...  adjust timer to go off in 500-n uSec, relative to last interrupt 
...
    bsf    data_avail_flag
    retfie

Net result:

two interrupts per PID cycle
near zero jitter
minimal jitter-free phase lag

Note however, that unlike some others on the list, I see nothing wrong with 
embedding the PID update in the interrupt handler.

Bob Ammerman
RAm Systems




-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist