Instant Interrupts - Revisited

[Darrel Taylor]

Awesom,

Will the pin change functions work with the 12F683?

Sure will.

Add these two lines in the ASM section right before the INT_LIST

RBIF = GPIF
RBIE = GPIE
(no space at the beginning of the line)

Then use RBC_INT.
<br>

[dhouston]

Add these two lines in the ASM section right before the INT_LIST

RBIF = GPIF
RBIE = GPIE
(no space at the beginning of the line)

Then use RBC_INT.

Thanks. Spending $0.25-0.30 more for the 12F683 vs. the 12F629 is worth it to be able to use Instant Interrupts.

[Darrel Taylor]

I like the 683 too. If for nothing more than the CCP module. Of course the extra RAM and program space is also handy.

With the 629 only having 64 bytes of RAM,
PBP uses 24-26 bytes
and DT_INTS-14 and ReEnterPBP want 31 bytes of it (without T? vars)

Which only leaves about 6-7 bytes for the program. Not much you can do with that.

But, when using ASM interrupt handlers, DT_INTS-14 only needs 7 bytes of RAM, leaving around 38 bytes for the users program. Now that, is workable. It also uses less program space that way.

You mentioned earlier that you only needed to toggle a pin in the interrupt, so you might take a look at this page...

DT_INTS-14 (Assembly Language Interrupts)
http://www.darreltaylor.com/DT_INTS-14/asm_ints.html

The ToggleLED1: handler does just that. And if the other handlers aren't too tuff, you might still fit it in a 629.

HTH,
&nbsp; DT

[DynamoBen]

Darrel

I'm going to be moving a project from a 16F88 to an 18F1320. The reason for the move is the 18F1320 has 3 external interrupts, 2 of which I will be using. Currently I'm using instant interrupts and INT_INT on the 16F88. The question is will instant interrupts work with multiple external interrupts? I see in the datasheet that the external interrupts have numbered flags.

[SteveB]

Darrel

I'm going to be moving a project from a 16F88 to an 18F1320. The reason for the move is the 18F1320 has 3 external interrupts, 2 of which I will be using. Currently I'm using instant interrupts and INT_INT on the 16F88. The question is will instant interrupts work with multiple external interrupts? I see in the datasheet that the external interrupts have numbered flags.

See http://darreltaylor.com/DT_INTS-18/home.html. Darrel has done a good job documenting the Instant Interrupts, and it shows on the right side of the page that multiple external interrupts are implemented.

Steve

[DynamoBen]

Thanks Steve, I forgot that he was using a separate version for the 18Fs.

[f_lez]

Its now 7:34 am, I just read this thread from start to finish, I would like to say it went completely over my head but some must have aimed a bit lower as I now have one hell of an headache........

I read it as I have just got a shiny new programmer and a 18f2550, I was looking for ways to port some old f88 stuff I wrote that used serial comunication, I want to it to use usb...

I found that they are some examples to make the 2550 emulate a serial port, and I may go that way, seems easier to port that way.

Then I read more and got more ambitious, and was wondering if I can port it over with the 2550 running fake serial over usb, but drop a bootloader in it before my old f88 code and use the bootloader over usb, then I wont need to use my pc serial port at all?


To summise, can I re-burn the chip via usb with a boot loader to debug my ported f88 code?

If I can, am I right in thinking all I need is to give up one i/o line to a switch to trigger the bootloader?

And like most things come in three's (especially questions), how to edit/burn to usb? with the f88 I usually create a hex file, quit basic, load the programmer software (winpic/whatever) and burn chip, remove from programmer, get a pin stuck in thumb and lose blood, stick in proto board, bend a pin etc...

[Demon]

Darrel

I'm going to be moving a project from a 16F88 to an 18F1320. The reason for the move is the 18F1320 has 3 external interrupts, 2 of which I will be using. Currently I'm using instant interrupts and INT_INT on the 16F88. The question is will instant interrupts work with multiple external interrupts? I see in the datasheet that the external interrupts have numbered flags.

Maybe assigning high & low priorities might help you:
http://darreltaylor.com/DT_INTS-18/LowPriority.html

One problem I am having now is that an internal interrupt (USB Service) seems to lose connection after I use an external interrupt (incoming USART data). Assigning a priority to each is just what I'm about to test and see how things go.

Robert

[Darrel Taylor]

Sounds like a good idea.

