Button Debounce Coding help - Page 2 - Electronic Circuits Projects Diagrams Free

bananasiong · 3rd August 2007, 03:17 AM

Quote:

Originally Posted by Suraj143

Wow what a video thanks donniedj I now understand.I applied Oznog codings it comes like this

Code:

	btfsc	PORTA,0		;check the button is pressed?
	goto	SHOW		;NO its not pressed then display the digits
	call	DEL500mS	;YES its pressed then add a small debounce delay
	btfss	PORTA,0		;check the button has it released?
	goto	SHOW		;NO then again show the digits
	goto	COUNTUP		;YES it has released then count up

But the problem is when increase the debounce delay time when i press the button & hold the segment displays going dim.When i reduce the debounce delay it counts up in a messy way.

can you tell me is my coding right & what modifications to be done?

It is because during the period you press and hold, no multiplexing is happening because it is looping in the delay routine. But if you reduce the debounce delay time, it is not enough for it to debounce, causing it counts up many times (I think so).
Why don't you put the display routine in the ISR? So you don't need bother about the displaying.

Suraj143 · 3rd August 2007, 03:25 AM

Hi banansiong I’m not familiar with much more ISR.
I applied your codings too replacing the goto SHOW with goto $-1 after btfss command.

That worked well but within the button pressed time the whole display is going off that is better without dimming the display.

But I still trying to have a smooth count in my coding without going to ISR.
Any suggestions will be greatly appreciated.

Oznog · 3rd August 2007, 03:29 AM

It's worthwhile to ask just what's so bad about making a debounce period longer than necessary? Well, if it's too long a second press would get interpreted as a bounce and ignored. But then who presses a button 10 or even 5 times a second? Probably advancing through a list of mp3 tracks or scrolling down a display, or- wait I know- advancing the alarm on a digital clock once you've let off the spin it does when you hold it down and need to step it minute-by-minute. Not sure how fast those are. Note that some buttons won't even pop back up fast enough to be pressed at such a frenetic pace.

Sometimes you get a crappy button in a bag of them, or one gets bouncier as it ages. As such it may be a good idea to figure out at what point is it possible that the debounce time will miss valid presses and set it substantially less than that, so it can be as tolerant as possible to bouncing.

Pommie · 3rd August 2007, 03:34 AM

You can use your show routine as a debounce delay.

Code:

loop		call	SHOW
		btfsc	PORTA,0
		goto	loop;	not pressed so wait
; is pressed
		call	COUNTUP
loop1		call	SHOW
		btfss	PORTA,0
		goto	loop1;	still pressed, so wait

		goto	loop

Mike.

Oznog · 3rd August 2007, 03:37 AM

Quote:

Originally Posted by Suraj143

Hi banansiong I’m not familiar with much more ISR.
I applied your codings too replacing the goto SHOW with goto $-1 after btfss command.

That worked well but within the button pressed time the whole display is going off that is better without dimming the display.

But I still trying to have a smooth count in my coding without going to ISR.
Any suggestions will be greatly appreciated.

ISRs can implement the debounce in one of two ways- set a timer resource (all have ISRs associated with them), when the timer counts down reenable the ability to react to a press. Bad part is that unless you pull some fancy coding you need one timer per button and this can be a problem.

The other possibility is to have a timer that expires say every 25mS. The timer ISR decrements the debounce timer and reenabled the button at zero. So when you detect a press you might set the counter to 3 for a 75mS debounce time. Downside is that the period of the first count is uncertain because the counter is already running when the button is pressed- it might make a debounce period of 51mS to 75mS in this case. Frequent interrupt tend to eat up the processing time esp if you're running low freq clocks. They also mean you can't use SLEEP mode mid-code to save power. We could pull a trick to disable the timer if no debounce counter needs to be decremented, a really good idea actually, you just need to be very careful with what you're doing.

Suraj143 · 3rd August 2007, 03:39 AM

Wow what a piece of code Mike I will try your coding & tell the progress.It should work for sure.

Thanks Mike.

Suraj143 · 3rd August 2007, 03:43 AM

Thanks Oznog I'm going to study your codings as soon as possible.

bananasiong · 3rd August 2007, 04:07 AM

Use Pommie's code, for sure the displays won't turn off or dim or get crazy

. But make sure you return from the label SHOW. So you don't need to use ISR if you're not familiar with it.

Mike, K8LH · 3rd August 2007, 05:09 PM

Oznog,

