does anyone have any pointers on testing and optimising bounce behaviour of mechanical switches?
I know based on Ganssle’s testing (ref http://www.ganssle.com/debouncing.pdf) that the mechanical switch bounce time can vary greatly, so even though I nominally have 3x switches of the same manufacturer I can expect a variation.
Perhaps part of my understanding gap is what the expected interrupt behaviour should be as I vary the Cpu.GlitchFilterTime. Let me explain my setup.
I am using the following code to set up the interrupt and handler:
InterruptPort KeyDigitalUp = new InterruptPort((Cpu.Pin)FEZ_Pin.Interrupt.Di0, true, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeBoth);
KeyDigitalUp.OnInterrupt += new NativeEventHandler(pushbutton_OnInterrupt);
I have a simple momentary contact pushbutton switch with a pulldown resistor connected to the IO port. My handler is currently processing 3 switches and using a switch/case for picking which one to do and then setting flags and altering values (hopefully minimal processing, although i am doing string handling at the moment while debugging - bad I know - but it’s only doing debug.print of a string value at the moment).
Often times, I’ll see the handler invoked twice in a row with the same state value of 1 (in my case that’s the key pressed state). I can’t really get my mind around what that might be - is it a distinct bounce between de-glitch reads, perhaps the 2nd interrupt fires (on trailing edge) and the handler doesn’t get the right state value? Does anyone have any other alternatives on what might happen there? I don’t see a single push generate 4 interrupts (ie a classic bounce situation) but I do see this “state doesn’t change” a lot.
If I change the Cpu.GlitchFilterTime setting I’m assuming that the internal filter will require a signal to settle for at least the value of Cpu.GlitchFilterTime before signalling an interrupt, is that correct? I’ve tried testing by altering the Cpu.GlitchFilterTime between 5 and 20 ms, even tried in the 200-500 range as well - this double-signal of state=1 has not really reduced.
thoughts, guidance, or a lifeline appreciated !