DT_INTS-18 - problem with INT0

[AndrewC]

Hi,

I'm using DT_INTS to interrupt on INT0 for a PIC 18F4431
The interrupt works fine but seems to trigger on both arising and falling edge.
Tried to configure the PIC to only look at the falling edge but it doesn't seem t0 make any difference.

Here's a snip of the troublesome code, what am I doing wrong ? Is there a parameter inside the DT_INTS I need to set ?



' set fuses - USE INC FILE FOR NOW

include "modedefs.bas" ' serial modes
INCLUDE "DT_INTS-18.bas" ' Base Interrupt System
INCLUDE "ReEnterPBP-18.bas" ' Include if using PBP interrupts


' ---- setup registers ----------------------------
ADCON0 = 0 ' A/D off
ADCON1 = 0
ADCON2 = 0
ADCON3 = 0
ANSEL0 = 0 'digital i/o
ANSEL1 = 0
INTCON.4 = 1 'enable INT0
INTCON2.7 = 0 'pullups on
INTCON2.6 = 0 ' Int 0 on falling edge of C3

ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler INT0_INT, _ManualFire, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM


'---[INT0 - interrupt handler]--------------------------------------------------
ManualFire:
Camera_meter = 1
Camera_shutter = 1
pause 10
Camera_meter = 0
Camera_shutter = 0
@ INT_RETURN

end

[circuitpro]

I'm having a similar issue with INT1, so am watching to see what we learn.

[HenrikOlsson]

Hi,
What do you trig INT0 with? If it's a pushbutton you may have contact bounce that makes the interrupt fire multiple times. The 10mS pause in the ISR provides some debounce but perhaps it's not enough.

Also, I don't see

@ INT_ENABLE INT0_INT ; enable external (INT) interrupts
anywhere. I see that you "manually" enable the INT0 interrupt but try using the provided macro, to begin with at least.

/Henrik.

[Charles Linquis]

To solve debounce problems, you can test for PORTB = 0 (or 1 if you are triggering on a rising edge). Don't leave the ISR unless the button is in the un-pressed state.

[AndrewC]

I am triggering off a pushbutton but it is not debounce - it triggers once when I press the button, and again when I release.

I thought of adding an "exit delay" to miss the release, but that fixes the symptoms and I'd like to understand the cause :)

Macro for enabling the interrupt: hmmm - I'll try that tomorrow but is there a macro anywhere that defines which edge to interrupt off or should I stick with INTCON2.6 line ? I'm also going to try moving that statement after the interrupt create ASM section.

Thanks, Andrew

[Gusse]

