Electronic – PIC12F509 Switch Debouncing On Press Release Or Both

microcontroller

I have a question regarding switch debouncing I'm using a PIC12F509 and the internal RC oscillator operating at 4 MHz.

I'm toggling an LED on and off connected to GP1 (output) via a momentary push button switch on GP3 (input) which is held high via a 10K resistor when the switch is open. I'm using the following macro and the code below to debounce the push button switch. It utilizes timer 0 set to a 1:256 prescale.

It waits until the contacts have remained in the same state (open in this case) for 10 milliseconds before executing the rest of the code. If they bounce (go low) timer 0 gets reset.

DbnceHi     MACRO    port,pin
local       start,wait,DEBOUNCE
variable    DEBOUNCE=.10*.1000/.256 ; debounce count = 10ms/(256us/tick)

    pagesel    $ ; select current page for gotos
    start      clrf TMR0 ; button down, so reset timer (counts "up" time)
    wait       btfss port,pin ; wait for switch to go high (=1)
    goto       start
    movf       TMR0,w ; has switch has been up continuously for
    xorlw      DEBOUNCE ; debounce time?
    btfss      STATUS,Z ; if not, keep checking that it is still up
    goto       wait

    ENDM

main_loop
; wait for button press

wait_dn   btfsc GPIO,3 ; wait until button low
goto      wait_dn

; toggle LED
movf      sGPIO,w
xorlw     b'000010' ; toggle shadow register
movwf     sGPIO
movwf     GPIO ; write to port

; wait for button release
DbnceHi     GPIO,3 ; wait until button high (debounced)

; repeat forever
goto     main_loop

END

Now onto my question up until now I've been debouncing both the button press and release. It's been brought to my attention in the tutorial I'm following that it's not normally necessary to debounce both the press and release of a switch.

I can understand why in theory because after the switch is read as low via the btfsc instruction (even if it's momentarily because the contacts are bouncing). The LED is toggled and the debounce high code will wait until the contacts have opened and stopped bouncing before executing the goto to loop the code from the beginning.

On the positive side this saves program memory. But if something seems too good to be true it usually is what are the potential pitfalls using this method?

Obviously for a simple application like this the code is overkill. But for something more critical like putting the PIC in sleep mode and waking up from a pin change any bounce must be eliminated in order for the micro to enter the leave sleep mode reliably.

What are your opinions on switch debouncing do you debounce the press and release or only one?

My guts telling me to go belt and suspenders and just debounce both to be safe but I have no logical reason for it.

Best Answer

Mechanical switches bounce on both transitions. The bouncing on opening is usually shorter than on closing, but can certainly happen.

I generally use 50 ms debounce time in both directions. A long time ago, I tested a bunch of pushbuttons. Most stop bouncing in 10-15 ms, but some took much longer, like 40 ms. I settled on 50 ms since that seemed to be long enough to be safe with just about any switch unless you deliberately try to keep it at the transition. I also did some testing on human delay perception, and concluded that 50 ms was about the limit you can get away with without the delay being noticed, unless perhaps someone is specifically looking for it.

Most microcontroller projects have a 1 ms periodic interrupt for other reasons anyway, so I usually add debouncing code to that. I keep a counter and a global flag for each switch. The flag indicates the current debounced state of the switch, which is what all the application code uses as the switch state. The counter is private to the interrupt routine. It is set to 50 whenever the actual switch state matches the debounced state, and decremented by 1 when they differ. When the counter reaches 0, the switch becomes officially debounced in the new state, and of course the counter is reset to 50 since now the switch and the debounced state agree.

I have used this basic approach in many microcontroller projects, and haven't had any trouble with bouncing buttons or users complaining (or even noticing) the 50 ms delay.

Related Solutions

Electronic – AVR Button Interfacing

Debouncing is something you must be familiar with when using buttons. When a contact closes, it does not just close, but bounces back a few times until it finally settles in its closed position.

Depending on how fast your sampling code is, the code can count many button presses, although you only moved your finger once. There are a number of debouncing strategies around. Search www.avrfreaks.net for debouncing and you will find plenty of posts. Most of the recent threads contain a link to some pretty good old examples/strategies which you can use.

This might not be the only problem with your code - but we can only know that when we've seen the code. Post it here or on avrfreaks and we might be able to help you.

Electronic – Decoding multiple quadrature rotary encoders

The key is how a quadrature encoding works: two signals are out of phase, so you can detect direction by which signal follows the other one. Combined, they have 4 states they pass through, but they will do so in opposite order for the opposite direction. I.e. 00-01-11-10- for right, 00-10-11-01- for left. As you see, they'll pass both the 01 and 10 states you're looking for - and the only way to know which way is by checking the next or previous state.

Given that you can guarantee only one encoder rotates at any time, the scaling of the quadrature decoder isn't really an issue. You can start by finding where the port changed and then decode only that transition.

Otherwise, we have the interesting challenge of finding a parallel algorithm for quadrature decoding applicable to microprocessors. A fundamentally parallel operation most of them have is bitwise operations on wider registers. Let's start by finding each channel where a change has happened, given the port arrangement a1b1a2b2 etc, i.e. every 2-bit group belongs to one channel.

If we do ((value&0xaa)>>1)^(value&0x55)) we get a parity value. This can then be xored with the previous parity value, and presto, we have a step signal. Next comes direction.

