Debouncing multiple buttons using schmitt trigger

I was hoping that someone on these forums could double check my schematic to ensure this will work properly on my PCB.

I'm trying to debounce/deglitch three buttons using a schmitt trigger and rc circuit. I'm using a 74HC14. My question is, can I use R5(10k resistor) for all three buttons as a pull up resistor or does each button need to have its own? The image is rather small but that resistor is running to the 5v supply. I normally had the buttons attached to the trinket and used its built in pullup resistors but since I have to run through the 74HC14 on this design I can't use that feature. I just want to be sure that using this design will give me the desired result before I order the pcb's and wait several weeks for them to get here only to find I've made a mistake somewhere.

My other question is whether this rc circuit will have enough filtering to debounce the button or should I change the resistor or cap values to adjust the time? Thanks for your time!

|500x315

Do I need to say more?
button pullup wrong.png

Kuusou:
but since I have to run through the 74HC14 on this design I can't use that feature.

Why? Who's giving you that awkward requirement?

button pullup wrong.png

I’m just trying to follow this schematic

I’m not sure what the highlighted red line means exactly, sorry i’m rather new to all this so i’m sorry if that’s a stupid question.

No one is giving me that req, just that my understanding is that it needs to run through a schmitt trigger to properly debounce it and i’m not sure how i would use the pullup resistors on the trinket with this set up.

Kuusou: I'm just trying to follow this schematic

Why? Just connect it to the Arduino :)

Kuusou: I'm not sure what the highlighted red line means exactly, sorry i'm rather new to all this so i'm sorry if that's a stupid question

It shows a connection which is made when the "bright" button is pressed. Do you want that connection ;)

septillion: Why? Just connect it to the Arduino :)

Well before the buttons were attached to the trinket but I need to properly debounce/deglitch them using hardware. I'm aware of button debouncing in software but that's not an option for me. The buttons trigger interrupts within my software and as a result I'm not able to properly debounce them so i'm trying to use a hardware solution instead.

septillion: It shows a connection which is made when the "bright" button is pressed. Do you want that connection ;)

I see what you're saying, so in this case I'd need each button to have its own resistor to avoid that.

So this should resolve that issue correct?

Is it possible to connect the buttons to the arduino and use the internal resistors and still get the debounce effect from the schmitt trigger???

|500x314

Kuusou:
The buttons trigger interrupts within my software

Now there is your problem :wink: We humans push the buttons. We humans are dead slow. Interrupts are for fast things. Aka, an interrupt is ALWAYS* the wrong choice for a button :wink:

Kuusou:
I see what you’re saying, so in this case I’d need each button to have its own resistor to avoid that.

Correct, classic newbie brain fart :wink: Don’t blame you, made them in the past as well.

But it also shows to me you don’t have a real clue why you do this. So my suggestion, drop the interrupt, just poll and debounce in software, saves you the hardware and easier to change :slight_smile:

PS Also, don’t be evil and draw GND down. Only evil people drop it upwards :wink:

  • With the exception if it needs to wake the uC from sleep.

septillion:
Now there is your problem :wink: We humans push the buttons. We humans are dead slow. Interrupts are for fast things. Aka, an interrupt is ALWAYS* the wrong choice for a button :wink:
Correct, classic newbie brain fart :wink: Don’t blame you, made them in the past as well.

But it also shows to me you don’t have a real clue why you do this. So my suggestion, drop the interrupt, just poll and debounce in software, saves you the hardware and easier to change :slight_smile:

PS Also, don’t be evil and draw GND down. Only evil people drop it upwards :wink:

  • With the exception if it needs to wake the uC from sleep.

I’m aware this probably looks like the XY problem.

I’m aware of the fact that its bad practice to use interrupts with buttons and have read a lot about it at this point. However my particular case (i need you to trust me on this) I need to have the interrupts attached to the buttons. A hardware solution is the only one I have. My program has some 13 different looping functions that I need to be able to switch between whenever a button is pressed. I was unable to find a better solution than to use interrupts and no one on this forum was able to help point me in another direction, other than to refer me to blink without delay, which didn’t help me in my case or at least make me understand a better way to do it. At this point my program is already written and a hardware solution is the much easier option.

In this case, is my schematic as laid out as well as It can be?

Hahaha I wasn’t aware evil people did that! I’ll have to avoid that in the future

Kuusou: (i need you to trust me on this)

Sorry, I just can't ;) To me it points to a design flaw elsewhere ;)

One thing I'm missing, the 100nF for the chip itself! ;) Every chip wants a decoupling cap close by. Besides that and the evilness it should work.

septillion: One thing I'm missing, the 100nF for the chip itself! ;) Every chip wants a decoupling cap close by. Besides that and the evilness it should work.

I'm not sure I following you on this. What do you mean? Is the 100nF too weak? Wrong type of cap?

Noting to do with the current caps, but something that applies for [u]all[/u] chips, they want a 100nF ceramic cap over the power rail close by (aka, right next to the IC) so they have a clean power supply :)

septillion:
Noting to do with the current caps, but something that applies for all chips, they want a 100nF ceramic cap over the power rail close by (aka, right next to the IC) so they have a clean power supply :slight_smile:

So something like this?

attached like C4?

Yeah, it's close on the schematic but he means physically close to the IC, as close as possible.

raschemmel: Yeah, it's close on the schematic but he means physically close to the IC, as close as possible.

I've been reading up on that, looks like my schematic above is slightly wrong though because the cap should go to ground.

Correct.
I didn’t notice that it was connected to Vcc.

|500x398

runaway_pancake: |500x398

I'm not sure what I'm looking at here, is this the same concept but cutting out the extra resistors and doing a 20k instead of 2 seperate 10k's?

What you're looking at is a circuit that I've actually used. Each Schmitt output goes to an input pin, but they also get diode OR'd before the INTerrupt pin. Any button-push results an interrupt where the sketch then determines which switch it was. I used this to control a motor [increase/decrease PWM or Stop]. (I added a fail-safe in the sketch where two or more would stop the motor.)

I'm not sure I know how to recreate that. This is the final schematic that I have at this moment. I've got my PCB designed as well. Are there any changes I could make to this design to make it more efficient or component/space saving?

|500x302

Thank you all for your time and help btw!

Even if you must use interrupts to handle button presses, maybe because you use delay() statements in your sketch and you need to “jump” over these, you can still use simple software debouncing. In the interrupt service routine, on a valid call, simply set a timer, say: static uint32_t isrLastCalledAtMs = millis() ;

However, if too little time has elapsed since the last valid call and the current call ( say less than 100mS ) then ignore the call because it is a bounce.