Since an HSERIN can take up to several hundred milliseconds (depending on baud rate and data size), it's best to have HSERIN in a Low Priority handler.

And things that "must" go without fail, in the High Priorities.

DT

[Demon]

Yup, that's what I was thinking, having the USB SERVICE come first, and have the USART interrupt 'whenever'.

Edit: WEEE !!!

Robert

[mr.sneezy]

I like the 683 too. If for nothing more than the CCP module. Of course the extra RAM and program space is also handy.

With the 629 only having 64 bytes of RAM,
PBP uses 24-26 bytes
and DT_INTS-14 and ReEnterPBP want 31 bytes of it (without T? vars)

Which only leaves about 6-7 bytes for the program. Not much you can do with that.

But, when using ASM interrupt handlers, DT_INTS-14 only needs 7 bytes of RAM, leaving around 38 bytes for the users program. Now that, is workable. It also uses less program space that way.

You mentioned earlier that you only needed to toggle a pin in the interrupt, so you might take a look at this page...

DT_INTS-14 (Assembly Language Interrupts)
http://www.darreltaylor.com/DT_INTS-14/asm_ints.html

The ToggleLED1: handler does just that. And if the other handlers aren't too tuff, you might still fit it in a 629.

HTH,
&nbsp; DT

Hi Darrel,
I tried this above tip to get back some RAM space to try put my old 12F683 code into a 12F629, but I get a persistent PBP error when I try to compile it.

error[101] d:temp\8chppm~3.asm 450: Error: (ReEnterPBP must be INCLUDEd to use PBP type interrupts)

I also fiddled the wsave value to get past other errors, but this one escapes me, due to not being very familiar with assembly I'd expect.

Heres my ASM code at the start of the program, what did I mess up ?
Thanks Martin

'Interrupt driven 20mS timer for PPM frame timing. See also "my_handler". Uses Timer 1 interrupts.
INCLUDE "DT_INTS-14.bas" ' Base Interrupt System
'INCLUDE "ReEnterPBP.bas" ' Include if using PBP interrupts

ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler TMR1_INT, _my_handler, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
INT_ENABLE TMR1_INT ; Enable Timer 1 Interrupts

ENDASM

T1CON = $1 ; TMR1ON
'@ INT_ENABLE TMR1_INT ; enable Timer 1 interrupts

[Darrel Taylor]

error[101] d:temp\8chppm~3.asm 450: Error: (ReEnterPBP must be INCLUDEd to use PBP type interrupts)

'INCLUDE "ReEnterPBP.bas" ' Include if using PBP interrupts
\<-- commented

INT_Handler TMR1_INT, _my_handler, PBP, yes

Ahhh chuew ...

[mr.sneezy]

error[101] d:temp\8chppm~3.asm 450: Error: (ReEnterPBP must be INCLUDEd to use PBP type interrupts)

'INCLUDE "ReEnterPBP.bas" ' Include if using PBP interrupts
\<-- commented

INT_Handler TMR1_INT, _my_handler, PBP, yes

Ahhh chuew ...

Hi,
Sorry Darrel I'm even more confused from the reply. I interpreted your old post and the website info to mean that if I wasn't using PBP interrupts e.g. 'On Interrupt' that I could rem out the ReEnterPBP.bas include. I see I'm interpreting that post wrong.
Can I take that reply to mean that in this case I can't do that, or does this mean I need to write the handler in ASM ?

That's MR Ahhh Cheuw :-)

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

[WOZZY-2010]

Hi,

I've been trying vary to fully understand the RBC_INT interrupt handler in DT_INTS-18.pbp.

So I wrote this little program, Created a simulator circuit model and also a similar hardware circuit.

Here is the Code:

' RBC TEST.BAS
' PIC 18F6480
' 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

INCLUDE "DT_INTS-18.bas"		; Include Darrel Taylor's Base Interrupt System for PIC18F [Version:3.4 (NOV 04, 2009)]

DEFINE OSC 20
DEFINE DEBUG_REG PORTC	
DEFINE DEBUG_BIT 6 			
DEFINE DEBUG_BAUD 57600
DEFINE DEBUG_MODE 1 
DEFINE  SHOWDIGITAL 1

TRISB=%11111111
ADCON0=%00000000
ADCON1=%00001111

BTN	  VAR	BYTE

ASM
INT_LIST  macro ; IntSource,  Label,      Type,  ResetFlag?
        INT_Handler RBC_INT, _DO_RBC_INT,   ASM,  yes	
    endm
    INT_CREATE
