I've been playing around with the following circuit to do a hardware debounce of a reed switch (resistor is 100k and capacitor is 0.1uF):
I'm using the falling edge for an interrupt, so if I understand right, this is not a usual set-up in two respects: (1) this really filters the rising edge, and (2) normally there would be a Schmitt trigger involved.
But it really cleans up the falling edges, which are very sharp! It grounds immediately when the switch is closed, and the slow rise time means any further bouncing doesn't make much voltage change after the initial change to ground. What downsides am I missing? I know it is bad to short large electrolytic capacitors -- is it hard on the 0.1 uF electrolytic capacitor?
On a slightly separate note: I see that it is frequently said on these forums that software debounce is superior. How is that -- is the opinion mostly about lower component count? I like a hardware option, because my MCU can sleep more, but perhaps I'm not seeing the whole picture.
A lot of threads, and other info out there, suggests that a Schmitt trigger is very desirable. I've worked through my MCU's (ATMega4808) data sheet, and have not found information about how fast a rise or fall should be. Where would I look for that kind of information (I may have missed it or look in the wrong places in the 400+ page datasheet!).
Are you recommending this circuit, and its associated rise and fall times, for use with this sort of MCU? Or is your point more strictly (corresponding to my question) about the topology for the debounce circuit?
One could write a masters thesis on debouncing. The circuit I gave is just general purpose, you made need to tweek the resistor values depending on the bounce characteristics of the reed switch.
A schmitt trigger with the circuit I gave would work best.
A real switch debouncer IC would be optimum. It dependes how far you want to go how much you want to spend
Interrupts are for very fast re-occurring events, and debounce slows things down .
They somehow don't fit together.
What is your loop time, and what is the reed re-trigger time.
If loop is shorter than reed, then use polling.
If not, then use a hall sensor instead of a reed switch.
Leo..
I think a lot of it is lower parts count, but software debouncing can also be very effective. For example, you could include in your ISR code that disables any further interrupts on the pin in question, and initiate a countdown variable for the number of milliseconds the line needs to be continuously high before you consider the line to have been released, and only then re-enable the interrupt. That would take care of any bouncing in the low state, and any that might occur when it's released as well. Your loop would read the line every millisecond, and if it is low, it would reset the countdown. Only when it reaches zero are you in the clear. 10ms would be a typical countdown value.
Thanks everyone, and especially stitech for finding that Schmitt trigger symbol in the 4809 datasheet!
Looks like the very simple RC network should perform very well. Indeed, I have done a little more playing around than described in the original post and it does seem to work well (i.e., not suffer from slow rises and falls, as a lot of sources say should be a worry), but with knowledge of the basic theory now that there is a Schmitt trigger on the pin, I'm motivated to re-do that testing a bit more systematically. I'll do a bit of testing in the next couple of days if I can make time.
Thanks to those suggesting reasons for software debounce and ways to do it. Briefly, I'm going a hardware route (unless convinced otherwise) here because I want my MCU to wake for only the shortest intervals possible, interrupts will be fairly frequent (possibly 0.1-3 per second) and ms or better timing the interrupts is not necessary.
Not very extensive testing, but the advice here has I think proven good (not that I doubted it).
Using this as a test circuit (the basic approach thanks to jim-p) things work very well:
I'm using rather larger resistors to minimise current consumption, as one of the reed switches will be closed 50% of the time. Thanks to the Schmitt trigger on the MCU's input (thanks for pointing it out, stitech), I seem to be able to detect the falling edges as a single interrupt all the way up to a using a 100 nF capacitor. I tried a 1uF capacitor, and started to get some spurious interrupts (i.e., two for one button press).
You will be better off to play around with the type of magnet and the orientation of it's magnetic field. Proper design will result in no bounce on closing and no bounce on opening. Perhaps the magnet is TOO strong! Remember, the steel pins on the ends of the switch conduct the magnetic field to the switch leaves.
I think all those components is a bit overkill.
A single cap - around 0.1uF - and resistor is all thats needed; and you can use the internal pull-up.
But the cap needs to be across the contacts so the surge current doesnt flow anywhere else.
You might think the current would harm the switch - but the energy stored in the capacitor is very small. Anyway its proved effective for the last hundred years or so.
The reason to choose for software debounce can be simply practical: I’ve got my UNO R3 on the table and I don’t feel like digging in my stock for breadboard, resistors and capacitors; and I’m busy writing the program anyway.
An algorithm I used before: I use interrupt-on-pin-change to start or restart a hardware timer. If the timer interrupts after a given time, I know the inputs are stable; comparing inputs to previous states determines rising, falling or stray pulse. Each bounce will wake up the processor for the duration of the interrupt routine.
The internal pull up resistors are typically 35kOhm, not much current when the switch is closed and none when opened.
You are using 4 components per input. Now imagine designing a PCB with a few inputs hardware debounced. The ‘small’ components will use a much larger area than the processor itself. A point in favour of software debounce.
But feel free to use hardware debounce, it’s your project after all.
Mechanical contacts without bounce might theoretically be possible, but don’t count on it.
I agree - it isn't a lot of current. But I have the rest of the project down to drawing < 10 uA when asleep - and it's mostly asleep - with the hope of it running on standard AA batteries for many months at a time. That leaves this reed switch circuit the largest power draw in the project (when asleep). My attention to power savings may seem a bit overkill (and perhaps it is), but it is with the goal to ultimately simplify power provision.
