Not until seeing your question. That seems to do it. It compiles and only uses 593 words so I think it will be OK, now.Originally Posted by Darrel Taylor
Will the pin change functions work with the 12F683?
Not until seeing your question. That seems to do it. It compiles and only uses 593 words so I think it will be OK, now.Originally Posted by Darrel Taylor
Will the pin change functions work with the 12F683?
Last edited by dhouston; - 1st August 2006 at 16:16.
Awesom,
Sure will.Will the pin change functions work with the 12F683?
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>
DT
Thanks. Spending $0.25-0.30 more for the 12F683 vs. the 12F629 is worth it to be able to use Instant Interrupts.Originally Posted by 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,
DT
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.Originally Posted by DynamoBen
Steve
Thanks Steve, I forgot that he was using a separate version for the 18Fs.
Originally Posted by DynamoBen
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
![]()
Last edited by Demon; - 15th August 2006 at 04:22.
My Creality Ender 3 S1 Plus is a giant paperweight that can't even be used as a boat anchor, cause I'd be fined for polluting our waterways with electronic devices.
Not as dumb as yesterday, but stupider than tomorrow!
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
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
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 ...
DT
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 :-)
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:
Here is the Circuit: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
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
Wozzy-2010
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>
DT
Bookmarks