Michael, Switch debounce is quite ON topic. For the PIC or any other digital processor. The bounce parameters vary from switch to switch. Dry switches are the worst. Mercury wetted switches are virtually bounceless. Some switches use a spring mechanism to move the contacts. These have a narrower bounce. The worst offenders are the really cheap pushbuttons that rely only on finger pressure. These things bounce all over the place if you only apply a very light pressure. You get what you pay for :) Typical debouncing periods range from 1 ms to 5 ms. To debounce a switch you can use physical means or software means. PHYSICAL MEANS Assume a SPST normally open pushbutton with one side tied to ground. Tie a pullup resistor to the other side and place a small capacitor in parallel with the switch. This gives the switch the following characteristics: it will switch to ground immediately upon closure. The current from the capacitor will help keep the contacts operational so long as the current is not excessive. When the switch physically bounces, the capacitor will start to charge up. This will take time. If the time to charge to 1/2 the supply voltage is longer than the bounce period, then the switch will be effectively debounced. The pullup resistor value and the capacitor value determine the debounce period that can be compensated for. A Schmitt trigger input is useful when such capacitor and resistor hardware debounce is used, but it is not absolutely necessary. Do not make this debounce period TOO long, or you will over-compensate, and then two rapid switch closures will be seen as only a single closure. In practical terms, you can simply adjust the charge time to be about 1/2 the absolute minimum time you would ever expect between VALID switch closures. Physical debouncing has the advantage of eliminating much of the software overhead. Just look for the make and the break. Physical debouncing DOES cost you a resistor and a capacitor, but we are talking pennies here. SOFTWARE-ONLY MEANS This is for the hardware minimalists who believe that absolutely everything should be done in software. It is "free" only if you don't need the processor resources for anything else. Use hardware AND software for the ultimate in de-bouncing. Best method is to begin with the closure, and in a count loop accumulate how many of the loop cycles result in a reading of CLOSED. For example, let's say that you loop 120 times and only get a CLOSED indication 10 times. You probably just had noise. 64 counts or more you would consider a closure. Wait for switch to open, delay for 1 ms and process exit. <> BTW, you can test for >64 counts by testing a single bit... the one that represents 64. Always try to keep things simple. Next best method. Let's assume a 1 ms max bounce period. Upon initial closure, time out for 1.5 ms. If the switch is open, it was just noise, so ignore it and exit. If it was still closed, then wait until the switch opens, delay 1.5 ms and process the closure. Hope this helps. Fr. Tom McGahee ---------- > From: Michael Park > To: PICLIST@MITVMA.MIT.EDU > Subject: [OT] Switch bounce characteristics > Date: Thursday, June 11, 1998 2:30 AM > > As I prepare to try my hand at debouncing a switch input, I'm curious to > know if anyone has characterized mechanical bounce in terms of typical > frequencies and durations. If that information is not directly > available, my question then becomes one of pragmatics: What sampling > frequency have you successfully used, and how many samples did you need > before declaring a switch settled? > Scott Dattalo, on his amazing debounce technique[1], talks about the > "vague terms" surrounding debouncing in general. I'd like to get a feel > for the numbers that real-world practitioners use. > > Reference: > [1] > http://www.interstice.com/~sdattalo/technical/software/pic/debounce.html > > -- > Michael Park > www.seattlerocketworks.com