Go Down

Topic: debounce problem (Read 8400 times) previous topic - next topic

dhenry

Quote
Well as Grumpy_Mike pointed out, you should try a larger capacitor.


Do the opposite: use as small of a capacitor as you can.

dhenry

For any of you with a highspeed scope, put it across the capacitor and observe the waveform when you close the button.

No, it is not about bouncing.

Far-seeker


For any of you with a highspeed scope, put it across the capacitor and observe the waveform when you close the button.

No, it is not about bouncing.


Well the original post was about signal bouncing, and apparently the problem was solved to ironbot's liking. :)  Given that for all we know ironbot is using something like this, I doubt worrying about contact degradation is worthwhile at this point.

dhenry

Quote
I doubt worrying about contact degradation is worthwhile at this point.


If you think this discussion is about contact degradation, you haven't understood this discussion.

Far-seeker


Quote
I doubt worrying about contact degradation is worthwhile at this point.


If you think this discussion is about contact degradation, you haven't understood this discussion.

Well, you are the one that quoted MarkT's comment about possible contact degradation and stated it was the most insightful comment in the thread (see below). 


Quote
The existing 10uF is being shorted into the switch each time it closes creating a tiny spark, which may eventually erode the contacts if the switch is small.


The most insightful comment in this whole thread.

MarkT is absolutely right here.


If you expect people that can't/won't do your experiment to know, rather than guess, about what you are refering to maybe you should tell them.  Cryptic advice is of little use to anyone.

BenF


True, can't do software debounce for I'm on ISR, no delay() !

Not true at all.

Two common ways as follows:

1. Disable interrupt in the ISR on first contact and record time to a global variable. Reenable interrupts in the loop after a bounce guard time.

- or -

2. Record time to a static variable in the ISR on first interrupt. Ignore successive interrupts until guard time has elapsed.

tuxduino

Quote
1. Disable interrupt in the ISR on first contact and record time to a global variable. Re-enable interrupts in the loop after a bounce guard time.


When the code enters an ISR interrupts are automatically disabled.
And automatically re-enabled when the ISR ends.
Also, how are you going to measure this bounce guard time, if interrupts are disabled hence millis() can't advance ?
(Self-answer: probably keeping only that particular interrupt disabled while globally enabling interrupts.)

Too tricky IMHO, if at all feasible.

Point 2 looks doable, instead.

TCSC47

Hi
Firstly MarkT is correct in saying that a schmitt trigger such as 74HC14 should be used for this type of switch debounce circuit. You are inputting a relatively slowly changing voltage level to the invertor which may result in false switching signals as the input slowly crosses the switching levels of the device.

Secondly, I am new here and know little of the Arduino microproc boards, so my next suggestion is a question. Is there any reason why the standard two Nand gate flip flop with a change over switch can not be used for switch debounce? This is the circuit I have almost always used for such applications.

See for example http://hyperphysics.phy-astr.gsu.edu/Hbase/electronic/setreset.html

Apologies for not attaching an image but I am still learning how to operate this site.

Cheers

dc42

Although TCSC47's suggestions are valid and workable, the whole point of microcontrollers is that by using software they can do in a single device many functions that previously we had to build separate hardware to do. Use software debounce.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

dhenry

Quote
Use software debounce.


I have found the old fashioned r/c debouncer to be quite effective and reliable.

dc42

#25
Oct 04, 2012, 02:56 pm Last Edit: Oct 04, 2012, 03:02 pm by dc42 Reason: 1

Quote
Use software debounce.


I have found the old fashioned r/c debouncer to be quite effective and reliable.



Yes, I'm sure it is; the atmega mcus have input hysteresis, so they can cope with the slowly-varying signal that this provides. But I prefer writing code to soldering components. [Actually, I don't even have to write any code, because I re-use the PushButton class that I developed a while ago.]
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

TCSC47

Hi dc42
Your answer for using software debounce is one that I certainly would accept for large production professional designs requiring small space and small component count.

Also, as you have informed us, the inputs for the atmega device have hysterisis, then the sensor switches can be connected directly to the device, eliminating the 74HC14 completely, reducing the component count to a minimum.

However, and admitting that I do not have full details of what ironbot is doing, his project seems to me to be a learning exercise. Thus I would always advise a gate of some sort between the microproc and an outside input, to protect the microproc and allow alot of messing about with soldering, flying leads, and mistakenly connected inputs etc.

Also, as such, I would try and separate as many of the component parts of the design as possible. By using the two NAND gate debounce which is virtually infallible, we can get into the more intersting aspects of programming the functioning of the project, knowing that switch bounce is not a problem. Later on when all the fun bits have been done, then we could return to the finer points of professional design.

Incidently, as has been pointed out here already, an oscilloscope would be a very useful bit of kit to see exactly what is going on with problems like switch bounce. I've just bought a second hand scope with a terrific spec. for £100 on line.
Cheers

dhenry

Quote
the inputs for the atmega device have hysterisis, then the sensor switches can be connected directly to the device, eliminating the 74HC14 completely, reducing the component count to a minimum.


I don't know how the hysterisis (either on the atmega or hc14) would have eliminated the need for debouncing. Your circuit would have worked with a non-ST gate and the atmega, with hysterisis, would malfunction without a debouncing approach.


BenF


When the code enters an ISR interrupts are automatically disabled.
And automatically re-enabled when the ISR ends.
Also, how are you going to measure this bounce guard time, if interrupts are disabled hence millis() can't advance ?

The trick is to only disable the relevant interrupt vector (external interrupt or pin-change interrupt). Using external debounce-circuits with microcontrollers went out of fashion 20 years ago.- This thread can serve as good example why that is.

tuxduino



When the code enters an ISR interrupts are automatically disabled.
And automatically re-enabled when the ISR ends.
Also, how are you going to measure this bounce guard time, if interrupts are disabled hence millis() can't advance ?

The trick is to only disable the relevant interrupt vector (external interrupt or pin-change interrupt). Using external debounce-circuits with microcontrollers went out of fashion 20 years ago.- This thread can serve as good example why that is.


I thought about that. But then you'd have nested interrupts. Scary :P Much better IMHO to have the ISR fire at regular intervals and debounce using volatile global variables, or by using static locals and using a volatile global to communicate with the main code.

Go Up