DT-Ints latency and other interrupt conciderations

[Darrel Taylor]

I may be continuing to miss the point, but ...

I still think TMR2 should be a high priority interrupt.
Except, it should be ASM, and ONLY collect the data required to calculate the error.

The PID and motor control should be running in the main loop, using the error info from the interrupt.

If the PID happens to miss an update, it won't matter that much because the error will still be updated the next time. And it's not like the PID loop can cancel the error on each update. It takes time. But at least the actual error measurements will be consistent at much higher frequencies.

Obviously, the "I" time period won't be constant, but I think they'll be close enough that you won't notice a difference. IMHO
Then the PID loop can run at it's maximum rate, while the interrupts run at their maximum rate, without interfering with each other.
<br>

[sougata]

I may be continuing to miss the point, but ...

I still think TMR2 should be a high priority interrupt.
Except, it should be ASM, and ONLY collect the data required to calculate the error.

The PID and motor control should be running in the main loop, using the error info from the interrupt.

<br>

I did not realize that the PID routine was running within the ISR. Henrik is it necessary ?? A better way could be accumulating error in the back (ISR) while processing error in main loop. I did tried your PID loop once but never closely worked on it. So excuse my ignorance if I am talking something analogue (illogical!!)

[HenrikOlsson]

Hi,
Yes the PID is currently run as part of the 1220Hz TMR2 ISR because I've always been taught that digital PID systems needs to be run at constant intervals and I can definetly see why that is neccessary.

You are correct that the important thing is to sample the data at precise intervals - if that's not done the effect will be the same as constantly changing the gains up and down. Or it will "look like" the speed of the motor isn't constant even though it actually is because the number of encoder counts per update is changing.

On the other hand, if the output of the filter isn't updated at constant intervals the motor doesn't have the same time to respond to input which is also the same as changing the gains but it might not be as bad as not sampling regularly. So, this is essentially why the PID routine is run inside the TMR2 ISR.

However, it's definitely worth a try to move it to the main routine and then have the TMR2 ISR signaling the main routine that new data is available, I'll try that! That would mean that the TMR2 ISR wouldn't (hopefully) contain any code that requires the PBP system variables so I'll be able to change its type to ASM although it's coded in PBP.


As a side note, I'm wondering what in the DoServo code it is that takes so much time. The PID code alone was measured to 190uS worsy case and it contains far more math than the rest of the DoServo code. Yet the complete DoServo routine sometimes takes 400uS, without it being interrupted. The 190uS was measured when compiled with PBP though, not PBPL but the PID code doesn't contain ANY operations on LONGS, does it matter?

Sorry, now I'm asking queastion that my scope can answer.... Thank you both!

/Henrik.

[Ioannis]

I believe that motor will not feel the difference ifthe PID routine is interrupted for a small fraction of time (in the order of microseconds).

The inertia is large enough even for small motors.

As Darrel always says, keep the ISR as fast as possible and return to your main routine for the processing. That way your PID will still run fast.

Ioannis

[HenrikOlsson]

Hi,
I agree, generally. BUT the "few uS" quickly add up... The servo code, including the PID, is supposed to run at 1220Hz and currently takes up to 400uS from "input to output". Let's say we're stepping at 50kHz and each interrupt takes 20uS. This means that during the 400uS it takes the servo code to execute there will be 20 interrupts, each taking 18uS for a total of another 360uS - the servo code now takes 760uS from "input to output".

However, the numbers will be the same no matter "where" the servo code is run - it's just a matter of finding which works the best. One benefit of moving it to the main routine is that it makes it at least possible for me to have the ISRs in "real" ASM which will help bring the latency down further. Don't know how I'll handle the USART though.... I love DT-Ints.... :-/

Thanks!
/Henrik.

[HenrikOlsson]

Hi,
Still messing around with this.... I changed the TMR2 interrupt to high priority and its type (as "declared" in the INT-List) to ASM but kept the code in PBP and moved the PID and PWM code to the main routine. The INT2 ISR now executes in 14uS. A semaphore signals the main routine to run the PID etc.

It works but there's no noticable increase in performance. At 10kHz the motor moves smoothly and silently, at 22.5kHz it's a lot more nervous and you can hear it kind of "ticking".

So I stopped playing with that for a while and instead tried to find what it is that eats up the CPU cycles in the servo-code and not surprisingly the PID-code is the biggest hog. What I find strange though is that when it's compiled with PBP 2.6 it runs in 40-125uS but when compiled with PBPL it takes 80-325uS to execute - quite a difference.

Why does it take more than twice the number of cycles to execute when compiled with PBPL? The PID code itself doesn't even use any longs.

Thanks!
/Henrik.

[Darrel Taylor]

With PBPL, all internal System and T? variables are LONGs.

All multiplications and divisions are done as Longs, even if they are byte vars.
Most things that get put in a System var with a CALL to the library are done as a Long.

IF ByteVar1 >= ByteVar2 THEN             ; <-- Long 
IF ByteVar1 = ByteVar2 THEN              ; <-- Byte
WordVar = WordVar /* Const               ; <-- Long
ByteVar1 = ByteVar1 + Const              ; <-- Byte
ByteVar1 = ByteVar1 + (ByteVar2 >> 2)    ; <-- Long
ByteVar1 = ByteVar1 + (ByteVar2 >> 1)    ; <-- Byte

Having 32-bit vars is nice, ... unless you need speed.

Is there a particular reason you need PBPL?
Maybe we can cut that down to word sized math so you can go back to PBPW.
<br>