Interrupt usage

[mister_e]

What else the pic will need to do? There's some case you don't even need any ON INTERRUPT.

@ SLEEP will send the PIC in sleep mode untill there's a interrupt type who can wake up the PIC. It should be listed in your datasheet, somewhere at the end.

[Brian J Walsh]

My understanding is, that although there are many sources of interrupts possible within the PIC's hardware, there is only one resulting interrupt condition. Either the processor has been interrupted or it has not. This leads me to believe that this interrupt condition has to be dealt with by a single interrupt handling routine which tells the interrupted processor what to do.

The interrupt routine, or interrupt handler, in its execution could, of course, determine the source of the interrupt by investigating the various interrupt flags and take specific action appropriate to the source, but there is only one routine and the point in the program (the label) where it is located is stated in the 'ON INTERRUPT GOTO' statement. Having more than one 'ON INTERRUPT GOTO', each with a different label, doesn't make sense to me, as that would mean that the interrupted processor could go to more than one routine to resolve the interrupt. How would it know which to go to ?

The flexibility allowed by MELabs by not predetermining the label in the command just means that you can call your interrupt handler what you like. It doesn't mean that there can be more than one and that they are differentiated by having different labels.

OK.. now to the question! The 'ON INTERRUPT' statement reference on MELabs PIC BASIC Pro support website, clearly states before giving the syntax example, that "More than one ON INTERRUPT may be used in a program"... Is this a typo or have I got it completely wrong?

Brian Walsh

[Darrel Taylor]

Hi Brian,

It's NOT a typo. You can use all available interrupts simultaneously.

On any interrupt, the program flow will be directed to the single interrupt handler. Then it's up to you to determine which one fired.

Each interrupt source has 2 bit's associated with it. An Enable bit (*IE), and an Interrupt Flag (*IF). You need to look in the datasheet to find where those bit's are.

Then in the interrupt handler, check BOTH the enable bit and the interrupt flag to determine if a particular interrupt has triggered.

For example, to have the RB Port change and Timer1 interrupts, it might look something like this...

RBIE    VAR INTCON.3
RBIF    VAR INTCON.0
TMR1IE  VAR PIE1.0
TMR1IF  VAR PIR1.0
TMR1ON  VAR T1CON.0

OldBits VAR BYTE
NewBits VAR BYTE


OldBits = PORTB   ; End the mismatch
RBIF = 0          ; clear the flag
RBIE = 1          ; enable PORTB change interrupts

TMR1IF = 0        ; clear TMR1 interrupt flag
TMR1IE = 1        ; enable Timer1 interrupts
TMR1ON = 1        ; Start the Timer

ON INTERRUPT GOTO INTHandler

Main:
    PAUSEUS 20
GOTO Main

DISABLE
INTHandler:
    IF RBIE and RBIF THEN
        NewBits = PORTB  ; end the mismatch
        RBIF = 0         ; clear the flag
        ; handle RB port change interrupt here
        OldBits = NewBits
    ENDIF

    IF TMR1IE and TMR1IF THEN
        TMR1IF = 0       ; clear the flag
        ; handle Timer1 interrupt here
    ENDIF
RESUME
ENABLE

hth,

[Brian J Walsh]

Darrel,

Thanks for the prompt response. There seems to be some confusion and perhaps I did not make myself clear.

I think I understand that all enabled interrupts are available at any time to cause the processor to go to the interrupt handler.

My point was that there can only be ONE interrupt handler (the single interrupt handler referred to in your reply) and that that single interrupt handler is referenced by a unique instance of the 'ON INTERRUPT GOTO' statement within the program.

Can you provide a sample of code showing the viable use of multiple 'ON INTERRUPT GOTO' statements? Your support of MELabs documentation which states that more than one 'ON INTERRUPT' is permissable in a program suggests that you can.

My understanding is that the purpose of 'ON INTERRUPT GOTO' is to direct program execution to a unique label when an interrupt, from whatever source, occurs (or rather is detected - in the case of compiler interrupt handling) and to deal with it.

Having the possibilty of more than one 'ON INTERRUPT GOTO' in a program with the same label would be redundant and having two or more with different labels would suggest the possibilty of multiple interrupt handlers with no way of steering program execution to the right one.

So, again, as PBP only supports a single global interrupt handler, why does the documentation state that more than one compiler level interrupt re-direction statement is allowed?

The question is - can more than one 'ON INTERRUPT GOTO' exist in a PBP program in a viable way and if so how can you use them differentially?

Regards,

Brian Walsh.

[Darrel Taylor]

Oh, I see what you're saying. But it's still not a typo.

You can have multiple ON INTERRUPT statements, but it gets a little tricky.
This will be hard to explain, so give me a little time.
<br>

[Darrel Taylor]

This example should show how you can use multiple ON INTERRUPTS.
But it's not much use for anything else.

The key thing to remember here, is that the assignments of the Interrupt Handlers only happens at Compile-Time. Attempting to execute an ON INTERRUPT statement at Run-Time to change the handler will not work.

As the program gets compiled, starting from the top, the interrupts are considered DISABLED, and no interrupt checks will be placed between the PBP lines of code.

When it encounters an ON INTERRUPT statement, the status changes to ENABLED, and in between every PBP statement, it will place an Interrupt Check, that jumps to the last assigned Handler.

In the example below, if an interrupt occurs while the program flow is within the Main loop, then the Handler0 will be jumped to.

Then when it encounters the second ON INTERRUPT statement, all lines following that assignment will interrupt to Handler1.

It does not matter if they are subroutines, main routines, or whatever, ANY lines following an ON INTERRUPT will jump to the last known handler (if interrupted).

It really does get tricky, because then each handler must be capable of handling any interrupt, which leads to multiple copies of the same handler or gosubs to common handlers. Or you have to make sure that before switching modes, ONLY the interrupts that the next mode can handle are enabled, I mean SERIOUSLY Tricky!

Just remember, It all happens at Compile-Time.

Mode   VAR BYTE
Mode = 0

ON INTERRUPT GOTO Handler0

Main:
    R0 = R0 ; just some stuff to put int checks between
    R1 = R1
    IF Mode = 1 then DoMode1
    IF Mode = 2 then DoMode2
GOTO Main

DISABLE
Handler0:
    ; Interrupt handler for the Main Loop
RESUME
ENABLE

;--------------------------------------------------------
ON INTERRUPT GOTO Handler1

DoMode1:
    ; Do Mode 1 tasks here
    
    IF Mode = 0 then Main
    IF Mode = 2 then DoMode2
GOTO DoMode1

DISABLE
Handler1:
    ; Interrupt handler for Mode 1
RESUME
ENABLE

;--------------------------------------------------------
ON INTERRUPT GOTO Handler2

DoMode2:
    ; Do Mode 2 tasks here
    
    IF Mode = 0 then Main
    IF Mode = 1 then DoMode1
GOTO DoMode2

DISABLE
Handler2:
    ; Interrupt handler for Mode 2
RESUME
ENABLE

hth,

[Brian J Walsh]

Thanks Darrel. That's quite an explanation!

Regards,

Brian Walsh.