Remove this one. And reason can be found from here (http://www.picbasic.co.uk/forum/showpost.php?p=78112&postcount=468) .

INTCON.4 = 1 'enable INT0

BR,
-Gusse-

[AndrewC]

Okeydokey - so I'll take out the INTCON lines but then where do I tell the D_INTS whether to trigger on a rising or falling edge ?

Andrew

ps: I'll add this question to the main D_INTS thread as it might be of interest to others.

[Acetronics2]

Hi, Andrew

you sure ?



INTCON2.6 = 0 ' Int 0 on falling edge of C3



a look to INTCON2 register could help ...

Darrel's goodie only enables/Disables the interrupts ... it's you to set interrupt conditions.

Bouncing looks here a more than a valid reason for "false triggering" ...

Alain

[Gusse]

Hi Andrew,

This is OK, interrupt on falling edge.

INTCON2.6 = 0

Also add that INT_ENABLE part as Henrik suggested. Then it should work.

Q: Isn't it so that INT_Handler execution cannot be interrupted (e.g interrupt in interrupt sequence)?
If yes, then debounce filtering is not needed, because first falling edge trigger INT_Handler. Ringing is ignored during interrupt execution time.

BR,
-Gusse-

[Ioannis]

Try something like this to see how it goes.

It just waits to free the button.

I know Darrel will spank me for this, but hey, it is just for testing!

Ioannis




' set fuses - USE INC FILE FOR NOW

include "modedefs.bas" ' serial modes
INCLUDE "DT_INTS-18.bas" ' Base Interrupt System
INCLUDE "ReEnterPBP-18.bas" ' Include if using PBP interrupts


' ---- setup registers ----------------------------
ADCON0 = 0 ' A/D off
ADCON1 = 0
ADCON2 = 0
ADCON3 = 0
ANSEL0 = 0 'digital i/o
ANSEL1 = 0
INTCON.4 = 1 'enable INT0
INTCON2.7 = 0 'pullups on
INTCON2.6 = 0 ' Int 0 on falling edge of C3

ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler INT0_INT, _ManualFire, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM


'---[INT0 - interrupt handler]--------------------------------------------------
ManualFire:
Camera_meter = 1
Camera_shutter = 1
pause 10
Camera_meter = 0
Camera_shutter = 0
while portb.0=0:pause 10:wend
@ INT_RETURN

end

[AndrewC]

Hi, Andrew

you sure ?




a look to INTCON2 register could help ...

Darrel's goodie only enables/Disables the interrupts ... it's you to set interrupt conditions.

Bouncing looks here a more than a valid reason for "false triggering" ...

Alain

At first I thought it couldn't be a bounce, but then I was just thinking of a "bounce" as I pressed the button. Obviously, a push button can bounce as you release it as well. Simplest thing is probably to just build a delay into the interrupt routine - timing isn't critical in this application and there is no problem holding in the interrupt routine for a few hundred msecs.

Andrew

[AndrewC]

Try something like this to see how it goes.

It just waits to free the button.

I know Darrel will spank me for this, but hey, it is just for testing!

Ioannis




' set fuses - USE INC FILE FOR NOW

include "modedefs.bas" ' serial modes
INCLUDE "DT_INTS-18.bas" ' Base Interrupt System
INCLUDE "ReEnterPBP-18.bas" ' Include if using PBP interrupts


' ---- setup registers ----------------------------
ADCON0 = 0 ' A/D off
ADCON1 = 0
ADCON2 = 0
ADCON3 = 0
ANSEL0 = 0 'digital i/o
ANSEL1 = 0
INTCON.4 = 1 'enable INT0
INTCON2.7 = 0 'pullups on
INTCON2.6 = 0 ' Int 0 on falling edge of C3

ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler INT0_INT, _ManualFire, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM


'---[INT0 - interrupt handler]--------------------------------------------------
ManualFire:
Camera_meter = 1
Camera_shutter = 1
pause 10
Camera_meter = 0
Camera_shutter = 0
while portb.0=0:pause 10:wend
@ INT_RETURN

end


That would be a neat way of waiting for the pushbutton to release, but shouldn't there also be a pause after the WHILE loop to debounce when releasing the button ?

What you and Darrel do in your private life is between you :) !

Andrew

[HenrikOlsson]

Hi,

Q: Isn't it so that INT_Handler execution cannot be interrupted (e.g interrupt in interrupt sequence)?
If yes, then debounce filtering is not needed, because first falling edge trigger INT_Handler. Ringing is ignored during interrupt execution time.
Yes, (as long as we're not talking low priority interrupts) but if the switch bounces longer than the time it takes to execute the ISR then it will get triggered again as soon as it leaves the interrupt routine.

The while-wend loop won't solve the problem either. If the switch bounces, the while-loop may check it at a moment when it's high and then exit the ISR, the switch continues to bounce and trips the interrupt again. The switch probably bounces on release as well so even if the while-loop manages to the job "sometimes" it's likely that once the button is released causing the program to leave the ISR, it will bounce and trip the interrupt again.

How about trying a bit of hardware, a single capacitor should do it.

/Henrik.

[Ioannis]

Just post it to be sure that after this modification it will work OK. If it does, then sure the de-bounce is an issue here.

If not, then we have to look elsewhere, though I doubt.

Ioannis

[Gusse]

How about trying a bit of hardware, a single capacitor should do it.
I fully agree with Henrik. And a small RC-loop would be even better.

If return from INT_Handler is not critical, then just add

PAUSE 100 'or some shorter time
as a last comment in interrupt routine.

BR,
-Gusse-

[circuitpro]

I am suffering from the worst contact bounce I've ever seen.

I'm using the INT line on a PCF8574 and thought it latched until the chip was read... false... it latches until it is read OR is returned to it's original state (which offers no help whatsoever in the case of contact bounce!)... and the INTCON2.6 settings to work on rising or falling edges doesn't help either, so simply added a .1uF cap on the INT line right at the CPU to ground, and it 100% debounced the interrupt.

Sometimes a 10-cent hardware solution is still the best.

[AndrewC]

Couple of closing comments from me:

1) didn't seem to make any difference whether I used INTCON.4 = 1 or the @ INT ENABLE

2) This particular routine when in use needs to have a 1sec exit pause anyway so I just debounced with a pause statement

All's well that ends well - thanks for pointing me at key bouncing :)

Andrew