I recently started with the Arduino (UNO R3) after I got an ebook at a reduced price. In this book there is an example of a button connected to an input pin of the arduino, pulled to ground by a 10k resistor with a 100nF capacitor in parallel to that resistor to cover up button bouncing.
As I was trying this out with a simple sketch that just printed out a counter on Serial, I noticed that after a few (less than 20) times the button was pressed, the output became erratic (mostly starting from zero) before everything froze up. With ouput over a few LEDs instead of serial the result was similar, all LEDs switching on before freezing up.
Without the capacitor I can press the button repeatedly until my finger gives in without anything going wrong. So I'm guessing there is something electronically wrong with this setup. Can anybody explain this to me? I tried Google and the forum search already but did not find anything specific to this. And if there is a general concept that explains it, I may still be too unexperienced to see the connection. I fear I may (or have already) damage(d) my Arduino.
What I found so far on debouncing is to either do it in software or to use the internal pullup, an external pullup resistor and a capacitor in series and an inverting schmitt trigger. I'm going to try this the next time I order components, but I'd still like to understand (on a general level at least) what was wrong with the first approach.
Hardware denouncing or Software denouncing.. . what else could there be?
Seriously, entire seminars are given on this topic.
The exact engineering approach is usually "some of both."
Without the capacitor I can press the button repeatedly until my finger gives in without anything going wrong.
. Not all buttons are created equal. And, there may be some issues in the software - especially if the program hangs. But it would be unlikely the Arduino is damaged.
Google on this: [microcontroller button debounce](http://microcontroller button debounce) there a lots of ways this issue is handled and not all are appropriate to every denounce situation. This is why testing various options is desirable.
LarryD:
Did you have the internal pull-up resistor enabled?
I did not expicitly enable the pullup, so I guess it wasn't. I just tried it again, one time with the internal pullup disabled and once enabled. Surprisingly (at least to me), when the internal pullup was disabled, the behaviour was as described above. When I enabled the pullup, everything seemed to work fine (at least for about the 200 clicks on the button I tried).
But I don't see much sense in simultaneously pulling the pin up with the internal resistor and pulling it down externally. Shouldn't this lead to a continous current from the pin to ground while the button is not pressed?
I am currently not looking for the best way to debounce a button, as far as I can see there is quite a lot to read about that, but I'd just like to understand why this setup behaves the way it does.
But I don't see much sense in simultaneously pulling the pin up with the internal resistor and pulling it down externally. Shouldn't this lead to a continous current from the pin to ground while the button is not pressed?
I think the intention was to make sure you -aren't- enabling the pullup, for the very reasons you gave.
sleeper_ds:
I recently started with the Arduino (UNO R3) after I got an ebook at a reduced price. In this book there is an example of a button connected to an input pin of the arduino, pulled to ground by a 10k resistor with a 100nF capacitor in parallel to that resistor to cover up button bouncing.
By the sound of it that's a bad circuit, its a crowbar on the supply voltage. There needs
to be a RC divider to form a low-pass filter, and R and C in parallel isnt a divider.
But I don't see much sense in simultaneously pulling the pin up with the internal resistor and pulling it down externally. Shouldn't this lead to a continous current from the pin to ground while the button is not pressed?
I think the intention was to make sure you -aren't- enabling the pullup, for the very reasons you gave.
I guessed so, but it only worked the other way around, strangely enough.
MarkT:
sleeper_ds:
I recently started with the Arduino (UNO R3) after I got an ebook at a reduced price. In this book there is an example of a button connected to an input pin of the arduino, pulled to ground by a 10k resistor with a 100nF capacitor in parallel to that resistor to cover up button bouncing.
By the sound of it that's a bad circuit, its a crowbar on the supply voltage. There needs
to be a RC divider to form a low-pass filter, and R and C in parallel isnt a divider.
That's the closest explanation to the strange behaviour so far, I think. I already thought for myself that this setup might lead to a current straight from +5V to ground for short periods of time, but as a beginner I assumed just assumed the example in the book would work correctly.
Thanks for the answers everyone. I hope you had a good start into the new year.
sleeper_ds:
What I found so far on debouncing is to either do it in software or to ...
...or to ... do it wrong.
Hardware debouncing is only needed when a switch is connected directly to some TTL chips (or something like that).
You don't need it when you have software, just make sure some time passes between each press.
I would disagree in the case of using a simple button to input to user interrupt pin(s). Implementing software debouncing inside a ISR adds complexity, code length, and time that a simple hardware debouncing solution could eliminate.
There's an important difference between using a push button on a normal input pin and using a push button on an interrupt pin:
A push button on a normal input pin is used to enter a value that is read by software and later used by software, and the switch can be debounced in hardware or in software as desired.
A push button on an interrupt input generates an interrupt, and if the switch is not debounced externally in hardware each bounce that occurs will generate a fresh interrupt, creating a situation that may be complex to handle and is best avoided.