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!
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.
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.
Kuusou:
The buttons trigger interrupts within my software
Now there is your problem 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
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 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
PS Also, don't be evil and draw GND down. Only evil people drop it upwards
With the exception if it needs to wake the uC from sleep.
septillion:
Now there is your problem 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
Correct, classic newbie brain fart 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
PS Also, don't be evil and draw GND down. Only evil people drop it upwards
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
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 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
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
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?
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.
