DT-Ints latency and other interrupt conciderations

[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>

[HenrikOlsson]

Thanks Darrel,
That explains it for sure - but it kind of sucks.... :-/

Basically, the Position and the Setpoint variables are the only longs and the reason for PBPL.

The setpoint is calculated by adding or subtracting the number of steps that has arrived since the last servoloop. For the position I get the lower 16bits from the hardware QEI counter and the upper 16bits by keeping track of the number of over/underflows with the RollOver ISR.

Man, I'm painting myself into a corner here....

BTW, how come these two...

ByteVar1 = ByteVar1 + (ByteVar2 >> 2)    ; <-- Long
ByteVar1 = ByteVar1 + (ByteVar2 >> 1)    ; <-- Byte

...are treated different?

Thanks for all the help, I appreciate it!

/Henrik.

[Darrel Taylor]

Basically, the Position and the Setpoint variables are the only longs and the reason for PBPL.

The setpoint is calculated by adding or subtracting the number of steps that has arrived since the last servoloop. For the position I get the lower 16bits from the hardware QEI counter and the upper 16bits by keeping track of the number of over/underflows with the RollOver ISR.

If that's all there is ... it's a piece of cake for PBPW.

Man, I'm painting myself into a corner here....

I think not.

BTW, how come these two...

ByteVar1 = ByteVar1 + (ByteVar2 >> 2)    ; <-- Long
ByteVar1 = ByteVar1 + (ByteVar2 >> 1)    ; <-- Byte

...are treated different?

A single shift right compiles to a

    BCF STATUS,C
    RRF _ByteVar2,F

or, RRNCF for an 18F.

But for 2 or more shifts, it puts the value in a system reg, saves the number of bits to shift, then calls a library routine to actually do the shift. Therefore ... LONG.

Let me try to figure out the PBPW way. (should be easy)
I think all the info is already in this thread.
Anything missing that might help?
<br>