Let's set up a Karnaugh map, using inputs a, b, a' and b' (where ' means prior):

phase diagram ___/"""\___/"""  a
              _/"""\___/"""\_  b
             a=0     a=1
           b=0 b=1 b=1 b=0   1 means right, 0 means left, x don't care
a'=0 b'=0   x   1   x   0
a'=0 b'=1   0   x   1   x
a'=1 b'=1   x   0   x   1
a'=1 b'=0   1   x   0   x

We have a diagonal pattern, which tends to occur with xor functions. We also have a margin of values that should not be counted (meaning either no step or a missed step). We already found the step function to eliminate those. In essense, all we need is to find the diagonal with 0s in it, so we can invert step to get direction. It looks like the remaining discrimination can be done with b^a':

  b^a'       a=0     a=1
           b=0 b=1 b=1 b=0
a'=0 b'=0   0   1   1   0
a'=0 b'=1   0   1   1   0
a'=1 b'=1   1   0   0   1
a'=1 b'=0   1   0   0   1

So, given that we need a'^b' for step and a' for direction, we can save those two bits from the previous step. Our functions are step=a'^b'^a^b, dir=step&(b^a').

old_a_axb = ((oldpin&0xaa)>>1) ^ oldpin
# This has a serious bug, in that the ROL step actually used B from
# the next channel over. Let's fix it. 
#b_axb = ROL(pin)^(pin&0x55)
b_axb = ((pin&0xaa)>>1)^(pin&0x55)|((pin&0x55)<<1)
dir_step = old_a_axb ^ b_axb

# Rewrite since the selections get messy
old_al = oldpin&0xaa
old_ar = old_al>>1
old_br = oldpin&0x55
al = pin&0xaa
ar = al>>1
br = pin&0x55
bl = br<<1
axb_r = ar^br
axb_l = axb_r<<1
old_a_axb = oldpin ^ old_ar
b_axb = bl | axb_r = br*3^ar
dir_step = old_a_axb ^ b_axb
next_old_a_axb = axb_l^b_axb

It might be possible to optimize the a^b operation to occur only once, but given that I needed either a or b in the other bits I leave that to someone else. Also, this method doesn't discriminate between channels at all; use another mask and finding set bits to detect which channels actually stepped.

Addendum: The algorithm actually gets a lot cleaner if we do not pair the signals in adjacent bits, but use matching positions of separate variables:

# assume, for instance, a[3:0] in pin[7:4] and b[3:0] in pin[3:0]
a=pin>>4
b=pin&0x0f     # Separate signals into individual variables
axb=a^b
step=oldaxb^axb
dir=olda^b
olda=a
oldaxb=axb

So, for one register width count of quadrature decoders, it takes two stored variables, three xor operations, and one extra temporary register (which rarely matters).

Best Answer

Related Solutions

Electronic – AVR Button Interfacing

Electronic – Decoding multiple quadrature rotary encoders

Related Topic