debouncing switches with a timer interrupt?

[aratti]

if i remove the pauses, there's no debounce, and one push of a button cycles through alot of menus.

I would apply a flag condition to control the key state.

False        CON  0
True         CON  1
KEYPRESS  VAR portXx
KeyFlag      VAR BIT
Counter      VAR WORD

LOOP:

PAUSE 1

IF KEYPRESS = False then

IF KeyFlag = False Then
Counter = Counter + 1
KeyFlag = True
ENDIF

ELSE
KeyFlag = False
ENDIF
.
.
.
.
.
GOTO LOOP

In the above snippet every time you press the key "KEYPRESS" the word variable "Counter" will increment of one unit, no matter how long you keep the key down. If you remove the flag control using pauses, it will be rather complicate to reach the same results.



Al.

[Kamikaze47]

I would apply a flag condition to control the key state.

This would still require some kind of debouncing. The logic state can "bounce" a number of times when pressing a button, so if it toggles back and forth a few times it could still advance the counter more than once for a single key press if the loop is quick enough.

[aratti]

This would still require some kind of debouncing. The logic state can "bounce" a number of times when pressing a button

Contact's debouncing should be solved with proper RC filter! If proper filtering is not possible an additional IF/THEN statement should reduce greatly the debouncing effect.

False        CON  0
True         CON  1
KEYPRESS  VAR portXx
KeyFlag      VAR BIT
Counter      VAR WORD

LOOP:

PAUSE 1

IF KEYPRESS = False then

IF KeyFlag = False Then
Counter = Counter + 1
KeyFlag = True
ENDIF

ELSE
KeyFlag = False
IF  KEYPRESS = False THEN  KeyFlag = True    ' re-checks the key logic state
ENDIF
.
.
.
.
.
GOTO LOOP

Al.

[DDDvvv]

thanks guys.

i tried the capacitor method, and that did not work well. still skipping menu items.

im using proteus simulation, and i tried every value of cap, 1000uf to 0.000001 uf., and everything in between.

ill try integrate the software flag idea into the problem, and hope that it fixes it. thanks

[DDDvvv]

hi all
i tried to implement the flag idea, but still the same result. menu item cycles through 3 to 6 items with one push of a button. here's the code snippet

RB_MainMenuLoop:
' BTN_PLUS is the Next Choice button
    PAUSE 1
      IF BTN_PLUS=0 THEN
      ;PAUSE 200
      IF FLAG_PLUS = 0 THEN
      bMenuPos=bMenuPos+1
      FLAG_PLUS = 1
      ELSE 
      FLAG_PLUS = 0
      IF BTN_PLUS = 0 THEN FLAG_PLUS = 1
      ;ENDIF
      IF bMenuPos>22 THEN
         bMenuPos=1
      ENDIF
      ENDIF
      Goto DisplayMainMenuLoop:
   ENDIF

im beginning to think that debouncing is not the problem. is there any other way to skin this cat?

[aratti]

Counter Var Byte

RB_MainMenuLoop:
' BTN_PLUS is the Next Choice button

PAUSE 1

IF BTN_PLUS=0 THEN

IF FLAG_PLUS = 0 THEN
bMenuPos = bMenuPos + 1
FLAG_PLUS = 1
Counter = 0
ENDIF

ELSE
Pause = 10
Counter = Counter + 1
IF Counter > 50 THEN FLAG_PLUS = 0 : Counter = 0
ENDIF

IF bMenuPos>22 THEN
bMenuPos=1
ENDIF

Goto DisplayMainMenuLoop:

================================================== ===============

Try this snippet and see how it works. You can tune the PAUSE 10 and Counter > 5, to better values to suite your need.

Al.

[Acetronics2]

hi all
i tried to implement the flag idea, but still the same result.

Hi,

You should understand debouncing NEED time, where ever this time comes from ( capacitor, timer ...)

the idea of debouncing is :

" Does the electrical state of pin still changes afer X milliseconds ??? "

so, you can't get a correct answer before X milliseconds !!! - Obvious -

But 200 ms is debouncing time for really poor quality switches, 20 ms can be obtained easily.

note also switches " bounce " when closing its contact ... not when opening it !!!

so, ... is it here THE good idea ???

Further, May I tell you a real time timer might not be disturbed by a keypress ... - or your program is " not so good " ...

the delay needed by the RTC to be updated is so far smaller than a key press action ...

Alain

[Mike, K8LH]

Consider using a switch state latch and relatively simple logic to sample your switches and detect the "new press" state while ignoring the other switch states. Here are the switch states;

swnew swold  switch state
  1     0    a "new press"
  1     1    still pressed
  0     1    a "new release"
  0     0    still released

Sample the switches at a decent debounce interval (16 to 25 msecs) either in your main program loop or in a timer based interrupt service routine. You only need a few lines of code to implement the switch state logic for multiple switches (perhaps one of the PBP gurus can interpret the C code? Sorry!);

//  swnew  ____---____-----_____   new switch sample
//  swold  _____---____-----____   switch state latch
//  delta  ____-__-___-____-____   changes, press or release
//  newhi  ____-______-_________   filter out release bits
//

while(1)                  //
{                         //
  delay_ms(24)            // 24-msec debounce interval
  swnew = ~porta;         // sample active-lo switches
  swnew &= 0x0F;          // on RA3..RA0 pins
  swnew ^= swold;         // changes, press or release
  swold ^= swnew;         // update switch state latch
  swnew &= swold;         // filter out "new release" bits
  if(swnew)               // if any "new press" bits
  { beep();               // task a "new press" beep
  }
  
  if(swnew.0)             // if RB0 "new press"
  {                       //
  }                       //

  if(swnew.1)             // if RB1 "new press"
  {                       //
  }                       //
}

If you implement the method in an ISR you'll need to inclusive-or "swnew" with a "flags" register for your main program.

Kind regards, Mike