ENDASM

@  INT_ENABLE   RBC_INT

DEBUG "INTERRUPT CREATED",10,13
DEBUG "INTERRUPT ENABLED",10,13

HOLD_HERE:
DEBUG "WAITING FOR INTERRUPT",10,13
PAUSE 2500
GOTO HOLD_HERE

DO_RBC_INT
DEBUG "############### RBC INTERRUPT ACTIVATED #################",10,13

MENU:
PAUSE 200
DEBUG "MENU - READ BUTTONS",10,13
If PORTB.4 = 1 Then PAUSE 250: Goto DO_ENABLE
If PORTB.5 = 1 Then PAUSE 250: Goto DO_DISABLE
If PORTB.6 = 1 Then PAUSE 250: Goto DO_RETURN
If PORTB.7 = 1 Then PAUSE 250: Goto DO_CLEAR
GOTO MENU

DO_ENABLE:
DEBUG "RUNNING DO_ENABLE",10,13
@ INT_ENABLE RBC_INT
Pause 250
GOTO HOLD_HERE

DO_DISABLE:
DEBUG "RUNNING DO_DISABLE",10,13
@ INT_DISABLE RBC_INT
PAUSE 250
GOTO HOLD_HERE

DO_RETURN:
DEBUG "RUNNING DO_RETURN",10,13
@ INT_RETURN
PAUSE 250
GOTO HOLD_HERE

DO_CLEAR:
DEBUG "RUNNING DO_CLEAR",10,13
@ INT_CLEAR RBC_INT
PAUSE 250
GOTO HOLD_HERE

END

Here is the Circuit:


There are 4 buttons connected to PORT B <4.7>
Here are my observations:

The first press of any button activates the RBC Interrupt and sends program to DO_RBC_INT subroutine, then on to MENU where it checks for button presses. This behaves exactly as I would expect it to.

Now...After that....

Pressing Button RB.4 [ENABLE] Runs the DO_ENABLE subroutine then the HOLD_HERE subroutine. At this point, the Interrupt handler seems to shut down as no Port B inputs activate the interrupt handler. I would expect the Interrupt to remain active.

Pressing Button RB.5 [DISABLE] Runs the DO_DISABLE subroutine then the HOLD_HERE subroutine. The Interrupt handler is now disabled as expected.

Pressing Button RB.6 [RETURN] Runs the DO_RETURN subroutine then the HOLD_HERE subroutine. It then sends program to DO_RBC_INT subroutine, then on to MENU. I would expect it to return to HOLD_HERE which is wherr the interrupt was originally activated

Pressing Button RB.7 [CLEAR] Runs the DO_CLEAR subroutine. At this point, the Interrupt handler seems to shut down as no Port B inputs activate the interrupt handler. I would expect this to just clear the interrupt then await another RBC trigger.

So it seems I can only activate the interrupt one time.

It doesn't seem to matter whether I use ASM or PBP types or set Resetflag to yes, or no

Can anyone shed light on what I'm doing wrong, or am I simply misinterpreting the function of the INT_* utilities.

I'm just not sure if I've got a mistake, am staying up too late working on this stuff, or just really don't get it.

Thanks,
Bob

[Darrel Taylor]

The idea of an Interrupt, is that it Stops the normal flow of the program ... executes an Interrupt Service Routine (ISR) ... then RETURNs back to the same point it was at when it was Interrupted.

You can't go back to the Main Loop without INT_RETURN'ing.
In other words ... no GOTO HOLD_HERE.
<br>

[WOZZY-2010]

Darrel,

Thanks for the quick reply.

I made a cut & paste error in my last post.

It should have stated:
Pressing Button RB.6 [RETURN] Runs the DO_RETURN subroutine. It then sends program to DO_RBC_INT subroutine, then on to MENU. I would expect it to return to HOLD_HERE which is where the interrupt was originally activated.

Pressing Button RB.7 [CLEAR] Runs the DO_CLEAR subroutine Then the HOLD_HERE. At this point, the Interrupt handler seems to shut down as no Port B inputs activate the interrupt handler. I would expect this to just clear the interrupt then await another RBC trigger.

I agree that it should never get to the GOTO HOLD_HERE statement, at the end of DO_RETURN:, but should still end up in HOLD_HERE since that is where the program was was when the RBC_INT interrupt was initially activated.