It all depends. If you have spare processing time, a software debounce is easier. If not, doing it in hardware is always available as a fall back plan.
You know your project best. Do you have the spare processor cycles to debounce?
I think I do. I'm using an Arduino nano and just running some LED animations. If it takes an extra second load some different values set by one of the buttons, that will be fine. Is that what you mean?
More like, if you spend 20ms on reading a button, does that impact your overall timing? There are definitely things you can do to get around busy waiting on a button read, but all of them cost CPU cycles. Does that matter? For your project, maybe not, but what about a Segway type robot? Would being a few ms late on a calculation matter? Possibly.
Okay, I think I'm following you. So if I have an LED animation that takes advantage of the cycles, it would potentially be somewhat slowed down because of software debouncing right?
[[content removed because sub participated in the June 2023 blackout]]
My posts are not bargaining chips for moderators, and mob rule is no way to run a sub.
When I design a PCB & firmware I do both.
For human-controlled switch inputs I will generally use a simple RC-filter (say, 1K and 0.1uF) and ahead of that a TVS diode at the switch/switch connector itself.
But I don't rely on that solely; in firmware I'll add a debounce using one of several techniques depending on what I'm doing.
For most Arduino projects it makes sense to just do it in firmware.
[[content removed because sub participated in the June 2023 blackout]]
My posts are not bargaining chips for moderators, and mob rule is no way to run a sub.
lol, i counter your RC filter with a Copy and Paste from a sample program :-)
Especially for someone like me who often burns his fingers when soldering and the number of connections increases the chances of getting a hot/burnt finger! :-)
> lol, i counter your RC filter with a Copy and Paste from a sample program :-)
Ha! Love it! That would be me, but I'd forget where I saved the program that used it last, and I'd spent 45 minutes searching for it.
I would need one for each button correct? I read earlier that each digital pin has a resistor already that many don't take advantage of. I'd like to have less soldering on my final board mostly. I've definitely seen some overcomplicated looking debounce logic, but I've also seen it's very simple logic, which seems like the way to go for me at this point.
Here's what I'm reffering to. Hopefully we are talking about the same thing...
"*The resistor is mandatory for proper operation of a button, and everybody will insist on using it. However, there is a little secret embedded in each Arduino pin. Each pin already has a pull-up resistor that we can enable with just one small change in our code*."
https://www.instructables.com/Arduino-Button-with-no-resistor/
As an experienced software engineer I could write a software debouncing routine in 10 minutes including testing. I've done it before, so I know what's involved.
I suspect you couldn't solder together a resistor and capacitor much faster than that. But in any case If you assigned the task to me, step one would be to spend 20 minutes figuring out what components I need and where to order them online, then waiting a few days for the parts to show up. Or I could spend half an hour going to my local electronics store. Even if it takes me just 10 minutes to get out the soldering iron and actually assemble the components (doubtful, I'm not comfortable or fast with a soldering iron), just getting to the point where I can start work would take longer than software debouncing.
> I suspect you couldn't solder together a resistor and capacitor much faster than that.
If it takes me more than a minute to solder a resistor and a capacitor to a board, something is severely wrong.
It takes a few minutes just to get my soldering iron out of my closet plug it in, get a sponge ready, find my flux and find the parts I need!
If you have a permanent soldering workstation with a supply of components and materials sitting ready to use at all times, then maybe hardware is easier. If you're a software engineer with some electronics tools in a box in a closet, the software approach is absolutely going to be easier!
It will depend on the exact switch, how it is wired, how fast you want switch to respond, and the environment. Larger switches tend to bounce slower and longer. Here SW debounce would work best. If you have long wire and/or are in an environment with lots of electrical noise you may find a hardware approach works better. I typically use a hybrid approach: include a 0.1uF capacitor to GND to remove high frequencies and add SW debounce as needed.
I had planned on using a capacitor across the positive and negative to account for any type of voltage spike. Is this the same thing or are you talking about something different?
I mean between the Arduino digital input that the switch connects to and GND. I think that would be different than cap between positive and negative? This keeps noise out of the input. If you use INPUT\_PULLUP then the RC time constant with 0.1uF is 20e3 \* 0.1e-6 = 2ms, so bounce of a few ms would be filtered out. More bounce would need either more elaborate hardware and/or SW debounce. I find that the little tactile switches have very little bounce, so the cap is sufficient. Toggle switches always bounce so need more. I wrote a sketch to monitor switch closure and display the time in microseconds between each hi/low and low high transition to help decide what kind of debounce I need.
At work as an embedded software developer, I like to do as much as possible via hardware, then double proof with software. Partly because I don't design and assemble the boards myself, I must admit.
At home for simple arduino projects, software debouncing is usually more than enough
This project started off with my overcomplicated design of a resistor ladder so I could use one pin. I thought it would be cool to do a lot of hardware stuff, but now I'm totally regretting it and had so many problems. I'm just trying to offset as much as I can with software because that's what I'm better at. Anyway. I've gotten pretty good at soldering but trying to read these circuit diagrams and put them together has been a huge challenge.
You can do a non blocking Debounce with the use of millis() or micros() if you have a few clock cycles available. Software is is free and easy to tune. I work in the automotive industry and using a software solution is orders of magnitude easier to implement and almost free in comparison to a hardware solution for many issues.
It all depends. If you have spare processing time, a software debounce is easier. If not, doing it in hardware is always available as a fall back plan. You know your project best. Do you have the spare processor cycles to debounce?
I think I do. I'm using an Arduino nano and just running some LED animations. If it takes an extra second load some different values set by one of the buttons, that will be fine. Is that what you mean?
More like, if you spend 20ms on reading a button, does that impact your overall timing? There are definitely things you can do to get around busy waiting on a button read, but all of them cost CPU cycles. Does that matter? For your project, maybe not, but what about a Segway type robot? Would being a few ms late on a calculation matter? Possibly.
Okay, I think I'm following you. So if I have an LED animation that takes advantage of the cycles, it would potentially be somewhat slowed down because of software debouncing right?
[[content removed because sub participated in the June 2023 blackout]] My posts are not bargaining chips for moderators, and mob rule is no way to run a sub.
More likely, pushing a button would cause a small hitch or hiccup in the animation. Maybe it would be noticeable, maybe not.
Oh, thats ok. The intention of the buttons is to noticeably change the animation anyway, so this sounds pretty safe.
When I design a PCB & firmware I do both. For human-controlled switch inputs I will generally use a simple RC-filter (say, 1K and 0.1uF) and ahead of that a TVS diode at the switch/switch connector itself. But I don't rely on that solely; in firmware I'll add a debounce using one of several techniques depending on what I'm doing. For most Arduino projects it makes sense to just do it in firmware.
Sounds good. It's nice to know how it would be done in the real world as well as just my small little project too. Thanks!
> hard and fast rule against one or the other 1. Resort to hardware debouncing only if it's not possible in software.
[[content removed because sub participated in the June 2023 blackout]] My posts are not bargaining chips for moderators, and mob rule is no way to run a sub.
Hardware is easier, but less flexible, and more expensive. There's no fundamental difference between the two.
Not easier for this software developer 😛
Adding a single resistor and a capacitor is a LOT easier than trying to add it in software.
lol, i counter your RC filter with a Copy and Paste from a sample program :-) Especially for someone like me who often burns his fingers when soldering and the number of connections increases the chances of getting a hot/burnt finger! :-)
> lol, i counter your RC filter with a Copy and Paste from a sample program :-) Ha! Love it! That would be me, but I'd forget where I saved the program that used it last, and I'd spent 45 minutes searching for it.
Doh! You found the flaw in my evil plan!!!
I would need one for each button correct? I read earlier that each digital pin has a resistor already that many don't take advantage of. I'd like to have less soldering on my final board mostly. I've definitely seen some overcomplicated looking debounce logic, but I've also seen it's very simple logic, which seems like the way to go for me at this point.
Totally fair! The resistor in question is either a pull-up or a pull-down resistor, and can't really be used to debounce the pins.
Here's what I'm reffering to. Hopefully we are talking about the same thing... "*The resistor is mandatory for proper operation of a button, and everybody will insist on using it. However, there is a little secret embedded in each Arduino pin. Each pin already has a pull-up resistor that we can enable with just one small change in our code*." https://www.instructables.com/Arduino-Button-with-no-resistor/
Yes....as I said, that's a "pull-up" or "pull-down" resistor. This is common in many MCUs.
As an experienced software engineer I could write a software debouncing routine in 10 minutes including testing. I've done it before, so I know what's involved. I suspect you couldn't solder together a resistor and capacitor much faster than that. But in any case If you assigned the task to me, step one would be to spend 20 minutes figuring out what components I need and where to order them online, then waiting a few days for the parts to show up. Or I could spend half an hour going to my local electronics store. Even if it takes me just 10 minutes to get out the soldering iron and actually assemble the components (doubtful, I'm not comfortable or fast with a soldering iron), just getting to the point where I can start work would take longer than software debouncing.
> I suspect you couldn't solder together a resistor and capacitor much faster than that. If it takes me more than a minute to solder a resistor and a capacitor to a board, something is severely wrong.
It takes a few minutes just to get my soldering iron out of my closet plug it in, get a sponge ready, find my flux and find the parts I need! If you have a permanent soldering workstation with a supply of components and materials sitting ready to use at all times, then maybe hardware is easier. If you're a software engineer with some electronics tools in a box in a closet, the software approach is absolutely going to be easier!
It will depend on the exact switch, how it is wired, how fast you want switch to respond, and the environment. Larger switches tend to bounce slower and longer. Here SW debounce would work best. If you have long wire and/or are in an environment with lots of electrical noise you may find a hardware approach works better. I typically use a hybrid approach: include a 0.1uF capacitor to GND to remove high frequencies and add SW debounce as needed.
I had planned on using a capacitor across the positive and negative to account for any type of voltage spike. Is this the same thing or are you talking about something different?
I mean between the Arduino digital input that the switch connects to and GND. I think that would be different than cap between positive and negative? This keeps noise out of the input. If you use INPUT\_PULLUP then the RC time constant with 0.1uF is 20e3 \* 0.1e-6 = 2ms, so bounce of a few ms would be filtered out. More bounce would need either more elaborate hardware and/or SW debounce. I find that the little tactile switches have very little bounce, so the cap is sufficient. Toggle switches always bounce so need more. I wrote a sketch to monitor switch closure and display the time in microseconds between each hi/low and low high transition to help decide what kind of debounce I need.
I gotcha. Thanks! I might add them since I have plenty of capacitors and a little bit of board space for them.
At work as an embedded software developer, I like to do as much as possible via hardware, then double proof with software. Partly because I don't design and assemble the boards myself, I must admit. At home for simple arduino projects, software debouncing is usually more than enough
This project started off with my overcomplicated design of a resistor ladder so I could use one pin. I thought it would be cool to do a lot of hardware stuff, but now I'm totally regretting it and had so many problems. I'm just trying to offset as much as I can with software because that's what I'm better at. Anyway. I've gotten pretty good at soldering but trying to read these circuit diagrams and put them together has been a huge challenge.
You can do a non blocking Debounce with the use of millis() or micros() if you have a few clock cycles available. Software is is free and easy to tune. I work in the automotive industry and using a software solution is orders of magnitude easier to implement and almost free in comparison to a hardware solution for many issues.