I've discovered and developed some relatively simple and reliable methods for debouncing and managing multiple switches over the last few years. Would you mind if I share them with you?

First, I use relatively simple switch state latch logic for managing one to eight switches (in parallel). Using a switch state latch allows you to process and act on a "new" debounced switch press or a "new" debounced switch release while ignoring the remaining portion of a switch cycle (how long the switch is pressed or released).

Code:

;
SWKEYS  equ     0x20            ; debounced switch bits, '1' = pressed
SLATCH  equ     0x21            ; switch state latch
SWITCH  equ     0x22            ; switch flag bits for MAIN
;
;  this routine transfers a new debounced switch press to the SWITCH
;  variable for MAIN
;
ISR_Switch_Press
        movf    SWKEYS,W        ; debounced switch bits
        xorwf   SLATCH,W        ; each '1' is a change (press or release)
        andwf   SWKEYS,W        ; each '1' is a "new" switch press
        xorwf   SWITCH,F        ; toggle switch flag bits for use by MAIN
        movf    SWKEYS,W        ; update switch state latch
        movwf   SLATCH          ;
;
;  this routine transfers a new debounced switch release to the SWITCH
;  variable for MAIN
;
ISR_Switch_Release
        movf    SWKEYS,W        ; debounced switch bits
        xorwf   SLATCH,W        ; each '1' is a change (press or release)
        andwf   SLATCH,W        ; each '1' is a "new" switch release
        xorwf   SWITCH,F        ; toggle switch flag bits for use by MAIN
        movf    SWKEYS,W        ; update switch state latch
        movwf   SLATCH          ;

