I have two push buttons on a machine I’m building. Unfortunately I don’t have the buttons with me right now, but I suspect them to be very bouncy. There’s no click moment, when increasing the press force, just a smooth motion against a soft spring until there’s a contact. Feels nice, but probably not meant for digital things.
Anyway, I started to write a button debouncing function based on a timer and an interrupt. And I tried to test it with any button I could find. Appears the button doesn’t bounce at all. This is what I get from my oscilloscope:
The oscilloscope is a cheap Fnirsi DSO-TC4, but I guess it shows a true situation. This is the finest resolution I could get. The falling edge is when I press the button. I can’t simply get any bouncing on the screen. The button must be a good one:
Switches that make a sliding contact do not bounce. Seems you have already opened one and should see the contact are not the type that press against one another. What did you see?
If the scope is right, you are indeed lucky.
BTW, no need to re-invent the button library, there are lots of them and they have already fixed all the things you would miss.
The first question you should be asking yourself is: is it actually a problem if they bounce?
What is the function of these 2 buttons? Because for some uses, bouncing has no significant negative effect. If that's true, you should apply the KISS principle and not debounce them.
Also, it's rarely wise to expect the product to always work exactly the same. You may get an entire shipment of these buttons with zero bounce, but the next load not so much. Those buttons can be had for 2 cents or less each, in quantity, so I don't expect there's a lot of QC involved.
But, as @PaulRB points out, assess the application before deciding if you care if it bounces, before going too far down that rabbit hole.
I am the founder of Wheel Re-Inventer’s Society. I’m the only member, because everyone has to found their own society.
I might write my own debounce functions, mostly because I want to learn to read pins at lowest level and I want to learn how to use timers and interrupts. And it’s fun. Anyway, I might eventually not need the debouncing. I guess my button functions will be of the kind where it is perfectly fine to simply wait one second after each key press. But just in case I want to distinguish between short press and long press, I would really need bounceless buttons.
Would you, though? You still haven't explained why they need to be debounced.
If you just want to debounce them because of ADHD or similar, please let us know. Also start having a think about how vulnerable your circuit might be to nearby lightning strikes.
Isn’t it obvious if I need a long press? If I press long, but the button bounces, it will be read as several short presses. Say short press means jump to next track to play and long press means jump to previous track.
Yes, then it is obvious. My point is you have said nothing about the use of these buttons until now. They could have been "stop" and "go" or "forward" and "reverse", or... Remember, we can't see into your head!
I mentioned the long press in #6. But I haven't planned the final functionality yet. What I’m working on is a busker organ with real pipes and a manually cranked bellows, but electronics controlling the player mechanics. The user interface consists of an on/off-switch, two push buttons and a vintage voltage meter. And the crank handle. I did the design with no specific functionality in mind, except for the voltage gauge, which will work as a bellows pressure gauge. I just thought this setup could give me enough options for further development of the actual functionality.
I want to play tunes from an SD card (tested and it’s working), I want to play tunes from a web site, controlling everything from my phone (just need to be adapted from an earlier instrument of mine). The two push buttons are of this type:
I really like the feel of the soft and smooth pressing motion, but as I mentioned, that will most probably cause some bouncing. So, I just want to be prepared with some software based debouncing, which won’t be a problem. My cheap oscilloscope probably is just fine, I just seem to have picked a too good switch for testing. It might have sliding contacts, but it definitely has the distinctive click, like pressing a convex metal membrane.
if the MCU has an internal pull-up enabled, you can often get away with just adding a capacitor between the input pin and ground. The internal pull-up acts as the resistor in the RC circuit. The capacitor value needs to be chosen to filter the bounce without making the response too slow.
Why? There are a lot of button libs that can distinguish between short and long press - even with bouncing buttons.
Debouncing a button is very easy - only read and store the button state every ~20-30ms. In the program you only use the stored state.
Writing debounce and learning all those things USED TO BE a rite of passage here.
BUT learning to depend on black boxes is preferable, it seems. Good thing that AI can give us answers so we don’t need to THINK even for trivial matters!
In 1987 I heard 3 brand new Drexel Tech CompSci Masters say that they were taught to NOT improve their own code since the next gen computers will be bigger and faster. What a cop out, and now we’re here. BTW, none of them did anything but re-invent the same wheel (pilot training app) over and over — generalization was beyond them. Mush melons with degrees.
You could write a fast loop() that shows how bouncy.
My first and most usual development button is a jumper that I ground to “press”. It’s amazing the mileage I got out of investigating buttons that way, sliding a jumper on the USB jack box.
Contact switches bounce. How do you know when that stops IS the question behind debounce and yes there is more than one way and yes if you work even one out, you get to learn How To Approach And Solve Real Problems. Don’t skip that even if you can!
I agree, but in order to know what questions to ask yourself in order to create a proper de-bounce library is perhaps a stage they have not reached yet.
More than one person has already predicted that AI is a leading candidate to be the vector of our end days. I think that is very possible.
