Can you describe the "bad result" you're getting, please? Could there be a problem be with your switch state logic, like detecting a single "new press" state, rather than actual switch bounce?

When button is pressed, the uC register multiple highs.

That sounds like the lack of switch state management. Some less sophisticated methods let you act on a debounced press and then force you to wait for a debounced release before continuing program execution (lol).

 

That sounds like the lack of switch state management. Some less sophisticated methods let you act on a debounced press and then force you to wait for a debounced release before continuing program execution (lol).

Yes, and now I have a lot of info to process.

 

I prefer to sample at intervals of less than 50 ms. 10 ms for example. You have more opportunities to implemet a smart algorithm.

Ganssle's article is excellent, but he has some examples of switches and presses that bounce for an incredibly long time or give a very unclear indication to your software; I don't think you need to cater for every possibility. A switch that does that should be regarded as faulty, and replaced. If it's a common problem with a particular type of switch, I would change to a better part.

If you want to avoid the long initial delay in responding to the button being pressed, because it causes an impression of lagging response to the user, you can use a different algorithm to detect the press. You can accept the first active indication as a press, then apply the debouncing using consecutive samples. Or you can accept the first two consecutive active samples as a press; if you sample at 10 ms intervals, the maximum delay will be 20 ms. Once you have accepted the press, the debouncing timing can be a lot slower and more fussy.

 

People let switch debouncing be a bugaboo, and it's trivial. Use the right procedure, and you don't even have to think about it.

The switch needs a pullup which can be internal to the processor, or an added part. I suppose you could invert this, and connect the switch to Vcc with a pulldown resistor, but it doesn't affect the logic.

Then all the processor needs to do is read the switch at an interval that's known to be longer than the maximum contact bounce time. 50msec, or 20 times/sec would be long enough for just about any switch. It doesn't matter whether the switch gets read before or after or during its period of uncertainty, the processor will never see anything but a single transition. It really is that simple.

Generally true, but I have found it is often nice to be able to read the switches as a part of the overall loop logic and not keep a separate timer or interrupt (assuming you even have them) going.

Plus, there are times when you either want to have fast responsiveness or fine timing of events. In that case, what you can do is adopt the following assumption: If a switch input is detected in the opposite state, it will be assumed that the switch has actually been moved to the other state and we will act on it as soon as it is detected. But, since it may bounce for some amount of time, we will desensitize the circuit/logic to any further changes in state for some specificied period of time (a disarmed dwell state).

 

http://pic.hitechworld.org/pic-microcontroler-how-to/how-to-query-keys-via-port-io/

I wrote the explanation some time ago, and I did not spend much time on it too. It is based on PIC RISC assembler.

Maybe I should write more, including information about C language too.

 

Care to share?

Found the time to reply.

I posted about debouncing recently, here

 

Found the time to reply.

I posted about debouncing recently, here

Thank you for the effort. Appreciated.

 

Years ago, when I used PICKIT2, WIN98 + some 16f54 chips, I followed a similar approach.

At first, I really used such debounce counters.

After a while, I figured out, only 3 discrete states are neccessary.
Anything else is additional complexity.

The way I implemented it from the beginning on is really resembling a low-pass.

The start transition is initiated by a button press.
Then the stop condition can no sooner be issued than the low-pass allows.
Once you have a "2" stored, the key was pressed.

You need to reset it again to zero. Pretty much it.

At first, I used higher counts, but all unneccessary.

 

People let switch debouncing be a bugaboo, and it's trivial. Use the right procedure, and you don't even have to think about it.

That about sums it up. There is no right way nor wrong way.

There are simple ways and complex ways. There are ways that are a good fit into your overall code and those that make a poor fit.