writing a program within ISR

[gary36]

Hi

I am implementing a PID controller and want to execute PID algorithm within an ISR. I have used the timer to trigger the interrupt . My problem is that how to keep ISR program small and how to redirect to other handler to deal with the PID. Secondly,The variables need to beglobal in order to correctly estimate the output value. How to do so? Using MPLABX IDE

 

[andre_luis]

This would be one of the few cases where performing routines within the Timer ISR would not be at all inconceivable, and it would obviously be presumed that the whole processing to be performed within each time slice is adequatelly sized and/or optimized to run in the shortest time.

 

[gary36]

Hi andre
can you give details on my queries posted in #1

 

[KlausST]

Hi,

A PID algorithm is small, and usuall doesn´t contain loops.
Indeed it´s just multiplying and adding values.

Only a couple of conditional branches are necessary to avoid overflow / underflow.

So write the code in the ISR, estimate it´s run time and be sure that the maximum runtime is less than the interrupt-to-interrupt time.

****
As so often in the posts: there are no specifications, thus we can give no detailed advice.

Klaus

 

[gary36]

Hi
would the following strategy work. I think I can ensure that I do not load ISR

void _ISR _T3Interrupt(void)
{
  IFS0bits.T3IF = 0;
flag=1;
}

while(1)
{
   if (flag==1)
{
  execute my PID algorithm
   flag=0;
}
}

 

[betwixt]

If the "my PID algorithm" is short it will work but to be honest I would advise the method in post #5, especially if the MCU is doing other things as well. Technically, as long as the algorithm has run, finished and the ISR has returned before the next interrupt it will be safe but if another interrupt occurs (from any source) while still in the ISR it will at best give wrong results and could completely crash the program.

Brian.

 

[andre_luis]

can you give details on my queries posted in #1

A PID controller, likewise any other fixed-time-based digital process, should have priority in execution, and as sufficiently 'detailed' in post #2, this would be one of the few cases where I would particularly have preferred to place the PID process within the interrupt vector. If you prefer a more asynchronous approach, you will have to deal with the queue control of the read values.

 

[gary36]

Hi andre

Do you feel the strategy adopted in #5 is incorrect. Will it not synchronously execute within the interrupt time period? Secondly I have seen sample codes using static double variable declarations. Could you please enlighten the benefit of the same

 

[andre_luis]

Do you feel the strategy adopted in #5 is incorrect

I did not say anytime that the asynchronous strategy would be worse or better, but at least in my opinion running PID controller outside interrupt handler turn things more complex once this requires an extra layer of control in the program to manage the start of execution of each iteration in the main(), triggered on the Timer interrupt.

Will it not synchronously execute within the interrupt time period?

A PID controller will generate an output control value (Analog, PWM, etc ...) which regardless of whether it was generated within the ISR or not, its exhibition to the I/O interface have to be synchronous with the timer interrupt, and therefore, once again, in my oppinion it makes no sense to calculate and display the value in different vectors, namelly Main() and Interrupt(). Keep in mind that according to the classic model of digital control, it essentially consists of a data acquisition stage, a data processing stage, and an output stage. If some of them have to be computed in a chain, there is no impediment to put them in the same place, interrupt on this case.

 

[KlausST]

Hi,

If the "my PID algorithm" is short it will work but to be honest I would advise the method in post #5, especially if the MCU is doing other things as well.

Maybe it's personal taste, but here I don't agree.

An example:
* If one task is the PID controller (in my case to control the electrical energy for a chemical process)
* another task is to display some values
* another task is to poll pusbuttons

Then I'd do the PID in interrupt context and the other tasks in main loop.
I'd give the PID the highest priority. For a PID to work stable it needs stable timing, especially reading_the_inputs and updating_the_outputs.
Any timing error will cause jitter and this jitter will cause noise and - depending on loop stability - ringing.
If the in_to_out delay is too high, then even oscillation may occur.

Maybe someone's argument is, that if thePID ISR takes too much time a new PID interrupt may be raised. This stricktly needs to be avoided. One needs to calculate/measure the maximum expectable ISR time. Then slow down the interrupt frequency.
With my applications I keep the max expectable ISR time less than 80% of the interrupt period.
In my eyes it's better to slow down PID ISR frequency but keep it constant, because one may adjust PID parameters to ensure stability.
This constant behaviour is absolutely predictable.

I know this sounds pedantic. But the chemical processes are critical .... and the product needs to be very uniform, one tiny irritation may cause the complete batch to be useless. A loss of 40,000€.

Klaus

 

[gary36]

Hi

Can ISR handle large program? Should we declare all variables within ISR static?

 

[KlausST]

Hi,

Can ISR handle large program?

* large in instructions: Yes
* large in time? --> already answered. It at least needs to faster than the interrupt period time.

Klaus

 

[FvM]

Can ISR handle large program?

The question has be answered in detail by KlausST. The total processing time of your controller task doesn't change either if it's performed in ISR or not. Problems arise if you don't know the actual processing time or if it's largely varying. Lengthy ISR routines however block the processing of other interrupts that must be performed in time, e.g interface handlers, unless you introduce well considered interrupt priorities.

Should we declare all variables within ISR static?

As in non ISR code, variables should be implemented as automatic or static depending on their function. Global or local static is just a matter of the variable scope. There are special considerations for those global variables that are accessed both in ISR and main level.

 

[std_match]

Should we declare all variables within ISR static?

You only need to declare them as static if they must keep their values between ISR executions.

Global variables that are used by both the ISR and other parts of the software should be declared as "volatile".
In your example in post #5, the variable "flag" should be "volatile".

 

[c_mitra]

PID controller and want to execute PID algorithm within an ISR...

In general it is not a good idea, but you can set a flag that can be checked in the main routine. If your routine DOES take long time, it is better to search of alternative strategy.