DT-Ints latency and other interrupt conciderations

[Darrel Taylor]

Hi Henrik,

It does take a lot of time to save/restore all of PBP's System variables.
So, PBP type interrupt handlers are not too good at high frequencies.

Fortunately, both of your interrupt routines aren't doing anything that requires System variables. And you can just change their "Type" to ASM, without actually writing them in ASM.

And your ASM routine would only count 8-bits, so I think it might be a bit limiting.

IF statements with "=", and simple addition/subtraction doesn't use PBP's system vars, so most interrupts that only need to count something can usually be written as PBP, then used as ASM.

HTH,

[HenrikOlsson]

Hi Darrel,
Many thanks, it does help a lot!

So, can I assume that it takes roughly the same time to "get out of" an ASM interupt as it takes to enter it, in this case 8.4uS? Then, theoretically, the max frequency would be 1/(2*8.4+1uS) = 56kHz - if all it had to do was servicing the INT2 interrupt - which unfortunately still isn't good enough :-( Even going to 40Mhz just barely gets me over the 100kHz target with not much time left to do anything.

I know the 8bit buffer variable may "look" limiting but because it is "read" by the servo-loop, which is currently run at 1220Hz, it means the actual limit would be ~155kHz - if I can get that I'd be happy. The only concern I have with this approach is that I need to disable the INT2 interrupt while reading and resetting the buffer. But if I'm not mistaken if an interrupt occurs during this time it will get "latched" and serviced as soon as I re-enable it again.

Thanks again Darrel! I'll give it a go during the day and see what I can get.

/Henrik.

PS. I have a comercially available drive that I bought which also uses the 18F2431, it has a claimed step-frequency of 400kHz - I wonder how they do it....

[Darrel Taylor]

Well let's see what we can do here ...

Since it's an 18F, with "qualified" ASM handlers ...
You can remove the remaining overhead by removing DT_INTS all together, and using an ASM ISR, written in PBP of course.

Something like this ...

DEFINE INTHAND _ISR
DEFINE NO_CLRWDT 1

;---------------------------------------------------------------------------
ISR:
  IF INTCON3.1 THEN             ' IF INT2 triggered
DoStep:
    If PortB.1 = 1 THEN         'Direction signal connected to PortB.1
      Setpoint = Setpoint + 1    'Setpoint is a 32bit variable
    ELSE
      Setpoint = Setpoint - 1
    ENDIF
    INTCON3.1 = 0               ' clear the int flag
  ENDIF
    
RollOver:
  IF PIR3.2 = 1 THEN            ' if IC2QEIF triggered
    IF QEICON.5 = 1 then
      Position.Word1 = Position.Word1 + 1    'Position is a LONG
    ELSE
      Position.Word1 = Position.Word1 - 1
    ENDIF
    PIR3.2 = 0                  ' clear the int flag
  ENDIF
@   RETFIE FAST                 ; return from interrupt with shadow regs

Setpoint is handled as a LONG, but if you can use a BYTE sized result, you can change it to Setpoint.byte0 to reduce it by a few instructions.

The NO_CLRWDT drops a couple more instructions, but make sure the WDT is OFF.

Compiled, it looks like this, including both handlers ...

_ISR
        btfss   INTCON3, 001h
        goto    _RollOver
_DoStep
        btfss   PORTB, 001h
        goto    L00003
        incf    _Setpoint, F
        clrf    WREG
        addwfc  (_Setpoint) + 1, F
        addwfc  (_Setpoint) + 2, F
        addwfc  (_Setpoint) + 3, F
        goto    L00004
L00003
        decf    _Setpoint, F
        clrf    WREG
        subwfb  (_Setpoint) + 1, F
        subwfb  (_Setpoint) + 2, F
        subwfb  (_Setpoint) + 3, F
L00004
        bcf     INTCON3, 001h
_RollOver
        btfss   PIR3,  002h
        goto    L00005
        btfss   QEICON, 005h
        goto    L00007
        incf    _Position??WORD1, F
        movlw   0
        addwfc  (_Position??WORD1) + 1, F
        goto    L00008
L00007
        decf    _Position??WORD1, F
        movlw   0
        subwfb  (_Position??WORD1) + 1, F
L00008
        bcf     PIR3,   002h
L00005
    RETFIE FAST                 ; return from interrupt with shadow regs

Hope that gets it closer.

[HenrikOlsson]

Thanks Darrel,
Now I'm a bit confused.... Will this allow me to still use DT-Ints for the low-priority interrupts? The actual servo-loop code is, as I said earlier, triggered as a low priority interrupt by TMR2 and I also have a second low priority interrupt for handling USART comms (which isn't used during the tests I've made so far).

Does the RETFIE FAST automatically restore the STATUS, W etc registers or is that not needed due to the "shadow regs"? As you can see I really suck at the low level stuff...

Before seeing your message I tried changing the RollOver ISR to type ASM but it didn't make much difference. Up to 20kHz it works fine, above that it starts to fall apart and I can't really see why.

Your assistance is much apprecited, thanks!

/Henrik.

[sougata]

Hi,

Darrel correct me if I am wrong, I am a bit rusty here.

The shadow registers are not memory mapped but are actually hardware registers, a single level deep hardware stack that can save your context (W,Status, BSR). Optional during <b>call, something s , </b> or a <b>return, something s , </b> and automatic when entering interrupt. You decide whether you want to restore them by Retfie Fast . So when a low priority interrupt (0x0018h) is interrupted by a high priority one, the context saved while entering the low priority is lost. Thus it works best if you are using only HP Ints or using it for only HP Ints.

[HenrikOlsson]

Hi again,
I'll start by quoting myself:

Before seeing your message I tried changing the RollOver ISR to type ASM but it didn't make much difference. Up to 20kHz it works fine, above that it starts to fall apart and I can't really see why.

Correction/clarification somewhere between 17.5-18kHz something happens which makes the TMR2 LP interrupt frequency start to drop. I guess the HP priority interrupts are stealing so much time that the TMR2 interrupts "runs over itself".

At 32kHz the high priority DoStep ISR still tracks the step pulses correctly but now the TMR2 ISR is only run at ~550Hz instead of 1220Hz which can be both heard and felt from the motor. Going higher than this (I tried 33kHz) completely unstabilizes the servo-loop so I don't know how high the INT2 interrupt will actually track the pulses.

/Henrik.

[Darrel Taylor]

I think that both INT2 and TMR2 interrupts should be HIGH priority.
The USART can be LOW priority, since servicing it is not really time critical.
But no, you won't be able to use DT_INTS for just the Low Priority.

Sougata is correct about the shadow registers...
They are only good for High Priority interrupts.
For Low priority ints you have to save W, STATUS and BSR in the ISR.

What are you doing with the USART handler?
Stuffing the bytes in a buffer?
<br>