Post by thread:debounce

I'll cc this to the pic list since this thread is currently being discussed. On Wed, 16 Feb 2000, sep wrote: {Quote hidden}> Hi, > I think that your idea for debouncing the button is really cool. I am just a > little unsure of how to apply that to de-bouncing a switch directly. > > I am using the 16f84 and so I want to debounce 4 of the pins (a switch > attached on each). And then when the buttons are pressed to goto: > > button1touched > button2touched > button3touched > button4touched > > > Is there any snippets you have or any help you could give me. Sorry I am > just a beginner trying to get through these (probably easy) things! > > I appreciate your help. There are probably dozens of ways going about this. Let me pick the one I'd most probably choose. In most pic programs I write, there's usually an interrupt process (or several processes) like the TMR0 interrupt and then there's a foreground polling loop. The interrupt process responds as fast as possible to the needs of the hardware and does as little as possible. (Basically, just clear the pending interrupts and setting flags to notify the foreground that there's work to be done.) The foreground loop does the bulk of the work. Since you only have four switches, you only need four bits of the 8 bits in the variables used in the filters. I'd snatch one as a flag and do this: every 20 to 50 or so milliseconds (possibly in an interrupt routine), sample the I/O port that is attached to your switches. I'll assume that it's the lower four bits in PORTA: movf PORTA,w ;Read the current switch setting iorlw 0x80 ;Set the msb - this is 'we have data' flag movwf csa ;This is the name of the variable used in ;the debounce routine Then within your main fore-ground loop btfss csa,7 ;If there's a sample, process it goto next_polled_item #ifndef RICH_LEGGIT ; :) call de_bounce #else movf csa,w movwf cva #endif bcf csa,7 ;Clear the flag movf last_sample,w ;get the previous sample xorwf cva,w ;compare to the current xorwf last_sample,f ;save the current sample as the last andwf last_sample,w ;Monitor only changes that went high movwf temp btfsc temp,0 call button1touched btfsc temp,1 call button2touched btfsc temp,2 call button3touched btfsc temp,3 call button4touched The useful trick is: A ^ B ^ A = B Scott

On Wed, 16 Feb 2000, sep wrote: > Hello again, [the de-bouncing continues....] > > Two things. > > 1) > > goto next_polled_item > > where does this go? Well, that depends. Sometimes I structure my foreground tasks like this: task_loop btfsc task_flags,TASK_0 call task_0 btfsc task_flags,TASK_1 call task_1 etc. goto task_loop in the example I posted previously, I illustrated a similar but different approach: task_loop: btfss task_flags,TASK_0 goto check_task_1 task_0: ; code for task 0 ... check_task_1: btfss task_flags,TASK_1 goto check_task_2 ; code for task 1 check_task_2: and so on... goto task_loop In your case, you may not have any other 'tasks'. So all you'd do is simply loop back and check if the debounce flag has become true. > 2) > I'm not sure I get the following asm conditional: > > > #ifndef RICH_LEGGIT ; :) > > call de_bounce > > #else > > movf csa,w > > movwf cva > > #endif It's a jab at Rich Leggit's (mostly true) statement that the need for debounce routines is a myth. If you can poll the switches at rate slower than the debounce time constant and fast enough to satisfy the user's expectations, then under sampling works great. In fact, I never have seen a mechanical switch bounce for so long that the user had to keep it pressed just to register an accurate response. Debouncing is more useful for reading relay contacts and obtaining fairly accurate change-of-state time-tagging info. For example, a common application in the utility industry is to measure 'sequence of events' or SOE's. The events are almost alway relay contacts and there are usually a whole bunch of them and they all need to be time tagged with typically 1ms resolution. Scott

Hee hee, I knew that would, er, push someone's button. :) So: consider the case where sampling occurs every 50 mS. A state change occurs at time T, and causes 'bounce' for (we presume) no more than 50mS. The next sample, S1, will occur at some time before T+50mS. The second sample, S2, will occur sometime after T+50mS and is thus guaranteed a steady state. Therefore we only need to worry about S1, for which there are three possibilities: 1-the input is stable in the new state. 2-the input is bouncing, but appears to have changed state. 3-the input is bouncing, but appears not to have changed state. In cases 1 and 2, the state change is detected on S1. In case 2, the state change is not detected until S2. The worst case detect time is 100 mS. Now, if you're worried about NOISE, i.e. transient contacts due to mechanical shock, button at the end of 200 feet of wire, etc. then you need a low pass filter: the classical 'debounce' algorithm (yes, these examples come from experience :) But for switches right there on the PCB? Save the code, debounce not required. --- Rich On Wed, 16 Feb 2000, Scott Dattalo wrote: {Quote hidden}> Date: Wed, 16 Feb 2000 12:46:40 -0600 > From: Scott Dattalo <spam_OUTscottTakeThisOuTDATTALO.COM> > Reply-To: pic microcontroller discussion list <.....PICLISTKILLspam@spam@MITVMA.MIT.EDU> > To: PICLISTKILLspamMITVMA.MIT.EDU > Subject: Re: debounce > > I'll cc this to the pic list since this thread is currently being > discussed. > > On Wed, 16 Feb 2000, sep wrote: > > > Hi, > > I think that your idea for debouncing the button is really cool. I am just a > > little unsure of how to apply that to de-bouncing a switch directly. > > > > I am using the 16f84 and so I want to debounce 4 of the pins (a switch > > attached on each). And then when the buttons are pressed to goto: > > > > button1touched > > button2touched > > button3touched > > button4touched > > > > > > Is there any snippets you have or any help you could give me. Sorry I am > > just a beginner trying to get through these (probably easy) things! > > > > I appreciate your help. > > > There are probably dozens of ways going about this. Let me pick the one > I'd most probably choose. In most pic programs I write, there's usually an > interrupt process (or several processes) like the TMR0 interrupt and then > there's a foreground polling loop. The interrupt process responds as fast > as possible to the needs of the hardware and does as little as possible. > (Basically, just clear the pending interrupts and setting flags to notify > the foreground that there's work to be done.) The foreground loop does the > bulk of the work. > > Since you only have four switches, you only need four bits of the 8 bits > in the variables used in the filters. I'd snatch one as a flag and do > this: > > > every 20 to 50 or so milliseconds (possibly in an interrupt routine), > sample the I/O port that is attached to your switches. I'll assume that > it's the lower four bits in PORTA: > > movf PORTA,w ;Read the current switch setting > iorlw 0x80 ;Set the msb - this is 'we have data' flag > movwf csa ;This is the name of the variable used in > ;the debounce routine > > > Then within your main fore-ground loop > > btfss csa,7 ;If there's a sample, process it > goto next_polled_item > > > #ifndef RICH_LEGGIT ; :) > call de_bounce > #else > movf csa,w > movwf cva > #endif > > bcf csa,7 ;Clear the flag > > movf last_sample,w ;get the previous sample > xorwf cva,w ;compare to the current > xorwf last_sample,f ;save the current sample as the last > andwf last_sample,w ;Monitor only changes that went high > > movwf temp > > btfsc temp,0 > call button1touched > > btfsc temp,1 > call button2touched > > btfsc temp,2 > call button3touched > > btfsc temp,3 > call button4touched > > > The useful trick is: > > A ^ B ^ A = B > > Scott >