DT_INTS-18 - problem with INT0

[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