I am looking for a hardware circuit that can debounce push buttons.
I heard there are some nand gate/flip-flop ICs or non inverting buffers(?) for that
Can I just plug in a designated IC for that?
I have too many buttons to control - 15-25 or more
Maybe someone can help and throw some bones here )
Thanks!
RC filter followed by 74HC14 schmitt-trigger inverter is the commonest one. The RC filter is low pass to lose
the bounces, the schmitt-trigger input gate will then produce clean fast logic edges from the result.
However since debouncing can be done in software (even for 25 buttons), why use hardware?
Debouncing is absolutely not easy when complex tasking. You have to stop all interrupts - most likely use critical sections and measure time very precisely. It is just ugly. It works excellent for very simple projects though.
Besides - buttons introduce a lot lot of noise to the mcu.
Can you post some links to simple schematics or best concepts?
I worked on calculator design for a while long ago, and we did debounce in software. It was as I recall the most flexible, inexpensive and reliable solution.
Since you have a lot of switches, and if you're worried about real-time issues in your application, maybe you should consider dedicating an inexpensive MCU to just managing and debouncing your keypads? Key press events as you know have a low, human-driven data rate, so you have lots of time to low-pass filter them in code. The question is whether you have that time to spare in your application's primary MCU.
In the end, I think all we can do is get the probability of a misread button down to an acceptably low level that we can live with as our system gets older and our switched get bouncier. (And do what we can to be tolerant of misreads when the do happen.)
A bouncing contact is not always a problem.
Why do you think you need debounce.
Leo..
LTC also makes a really really spiffy single switch debouncing IC as part of it's timerblox series - but the price is eye-watering.
You can also do "okay" with a small capacitor...
That said, it would take exceptional circumstances to make me use hardware debouncing - software debounce is almost always practical, and has no added hardware cost.
Are you going to use an MCU with one input pin per button or a port expander or attempting to scan the buttons in a matrix?
Deous:
Can I just plug in a designated IC for that?
Absolutely.
It is called a microcontroller. An ATmega328 would be an excellent example.
Deous:
I have too many buttons to control - 15-25 or more
That makes a microcontroller even more important.
Deous:
De-bouncing is absolutely not easy when complex tasking. You have to stop all interrupts - most likely use critical sections and measure time very precisely. It is just ugly. It works excellent for very simple projects though.
Total nonsense! 
De-bouncing pushbuttons has nothing whatsoever to do with interrupts. Well, actually, it does use interrupts in a sense, as the millis() function which you use, does internally use an interrupt, but you will (should) already be using millis() so this hardly counts.
The trick for multiple pushbuttons is that you de-bounce all buttons simultaneously, putting them into bytes or words to perform the individual operations. If it is convenient to align them to byte-wide ports, it would be extremely fast. On the other hand, you can matrix buttons (preferably with one diode per button) and also use a 74HC4017 to scan them from two "strobe" pins.
Deous:
Besides - buttons introduce a lot lot of noise to the mcu.
That sounds like an absurd claim, but I think I understand what you are thinking.
Only if you are foolish enough to connect them to interrupts.
I still haven't seen a valid reason why debounce is needed.
If a button turns on a light, then it doen't matter if you turn that light on once or 100 times.
It will still result in the light being on.
Leo..
Wawa:
I still haven't seen a valid reason why debounce is needed.
That would be due to - dare I say it again - the XY problem! 
Wawa:
I still haven't seen a valid reason why debounce is needed.
If a button turns on a light, then it doen't matter if you turn that light on once or 100 times.
It will still result in the light being on.
Leo..
Not necessarily.
If the button press turns on a light and the next press of the same button turns off the light (toggle fashion) then some debouncing might be desirable. But I am curious to know what he is doing with so many buttons and how intends to connect them all up.
Paul__B:
...Total nonsense!
De-bouncing pushbuttons has nothing whatsoever to do with interrupts. Well, actually, it does use interrupts in a sense, as the millis() function which you use, does internally use an interrupt, but you will (should) already be using millis() so this hardly counts.
The trick for multiple pushbuttons is that you de-bounce all buttons simultaneously, putting them into bytes or words to perform the individual operations. If it is convenient to align them to byte-wide ports, it would be extremely fast. On the other hand, you can matrix buttons (preferably with one diode per button) and also use a 74HC4017 to scan them from two "strobe" pins.
That sounds like an absurd claim, but I think I understand what you are thinking.Only if you are foolish enough to connect them to interrupts.
E..xcuse me? What a character.
Anyways. I have groups of buttons - each group behaves different and within group there could be subgroups of buttons having different push patterns f.ex. dn is on up is off, dn-up,dn-up/on-off, short pushes switches engine off etc.
They are to control property lights, sprinkle systems, fountains, roof extenders etc. It is old control panel design already in place.
A bit of headache but people got used to using it.
OK. Maybe look at using MCP23017 port expanders for all your buttons/switches. These are quite versatile each allowing up to 16 buttons or devices and with only 2 wires (plus power) you can connect up to 8 to the MCU via the I2C bus.
You can configure them to trigger a notification when a button changes state. You can implement debouncing by ignoring such notifications that occur within X mS of a previous (acted on) notification.
Another alternative is to use say an Arduino Mega if it has enough pins for a direct connection of all your buttons etc.
You have to stop all interrupts
I agree that this is a noncense, of course you don’t have to stop interrupts to do a debounce, you simply have to ignore the reading from a button for a time after it has been pressed.
Generating an interrupt from a push button IS stupid.
You came here to learn not to insist on your misguided ideas.
Grumpy_Mike:
I agree that this is a noncense, of course you don’t have to stop interrupts to do a debounce, you simply have to ignore the reading from a button for a time after it has been pressed.Generating an interrupt from a push button IS stupid.
You came here to learn not to insist on your misguided ideas.
Perhaps the really stupid thing is making sweeping generalizations with no foundation?
Of course you may want to fire an interrupt on a button press. That's what most "panic switches" do for heaven's sake. 1) A button press event fires an interrupt. 2) The ISR responds by disabling the interrupt and 3) initiating the required event handling. 4) Usually, some sort of recovery procedure is executed (alarms are turned off, etc.) Then 4): eventually, if all is well and after enough time has passed that the probability of bounce is reduced to an acceptably low level, the interrupt may be re-enabled.
I suspect that you've not had much experience with mission-critical RTOS and issues in real-time embedded applications. Could that be the source of some of your misguided ideas?
I suspect that you've not had much experience with mission-critical RTOS and issues in real-time embedded applications.
That is where you are wrong yet again. Only been doing embedded stuff for 40 years.
Do you really think the OP has 20 real-time panic buttons? If you do then it is you who knows nothing.
Look, this is a beginners forum, we are trying to teach people not trying to score points or totally confuse beginners. What teaching expert are you got? Absolutely none from the time and contents of your “contributions”.
Beginners often think buttons need debouncing and that debouncing involves interrupts, this is seldom the case. The challenge with this forum is that we have to educate and guide people into the best way of doing things.
If you want a points scoring pedantic forum try elsewhere.
"Generating an interrupt from a push button IS stupid"
No, it isn't, and I believe you know that now that I've given you a detailed example of when it is indeed NOT stupid.
I suspect that what really has you upset is having some of your own language fed back to you.
"What teaching expert are you got?"
Enough to know that people that are asking questions deserve a little respect and consideration, regardless of whether they're beginners or old geezers like us.
"...we have to educate and guide people to the best way of doing things."
Somehow, being self-important and frankly a little insulting at times doesn't seem like the best pedagogical approach to me. You might have been more helpful if rather than passing judgment from on high, you had asked a few questions about all of those buttons first. Just a thought.
(By the way: a three axis milling machine may use six limit switches, two on each of the X/Y/Z axes. Those six limit switches may all be combined to drive a single common "range interrupt." Just an example. The ISR handles which of the six switches has been activated. No need for every switch to have its own unique interrupt. But of course you KNEW that... )
Enough please -
the OP ask for a hardware debounce solution, only one person stepped up with a chip that would do hardware debounce - it seems the 16DIP version is a bit of an orphan but still being made and available
Many people have bashed the OP with out knowing anything about why they ask for hardware debunce, why not ask why? Maybe the OP has tried software debounce and finds it adversely effects the program, maybe the OP has a software Debounce routine that is not very good, why not offer the OP a routine that you have found works well??
I ask a friend that works with small processors and knows way more than I, is response was that hardware debounce is not used much now, BUT recently they had a project and his intern (very sharp person he said) has problems with software debounce and they had to go to a way faster processor to get the software debounce to work
Bashing and being rude to someone that ask for help does nobody any good.
CurtCarpenter
Retired electrical engineer trying to keep my hand in
But failing.
My mom said don’t feed the troll, goodbye.