Instant Interrupts - Revisited

[HenrikOlsson]

Hi,
You can use Darrels routines with interrupt service routines written in assembly and/or BASIC. If the interrupt service routines you write are written in BASIC (PBP) you should declare them as type PBP in the INT_LIST AND you must INCLUDE ReEnterPBP.bas. If you write your interrupt service routines in assembly you declare them as Type ASM in in the INT_LIST and then ReEnterPBP file is NOT needed because you're not using ISR's written in BASIC. Anytime one or more of you ISR's are written in BASIC the ReEnterPBP file must be included, only when all handlers are in ASM can it be left out.

ON INTERRUPT is the compilers own way of handling interrupts and has nothing to do with DT_Ints. You use either ON INTERRUPT or Darrels routines.

/Henrik.

[mr.sneezy]

Thanks Henrik, that explanation is clear, concise, and fully understood now.

cheers,
Martin

[WOZZY-2010]

Well I think I've finally figured out some of the nuances of RBC_INT.
I think the last example I tried to use was not a very good way to test it out.

I tried to document this working code example in a way that's understandable and can be used as a template to build on.

This is setup with PBP type interrupts using ReEnterPBP-18.bas, since I'm using PBP in the Interrupt handler, but ... it seems to work just fine when run as ASM type, and not including ReEnterPBP-18.bas. You can just uncomment out the appropriate lines to suit your needs.

The thing that was giving me so much of a headache before was the need to read one of the Port B <4-7> registers prior to exiting the Interrupt handler. This ends the mismatch condition and allows the RB Port Change Interrupt Flag Bit to be cleared. Even though I was reading the Port B <4-7> registers frequently, it seems that using GOTO to enter the Interrupt handler exit subroutine, caused the Interrupt Flag Bit to reset.

Program operation:
This Program uses DEBUG to send status comments to a 9600 Buad Serial ASCII Terminal on PORTC.6
On first press of any of the PORTB<4-7> buttons, the program enters the interrupt handler.
The Interrupt Handler, continuously reads the buttons.
Buttons 1,2 & 3 just display a status message. You could put any subroutine in place of the DEBUG Statement.
Button 4 gracefully exits the interrupt handler.
At this point, RBC_INT is reset and awaiting any PORTB<4-7> button press again to reenter the Interrupt handler.


Anyway here's the Code and a schematic of the setup... I hope this helps someone who's struggling with RBC_INT like I was.
The ZIP file attachment has the code, and copies of the version of DT_INTS-18.bas and ReEnterPBP-18.bas that are included.

Bob W.

' RBC TEST.BAS
' Bob Wozniak
' PIC 18F6480 @ 20 MHZ
' MPLAB IDE V8.40  /  PBP V2.60  /  Build Options: [-ampasmwin]
' RB4  Momentary Contact Button Goes High on Press,  10K Resistor to Ground
' RB5  Momentary Contact Button Goes High on Press,  10K Resistor to Ground
' RB6  Momentary Contact Button Goes High on Press,  10K Resistor to Ground
' RB7  Momentary Contact Button Goes High on Press,  10K Resistor to Ground
' RC6  22K ohm to RX on 57600-N-8-1 Serial Terminal
' This program created to check Port-B Change Interrupts

INCLUDE "DT_INTS-18.bas"		  ; Include Darrel Taylor's Base Interrupt System for PIC18F [Version:3.4 (NOV 04, 2009)]
INCLUDE "ReEnterPBP-18.bas"      ; Need to include if using PBP type interrupts

DEFINE OSC 20

DEFINE DEBUG_REG PORTC	' SETUP DEBUG to view output on 9600 BAUD ASCII Terminal on PORTC.6
DEFINE DEBUG_BIT 6 			
DEFINE DEBUG_BAUD 9600
DEFINE DEBUG_MODE 1 

I VAR WORD
X VAR BYTE

ASM
INT_LIST  macro ; IntSource,  Label,             Type, ResetFlag?
;       INT_Handler RBC_INT, _RBC_INT_HANDLER,   ASM,  no             ; use for ASM type interrupts
        INT_Handler RBC_INT, _RBC_INT_HANDLER,   PBP,  no             ; use for PBP type interrupts
    endm
    INT_CREATE
ENDASM
@ INT_ENABLE   RBC_INT



HOLD_HERE:          ' **** This subrouting loops continuously and waits for button press to activate RBC interrupt handler
IF I = 0 THEN DEBUG 10,13,10,13,"HOLDING FOR PORTB <4-7> BUTTON PRESS to ACTIVATE INTERRUPT",10,13 : I = 1
PAUSE 10
GOTO HOLD_HERE



