3 ms·

Knew this would be good, was not disappointed.Glad I don't work in hardware.

frudyputy 1y ago
This is a very trivial problem, it doesn't even feel right calling it a 'problem'. It's probably the second lesson for the greenest Arduino newbie, right after blinking an LED. Don't let it discourage you from embedded hardware.
- lambdaone 1y ago
  Doing it right (via the algorithm above) is a trivial few lines of code. The thinking behind the state machine that gives both high reliability and low latency isn't trivial. It is, however, obvious once you know the trick of maintaining an extra auxiliary variable in addition to counter/timer variables, and understand that you don't need to wait for the bouncing to finish before registering a change. Think sort algorithms; everyone comes up with bubblesort first, but you can do much, much better with only tiny changes after a bit of thought.
- formerly_proven 1y ago
  On the one hand yes on the other hand I’d boldly claim incorrect debouncing is the most common (and usually exceedingly obvious) defect in embedded systems.
- tonyarkles 1y ago
  And yet… I’ve seen it done wrong so many times, resulting in either spurious inputs or lost inputs, depending on how it’s been implemented. I agree with you, don’t let it discourage you from embedded hardware. If you want to be successful in the embedded space, though, this is a great easy example to show that you need to take into account a bunch of physical effects when you’re doing hardware. Capacitors change their value with temperature and applied voltage (!), resistors have capacitance and inductance (which may or may not matter), clock crystals change frequency with temperature, switches bounce, ADCs have sampling capacitors that need to charge, chips power themselves up from active-high TTL lines, etc. I’ve been doing embedded for 20 years now and one of the biggest things I’ve encountered with new learners is that the Arduino platform is amazing for people to get into the field but they’ll hit a point where something mostly works and they don’t have the rest of the background necessary to debug or understand why it doesn’t work as well as they thought it would. Or works great and then “randomly” blows fuses/burns out of there isn’t a fuse.
- bombela 1y ago
  So trivial that I want to throw away by the window my microwave everytime I use it!
joezydeco 1y ago
Jack Gansssle wrote the definitive guide on debouncing for embedded systems. https://www.ganssle.com/debouncing.htm https://www.ganssle.com/debouncing.htm
bombela 1y ago
For my hobby projects I hardware debounce with a single tiny capacitor. The MCU already has schmitt trigger inputs (handles hysteresis). And it also has a high value pull up resistor. The tiny capacitor from input to ground complete the low pass filter. When you press the button, it quickly empties the capacitor to ground. Because it is so tiny, combined with the intrinsics parasitic resistance, this is a small enough EMI for hobby work. The MCU input will register the state change right away, the pull up resistor will slowly recharge the capacitor (we talking a few dozen of milliseconds here). The schmitt trigger will handle the transition cleanly. Nothing to do in code. Interrupts just work as expected without anything special. I think it's worth it.

This is a very trivial problem, it doesn't even feel right calling it a 'problem'. It's probably the second lesson for the greenest Arduino newbie, right after blinking an LED. Don't let it discourage you from embedded hardware.

lambdaone 1y ago
Doing it right (via the algorithm above) is a trivial few lines of code. The thinking behind the state machine that gives both high reliability and low latency isn't trivial. It is, however, obvious once you know the trick of maintaining an extra auxiliary variable in addition to counter/timer variables, and understand that you don't need to wait for the bouncing to finish before registering a change. Think sort algorithms; everyone comes up with bubblesort first, but you can do much, much better with only tiny changes after a bit of thought.
formerly_proven 1y ago
On the one hand yes on the other hand I’d boldly claim incorrect debouncing is the most common (and usually exceedingly obvious) defect in embedded systems.
tonyarkles 1y ago
And yet… I’ve seen it done wrong so many times, resulting in either spurious inputs or lost inputs, depending on how it’s been implemented. I agree with you, don’t let it discourage you from embedded hardware. If you want to be successful in the embedded space, though, this is a great easy example to show that you need to take into account a bunch of physical effects when you’re doing hardware. Capacitors change their value with temperature and applied voltage (!), resistors have capacitance and inductance (which may or may not matter), clock crystals change frequency with temperature, switches bounce, ADCs have sampling capacitors that need to charge, chips power themselves up from active-high TTL lines, etc. I’ve been doing embedded for 20 years now and one of the biggest things I’ve encountered with new learners is that the Arduino platform is amazing for people to get into the field but they’ll hit a point where something mostly works and they don’t have the rest of the background necessary to debug or understand why it doesn’t work as well as they thought it would. Or works great and then “randomly” blows fuses/burns out of there isn’t a fuse.
bombela 1y ago
So trivial that I want to throw away by the window my microwave everytime I use it!

joezydeco 1y ago

Jack Gansssle wrote the definitive guide on debouncing for embedded systems. https://www.ganssle.com/debouncing.htm https://www.ganssle.com/debouncing.htm

bombela 1y ago

For my hobby projects I hardware debounce with a single tiny capacitor. The MCU already has schmitt trigger inputs (handles hysteresis). And it also has a high value pull up resistor. The tiny capacitor from input to ground complete the low pass filter. When you press the button, it quickly empties the capacitor to ground. Because it is so tiny, combined with the intrinsics parasitic resistance, this is a small enough EMI for hobby work. The MCU input will register the state change right away, the pull up resistor will slowly recharge the capacitor (we talking a few dozen of milliseconds here). The schmitt trigger will handle the transition cleanly. Nothing to do in code. Interrupts just work as expected without anything special. I think it's worth it.