There are several different ways your MAIN program can process a switch press flag bit in the SWITCH variable (or a switch release flag bit if you're using the "release" algorithm). Let's say we've defined a switch called "sw_UP" as bit 0 in the SWITCH variable. Here's one way you might process that switch in MAIN;

Code:

;
;  test "UP" switch
;
Test_UP btfss   sw_UP           ; is SWITCH,0 a '1' (new switch press)?
        goto    Test_DOWN       ; no, branch, else
        bcf     sw_UP           ; clear bit so we don't process again
; perform "UP" code here
;

The previous example is for momentary type switch functions where we press a switch, perform some function, and we're done. We clear the flag bit after we test it and it won't get set again until the user releases the switch and presses it again.

We can also use our standard momentary push button switches to emulate toggle switches. That is, press a switch to toggle the switch flag bit from on-to-off or from off-to-on. This is extremely handy for lighted push button switches. Push it once to light the LED then push it again to toggle the LED off. In this case the only difference in the way you process the switch in MAIN is that you don't need to clear the switch flag bit after testing it. It gets toggled automatically in the ISR after each "new" press.

Code:

;
;  test SET mode toggle switch flag
;
SET     btfss   sw_SET          ; is SWITCH,1 a '1' (SET mode on)?
        goto    NextProc        ; no, branch, else
;
;  perform SET functions in SET_loop
;
SET_loop
;
;  has SET mode been turned off
;
        btfsc   sw_SET          ; SET switch still on?
        goto    SET_loop        ; yes, continue SET operations, else
;
;  save any changes and exit
;

And if I haven't bored you to death, here's one last extremely simple addition to that ISR code that provides us with a switch press beep. The additional code sends a short 32 msec 500 Hz beep when it detects "new" switch press bits in W.

Code:

;
SWKEYS  equ     0x20            ; debounced switch bits, '1' = pressed
SLATCH  equ     0x21            ; switch state latch
SWITCH  equ     0x22            ; switch flag bits for MAIN

BEEP    equ     0x23            ; beep timer
;
;  process "new" debounced switch "presses"
;
ISR_Switch_Press
        movf    SWKEYS,W        ; debounced switch bits
        xorwf   SLATCH,W        ; each '1' is a change (press or release)
        andwf   SWKEYS,W        ; each '1' is a "new" switch press
;
        skpz                    ; any "new" presses?  no, skip, else
        bsf     BEEP,5          ; send short 32-msec 500-Hz "beep"
;
        xorwf   SWITCH,F        ; toggle switch flag bits for use by MAIN
        movf    SWKEYS,W        ; update switch state latch
        movwf   SLATCH          ;
;
;  BEEP routine (500-Hz when using 1 msec interrupts)
;
        movf    BEEP,W          ; beep timer set?
        bz      ISR_Next        ; no, branch, else
        movf    PORTA,W         ;
        xorlw   1<<SPKR         ; toggle SPKR port bit in W
        movwf   PORTA           ; toggle actual SPKR pin
        decf    BEEP,F          ; decrement beep timer
;
ISR_Next

Not bad for 15 words, yes, no?

The important thing to note about this code and method is that it simply tests the switches during each 1 msec interrupt and doesn't tie up the processor unnecessarily by waiting for a switch to change state.

I've also developed some similarly "tight" code for implementing multiple independant debounce timers (which work on both press and release), repeat timers, etc., but they use vertical counters which seems completely alien to most people so I won't impose those algorithms on you folks at this time (grin).

Regards, Mike

donniedj · 3rd August 2007, 10:56 PM

Here the request pics of a my tact switch during release. When zoomed out the button press always looks very clean. Yet its a different story when a 1 GS/s digital scope is called into action on the front line

.

ljcox · 4th August 2007, 09:48 AM

Pommie,
I tried to send you a PM but your inbox is full.

Len

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Latest
odd project, 1 button adds a light 1 button takes a light away with sound.	KevinAlaska	Electronic Projects Design/Ideas/Reviews	15	6th June 2007 04:38 AM
Please help me in writing code	abdosat2000	Micro Controllers	9	5th June 2007 01:40 PM
1 Hour Timer PIC 16F628A (Set Button)	Suraj143	Micro Controllers	11	26th April 2007 03:54 AM
button midi keyboard	jjjjjj	General Electronics Chat	2	20th March 2006 04:10 PM
Push Button On/Off power to PIC	eblc1388	Micro Controllers	8	17th February 2006 01:31 PM

3rd August 2007, 03:25 AM	(permalink)
Suraj143	Hi banansiong I’m not familiar with much more ISR. I applied your codings too replacing the goto SHOW with goto $-1 after btfss command. That worked well but within the button pressed time the whole display is going off that is better without dimming the display. But I still trying to have a smooth count in my coding without going to ISR. Any suggestions will be greatly appreciated.

3rd August 2007, 03:29 AM	(permalink)
Oznog	It's worthwhile to ask just what's so bad about making a debounce period longer than necessary? Well, if it's too long a second press would get interpreted as a bounce and ignored. But then who presses a button 10 or even 5 times a second? Probably advancing through a list of mp3 tracks or scrolling down a display, or- wait I know- advancing the alarm on a digital clock once you've let off the spin it does when you hold it down and need to step it minute-by-minute. Not sure how fast those are. Note that some buttons won't even pop back up fast enough to be pressed at such a frenetic pace. Sometimes you get a crappy button in a bag of them, or one gets bouncier as it ages. As such it may be a good idea to figure out at what point is it possible that the debounce time will miss valid presses and set it substantially less than that, so it can be as tolerant as possible to bouncing. __________________ I thought what I'd do was I'd pretend I was one of those deaf-mutes.

3rd August 2007, 03:34 AM	(permalink)
Pommie	You can use your show routine as a debounce delay. Code: loop call SHOW btfsc PORTA,0 goto loop; not pressed so wait ; is pressed call COUNTUP loop1 call SHOW btfss PORTA,0 goto loop1; still pressed, so wait goto loop Mike.

3rd August 2007, 03:39 AM	(permalink)
Suraj143	Wow what a piece of code Mike I will try your coding & tell the progress.It should work for sure. Thanks Mike.

3rd August 2007, 03:43 AM	(permalink)
Suraj143	Thanks Oznog I'm going to study your codings as soon as possible.

3rd August 2007, 04:07 AM	(permalink)
bananasiong	Use Pommie's code, for sure the displays won't turn off or dim or get crazy . But make sure you return from the label SHOW. So you don't need to use ISR if you're not familiar with it. __________________ Superman returns..

3rd August 2007, 05:09 PM	(permalink)
Mike, K8LH	Oznog, I've discovered and developed some relatively simple and reliable methods for debouncing and managing multiple switches over the last few years. Would you mind if I share them with you? First, I use relatively simple switch state latch logic for managing one to eight switches (in parallel). Using a switch state latch allows you to process and act on a "new" debounced switch press or a "new" debounced switch release while ignoring the remaining portion of a switch cycle (how long the switch is pressed or released). Code: ; SWKEYS equ 0x20 ; debounced switch bits, '1' = pressed SLATCH equ 0x21 ; switch state latch SWITCH equ 0x22 ; switch flag bits for MAIN ; ; this routine transfers a new debounced switch press to the SWITCH ; variable for MAIN ; ISR_Switch_Press movf SWKEYS,W ; debounced switch bits xorwf SLATCH,W ; each '1' is a change (press or release) andwf SWKEYS,W ; each '1' is a "new" switch press xorwf SWITCH,F ; toggle switch flag bits for use by MAIN movf SWKEYS,W ; update switch state latch movwf SLATCH ; ; ; this routine transfers a new debounced switch release to the SWITCH ; variable for MAIN ; ISR_Switch_Release movf SWKEYS,W ; debounced switch bits xorwf SLATCH,W ; each '1' is a change (press or release) andwf SLATCH,W ; each '1' is a "new" switch release xorwf SWITCH,F ; toggle switch flag bits for use by MAIN movf SWKEYS,W ; update switch state latch movwf SLATCH ; There are several different ways your MAIN program can process a switch press flag bit in the SWITCH variable (or a switch release flag bit if you're using the "release" algorithm). Let's say we've defined a switch called "sw_UP" as bit 0 in the SWITCH variable. Here's one way you might process that switch in MAIN; Code: ; ; test "UP" switch ; Test_UP btfss sw_UP ; is SWITCH,0 a '1' (new switch press)? goto Test_DOWN ; no, branch, else bcf sw_UP ; clear bit so we don't process again ; perform "UP" code here ; The previous example is for momentary type switch functions where we press a switch, perform some function, and we're done. We clear the flag bit after we test it and it won't get set again until the user releases the switch and presses it again. We can also use our standard momentary push button switches to emulate toggle switches. That is, press a switch to toggle the switch flag bit from on-to-off or from off-to-on. This is extremely handy for lighted push button switches. Push it once to light the LED then push it again to toggle the LED off. In this case the only difference in the way you process the switch in MAIN is that you don't need to clear the switch flag bit after testing it. It gets toggled automatically in the ISR after each "new" press. Code: ; ; test SET mode toggle switch flag ; SET btfss sw_SET ; is SWITCH,1 a '1' (SET mode on)? goto NextProc ; no, branch, else ; ; perform SET functions in SET_loop ; SET_loop ; ; has SET mode been turned off ; btfsc sw_SET ; SET switch still on? goto SET_loop ; yes, continue SET operations, else ; ; save any changes and exit ; And if I haven't bored you to death, here's one last extremely simple addition to that ISR code that provides us with a switch press beep. The additional code sends a short 32 msec 500 Hz beep when it detects "new" switch press bits in W. Code: ; SWKEYS equ 0x20 ; debounced switch bits, '1' = pressed SLATCH equ 0x21 ; switch state latch SWITCH equ 0x22 ; switch flag bits for MAIN BEEP equ 0x23 ; beep timer ; ; process "new" debounced switch "presses" ; ISR_Switch_Press movf SWKEYS,W ; debounced switch bits xorwf SLATCH,W ; each '1' is a change (press or release) andwf SWKEYS,W ; each '1' is a "new" switch press ; skpz ; any "new" presses? no, skip, else bsf BEEP,5 ; send short 32-msec 500-Hz "beep" ; xorwf SWITCH,F ; toggle switch flag bits for use by MAIN movf SWKEYS,W ; update switch state latch movwf SLATCH ; ; ; BEEP routine (500-Hz when using 1 msec interrupts) ; movf BEEP,W ; beep timer set? bz ISR_Next ; no, branch, else movf PORTA,W ; xorlw 1<<SPKR ; toggle SPKR port bit in W movwf PORTA ; toggle actual SPKR pin decf BEEP,F ; decrement beep timer ; ISR_Next Not bad for 15 words, yes, no? The important thing to note about this code and method is that it simply tests the switches during each 1 msec interrupt and doesn't tie up the processor unnecessarily by waiting for a switch to change state. I've also developed some similarly "tight" code for implementing multiple independant debounce timers (which work on both press and release), repeat timers, etc., but they use vertical counters which seems completely alien to most people so I won't impose those algorithms on you folks at this time (grin). Regards, Mike Last edited by Mike, K8LH; 4th August 2007 at 01:29 AM.

3rd August 2007, 10:56 PM	(permalink)
donniedj	Here the request pics of a my tact switch during release. When zoomed out the button press always looks very clean. Yet its a different story when a 1 GS/s digital scope is called into action on the front line . __________________ I can still log in! Delete my account and all my post now.

4th August 2007, 09:48 AM	(permalink)
ljcox	Pommie, I tried to send you a PM but your inbox is full. Len __________________ Len