developing switch bounce delay

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

developing switch bounce delay

7,815 Views
Bud
Contributor I
There seems to be 2 ways to handle switch debounce when you want to read into a port.  One is to develop a delay loop the second is to utilize a timer.  the delay loop is fairly easy.. how do I initialize a timer to be randomly called only when I want to debounce the switch? I am utilizing a 9sc08gt16 processor.
 
Thanks
Bud
Labels (1)
0 Kudos
Reply
12 Replies

2,256 Views
tonyp
Senior Contributor II

In addition to the other great responses you've received:

I often use dual (and occasionally triple) functions per key (I'll describe dual here.) This saves component count and cost in smaller cost-sensitive applications.

You can have the same key invoke different actions on short and long (or short, medium, and long) presses.  I normally use <2 sec for short, and >5 sec for long. 

The shorter presses can be acknowledged only on releasing the key because you can't know if the user intends to keep it pressed even longer for the next function.  This means you need to debounce both key-down and key-up to save you from the possibility of noise appearing as a (premature) release, using similar methods to those described in other replies.

The longest key can be acknowledged regardless of a release but I prefer to wait for a release anyway which also gives me an indication of possible stuck-key errors (indefinite presses), if it doesn't happen within some reasonable time.  So, in reality, there is always an extra quite long "hidden" key which is returned as KeyError.

0 Kudos
Reply

2,256 Views
FC
Contributor III
Is the simple software delay suitable for real world applications?
 
Since the debounce is specific for each type of switch, the bounce needs to be studied for the best debounce technique.
0 Kudos
Reply

2,256 Views
rocco
Senior Contributor II

Is the simple software delay suitable for real world applications?
I am told that the "real world" is where the walls are not padded. I do not know for sure, since they won't let me out to see it.

The routine I use works for any switch, regardless of how long it bounces. I sample at a fixed rate (driven by a timer interrupt), and only register a change when the switch has been the same for five milliseconds. This will work for a 2 millisecond switch or a 100 millisecond switch.

The code is here on the board somewhere.
0 Kudos
Reply

2,256 Views
peg
Senior Contributor IV

Yes it will work 100% with a 2ms switch and very reliable for a 5, 10 15. But as you approach 100 the reliability of proper detection falls away as the probability of sampling at 5 discrete times in a row when the switch is in the bounced state rises.

The "padding" in the timer method eliminates this.

This method also works as a noise/glitch filter as well, although if you have noise/glitches that can cause a state change on an input you probably should be looking elsewhere.

I am not saying it is bad concept, I use both basic methods myself, where appropriate.

Regards David

 

Message Edited by peg on 2006-07-02 12:21 PM

0 Kudos
Reply

2,256 Views
rocco
Senior Contributor II
Actually, David, I have never really seen a switch bounce for 100 milliseconds, so I can't really say that it would work at that extreme. But it does work reliably for the worst switch I ever had, which varied between 25 and 35 milliseconds (an old military-style toggle).

My experience is that, when a switch bounces, it keeps bouncing for the entire debounce period. They don't seem to stop to rest.

I like to sample at a 200 microsecond rate, which means you would need 25 samples, all at the same level, before you decided that the switch has stopped bouncing.
0 Kudos
Reply

2,256 Views
peg
Senior Contributor IV

Fair enough!

Somehow I got it in to my head that you were sampling at 1ms rate which led me to comment as I did. 25 consecutive samples of an uncontrolled frequency source would be impossible enough.

 

0 Kudos
Reply

2,256 Views
irob
Contributor V
To date, I've just been using software timers and large state machines to give me various styles of switch detection. E.g., long and short times for multiple functions, action taken while switch is still depressed, action taken after up debounce, etc.
0 Kudos
Reply

2,256 Views
peg
Senior Contributor IV


FC wrote:
Is the simple software delay suitable for real world applications?
 
Since the debounce is specific for each type of switch, the bounce needs to be studied for the best debounce technique.



Yes, normally it is. The debounce time is usually inversly proportional to the cost of the switch. Good quality keypad switches can be safely debounced in 10-15ms.

What else did you have in mind for the "real world applications" where you think it wouldn't work?

If you can't debounce it in 100ms you should probably looking at a different switch rather than more complex code as the "bounce" time will probably only get worse with time.

Regards David

 

0 Kudos
Reply

2,256 Views
peg
Senior Contributor IV

Hi Bud,

Now that you have quantified the ways, others will suggest more! :smileywink:

If you have a spare timer, you can scale it and set the modulo to get your delay.

Then when you see the switch operate :

Read TPMxSC to help next step

Clear TOF inTPMxSC

Write to TPMxCNTH to reset counter

Now you can wait for TOF to become set or get it to generate an interrupt

Don't clear TOF as you normally would when you service this.

Then perform the intended switch response. (if you did not do it when you first detected closure)

This method saves having to do the 16-bit adds.

Regards David

 

Message Edited by peg on 2006-06-30 03:11 PM

0 Kudos
Reply

2,256 Views
peg
Senior Contributor IV

See, there you go, even before I finished typing method 3 arrives!

Some comments on this method though:

1. switch needs to remain down at the end of debounce. (not always an issue)

2. if a second switch changes state within the firsts debounce the debounce can be extended to double length (now it has to be down for 2 x debounce time)

3. You don't get to react to the closure until after the debounce time (or 2?).

If it is a keypad or array of finger operated buttons this is not a problem, but if they are machine switches etc this could cause havoc.

You will notice I avoided scrutiny by only answering the exact question about implementing the timer.

This is one of those subjects that a first seem innocuous but can be quite complicated and dependant on many other things.

Regards David

 

Message Edited by peg on 2006-06-30 03:13 PM

0 Kudos
Reply

2,256 Views
glork
Contributor I


Bud wrote:
There seems to be 2 ways to handle switch debounce when you want to read into a port. One is to develop a delay loop the second is to utilize a timer. the delay loop is fairly easy.. how do I initialize a timer to be randomly called only when I want to debounce the switch? I am utilizing a 9sc08gt16 processor.


Thanks

Bud





Hello Bud.
This is a problem that I have to solve for just about every application I do. I have a standardized way of doing it, but it only works if you have a periodic interrupt going on (say a 'real-time' interrupt every milisecond). It works like this:
1. Assume we have 8 switch inputs on port A
2. Assume we want a de-bounce time of 50 miliseconds
3. Assume we've assigned variables temp_switch and valid_switch and bounce_time
4. Assume the processor init routine will clear temp_switch and valid_switch and place $32 in bounce_time.
Now the process:
A) every time the periodic interrupt executes it reads port A and compares it with the contents of temp_switch.
If not the same copy port A to temp_switch and init bounce_time to $32 and leave
Else if bounce_time is non zero decrement it and leave
Else if bounce_time is zero copy temp_switch to valid_switch and leave

