Forum 2005-2010 (read only)
Syntax & Programs
(Read 6926 times)
Aug 30, 2010, 02:47 am
I was working on my example above, which is quite stable code.. Accidentically probing in a "spike" is very, very unlikely. This is of course differently when your interrupt-system is lurking for that :-)
There can be more in "switch" but a switch, though generally it is counterpart of a pulldown or pullup of 100k or less. To inject here a 1us spike of 2.5 volts is - tricky.
But, yes, there can be circumstances...
Aug 30, 2010, 04:01 am
: Aug 30, 2010, 04:02 am by InvalidApple
Actually, it's quite easy when the switch is in the other room and is connected with unshielded wire.
If all digital inputs where 100% reliable, we would not need error detection (parity checks, cyclic redundancy checks, ...) on serial communication.
I'm sorry, but I don't think that to "just do it" when the first edge is detected is good practice (for a switch input). This is because the chance of having a program long enough (quote "100ms") to oversee the bouncing is "very, very unlikely".
The edge detector, in my opinion, is much better suited to analysing digital data communication, rather than a switch input.
Aug 30, 2010, 12:45 pm
: Aug 30, 2010, 01:27 pm by mpeuser
I never talked in favour of "edge detection", on the contrary!
Noise is a very critical issue with analog input. True "noise" on digital lines is rare. What you get is "spikes", the source of which is often a carelessly attached brush motor.
Still I cannot see how this will affect an input pin pulled by the typical paranoic value of 10k to well decoupled + or ground....
I just managed to dig out an articled I had read some years ago, with a lot of details..
Aug 31, 2010, 03:44 am
A Digital signal is just an interpretation of an analogue signal and obeys the analogue laws, such as attenuation. If the signal to noise ratio (SNR) is not large enough, your chances of reading a false reading are much more probable (this is the power of the signal, not voltage).
Because we are dealing with small currents here (hence lower powered signals), false readings should be a concern. The problem with impulse noise is that it is a high powered signal, which can be caused by coupling with a light being turned on or off (not just a brush motor).
It would be wrong to assume that the switch used in Joker's project is of ideal nature. How long are the wires? How thick are the wires? What possible sources of noise are there where their project is designed to run? You don't know what environment and hardware Joker's project will be operating with, so saying that the probability of transmission impairments occurring is "very, very unlikely" is just not a good assumption. What if the switch was to turn on a nearby "brush motor"?
The experiment in this article does
address the issue of any sort of transmission impairments (eg: attenuation, delay distortion, thermal noise, impulse noise, crosstalk, ...). It does not say what power the signal it is, so it would be wrong to speculate; however, it does seem to be strong enough to ward off the effects of noise.
It also acknowledges the random nature of bouncing saying that 2 switches exceeded 6.4mSec in bouncing time, with one sample at 157mSec in opening (I'd put that switch in the bin). This article finished by saying, "
Assume things are worse than shown
If you then click on <Go to Page Two of This report> at the bottom of the page, there are many different techniques for solving the debouncing switch problem.
"But the environment itself can induce all sorts of short transients that mask themselves as switch transitions. Called EMI (electromagnetic interference), these bits of nastiness come from energy coupled into our circuits from wires running to the external world, or even from static electricity zaps induced by shuffling feet across a dry carpet. Happily EMI and contact whacking can be cured by a decent debounce routine. . . . but both factors do affect the design of the code"
The bottom line of what I (and page 2 of the article deSilva provided) was trying to say is that using debouncing methods in your code/hardware
is good practice
. Also, methods for debouncing can usually double up as protection against some transmission impairments: Therefore, debouncing should
be omitted from your design as suggested by deSilva.
Aug 31, 2010, 10:40 pm
: Aug 31, 2010, 10:42 pm by mpeuser
I definitely support nearly everything said. But being a little bit theoretically oriented, I can't help noticing that debouncing is not deglitching. Both try to avoid to erroniously find a signal where no signal is. Also both can be considered as a kind of "pattern matching"... Still one has to know what the characteristics of both issues are, and they are different.
It will do no harm to also do all-purpose deglitching. But when you feel you need this, then you are in greater trouble than you think in the first place. When you have to debounce a switch then you just have a common switch.
The simple algorithm I gave above will work in many situations. It will be less reliable when you exchange the level-probing by interrupt edge detection. That will be something quite different. So when you - for what reason ever - have to use interrupts, my small example is not at all the best algorithm!
I - and some of you - have used small devices that react to a pressed key after 200 ms only. This is awkward. The programmers meant well I am sure, but this is not my style..
Sep 01, 2010, 02:57 am
If I can't convince you that debouncing is a good idea because of the advantages given in the article you posted, I'm going to stop with this thread now.
Sep 01, 2010, 07:54 am
If you refuse to understand that I am an advocate for debouncing, then I think that is best. Funny misunderstandings.... Maybe my bad English...