RBC_INT_HANDLER:     ' **** Program jumps here when ANY PORTB.4 thru PORTB.7 are changed ****
DEBUG "############### RBC INTERRUPT ACTIVATED #################",10,13
PAUSE 250    ' This pause allows time for button debounce - needs to be here unless immediate read of interrupt button req'd


READ_BUTTONS:        ' **** Program cycles reading buttons, until button 4 is pressed ****
If PORTB.4 = 1 Then DEBUG "BUTTON 1 PRESSED",10,13
If PORTB.5 = 1 Then DEBUG "BUTTON 2 PRESSED",10,13
If PORTB.6 = 1 Then DEBUG "BUTTON 3 PRESSED",10,13
If PORTB.7 = 1 Then DEBUG "BUTTON 4 PRESSED - EXITING",10,13 : I = 0 : GOTO END_RBC_INT
PAUSE 5  
GOTO READ_BUTTONS


END_RBC_INT:        ' **** this subroutine gracefully exits the interrupt handler and resets for next RBC event ****
PAUSE 250              ; This pause allows time for button debounce - needs to be here or interrupt will immediatly reactivate
DEBUG "################ EXITING RBC INTERRUPT HANDLER ############",10,13

X = PORTB.7            ; NOTE: Prior to returning from RBC Interrupt, you MUST read at least 1 PORTB <4-7> to end
                       ; the mismatch condition and allow the RB Port Change Interrupt Flag Bit to be cleared.
                       ; If not here, the interrupt will immediatly reactivate if using the GOTO END_RBC_INT statement.
@ INT_CLEAR RBC_INT
@ INT_ENABLE RBC_INT
@ INT_RETURN
END

[Ioannis]

Hi Bob.

I think you must be very quick on the 4th button to exit (less that 250ms plus the debug delay). If you hold the button longer the ISR will activate again,won't it?

Also the:

@ INT_CLEAR RBC_INT
@ INT_ENABLE RBC_INT

at the end of the ISR are not necessary as they are handled by the DT_Ints, right?

Ioannis

[WOZZY-2010]

I think you must be very quick on the 4th button to exit (less that 250ms plus the debug delay). If you hold the button longer the ISR will activate again,won't it?

Ioannis...You're right about this. the 250 mS delay is fine on the simulator, but is a little too short to be reliable with real hardware buttons. 400-600 is a better number for use on the hardware.

Also the:
@ INT_CLEAR RBC_INT
@ INT_ENABLE RBC_INT
at the end of the ISR are not necessary as they are handled by the DT_Ints, right?

Thanks for pointing this out...it seems to be somewhat dependent on the value of the DT_INT ResetFlag Here's what I found:

Disabling @ INT_CLEAR RBC_INT
ResetFlag = yes - no change to program operation
ResetFlag = no - Interrupt reactivates again immediately
So the @ INT_CLEAR RBC_INT is dependent on the ResetFlag setting

Disabling @ INT_ENABLE RBC_INT
ResetFlag = yes - no change to program operation
ResetFlag = no - no change to program operation
So the @ INT_ENABLE RBC_INT is not necessary.

I also now realize that I still haven't quite figured out the how INT_DISABLE RBC_INT effects the Interrupt handler in it's different states.

Thanks,
Bob W.

[Ioannis]

Why do you care so much about Enable/Disable flags? All these are taken care by Darrel in his routines, so normally you don't have to deal with them.

Just do as his examples show and you are OK.

In the extreme case you want some control as to when the interrupts are re-enabled, just use the @INT_ENABLE or @INT_DISABLE commands locally.

Also the simplistic debouncing of a button with time delay is not very elegant and is not recommended as it can delay the program execution.

Ioannis

[WOZZY-2010]

Ioannis,

Why do you care so much about Enable/Disable flags? All these are taken care by Darrel in his routines, so normally you don't have to deal with them.

I'm really just trying to fully understand this particular interrupt. It's a good learning exercise for me before I go on to other interrupts. I am learning that Darrel's routines are actually much easier to use and sensible than I thought, before I thoroughly confused myself by looking at it in this much detail.

Also the simplistic debouncing of a button with time delay is not very elegant and is not recommended as it can delay the program execution.

As I'm really pretty new to this, I'd be very interested to know what is your recommendation for debouncing. Are you talking about a hardware, or a software solution?

For my current application, the interrupt is just used to jump out of the main program to enter a set up menu. So the main program is on hold and nothing is time critical. This whole RBC_INT study is just a tangent that I went off on, when I didn't understand why the stuff that I had cut & paste from the examples didn't behave as I expected.

Thanks again,
Bob W.