This technique debounces any change of state for the 8 port A inputs and has the advantage that your main program can treat the contents of valid_switch as 'gospel' switch info.
ron
0 Kudos
Reply

2,256 Views
bigmac
Specialist III

Hello Bud,

To generate non-critical time delays, such as for switch debounce, LED flashing, etc, there are a couple of simple methods using the timer.  The first uses a periodic interrupt such as RTI or timer overflow.  The second method requires simply to read the timer count register, and does not specifically require any interrupts to be enabled.

Method 1

The periodic interrupt should occur multiple times within the timeout period - the actual timeout period will have an uncertainty of one interrupt period (i.e. +/- one half period).  Allocate one or more global variables (of byte or word size), one variable for each simultaneous timeout that may need to occur, say timeout1, timeout2. 

Within the timer ISR place the following code for each variable, to decrement the variable unless already zero.
   if (timeout1)  timeout1 -= 1;
   if (timeout2)  timeout2 -= 1;
etc.

Then within the main program, where you need the timeout delay period, the following code should work.
   for (timeout1 = DEBOUNCE; timeout1; );

or alternatively
   timeout1 = DEBOUNCE;
   while (timeout1);

Method 2

If the timer overflow method should have insufficient resolution because the overflow period is too long (and you do not wish to alter timer settings for other reasons), simply chose a bit within the timer count register (TCR) that toggles at a suitable rate, and use this as the basis for decrementing a timeout variable.  The following example uses bit 9 for the timing.

   #define MASK 0x0100

   for (timeout1 = DEBOUNCE; timeout; ) {
      while (TCR & MASK == 0);
      while (TCR & MASK);
      timeout1--;
   }

I hope this provides some ideas.

Regards Mac

 

Message Edited by bigmac on 2006-06-30 04:59 PM

0 Kudos
Reply