The MSO showered the screen with hash as it tried to interpret the data. It was if the contacts didn't bounce so much as wiped, dragging across each other for a time, acting like a variable resistor. Another artifact of this wiping action was erratic analog signals treading in the dreaded no-man's land of TTL uncertainty 0. The two from the el cheapo game joystick were nothing more than gold contacts plated onto a PCB; a rubber cover, when depressed, dropped some sort of conductive elastomer onto the board.
Interestingly, the analog result was a slow ramp from zero to five volts, with no noise, wiping or other uncertainty. Not a trace of bounce. And yet.. What's going on? With TTL logic, signals in the range of 0. Anything goes, and everything did. Tie this seemingly bounce-free input to your CPU and prepare to deal with tons of oscillation - virtual bounces. My assessment, then, is that there's much less whacking of contacts going on than we realize.
A lot of the apparent logic hash is from analog signals treading in illegal logic regions. Regardless, the effect on our system is the same and the treatment identical.
But the erratic nature of the logic warns us to avoid simple sampling algorithms, like assuming two successive reads of a one means a one. So we know how long the contacts bounce and that lots of digital zaniness - ultra short pulses in particular - can appear. But what happens during the bounce?
Quite a lot, and every bounce of every switch was different. Many produced only high speed hash till a solid one or zero appeared. Others generated a serious pulse train of discernable logic levels like one might expect. I was especially interested in results that would give typical debounce routines heartburn.
Consider switch E again, that one with the pretty face that hides a vicious msec bouncing heart. One test showed the switch going to a solid one for 81 msec, after which it dropped to a perfect zero for 42 msec before finally assuming its correct high state. Think what that would do to pretty much any debounce code! Switch G was pretty well behaved, except that a couple of times it gave a few microsecond one before falling to zero for over 2 msec.
Then it assumed its correct final one. The poor ISR would be left puzzled as it contemplates 2 msec of nothingness. Why did it invoke me? Ain't nuthin' there! O is a very nice, high quality microswitch which never showed more than 1. But digging deeper I found it usually generated a pulse train guaranteed to play havoc with simple filter code. There's no high speed hash, just hard-to-eliminate solid ones and zeroes. Easy to filter? But not by code that just looks for a couple of identical reads.
What happens if we press the buttons really, really fast? Does that alter the bouncing in a significant way? It's awfully hard for these aging fingers to do anything particularly quickly, so I set up a modified experiment, connecting my MSP board to a sizeable 3 amp four pole relay. Downloading code into the CPU's flash let me toggle the relay at different rates. The relay had no noticeable analog effects, banging cleanly between 0 and 5 volts. The raucous clacking of contacts overwhelmed our usual classical fare for a few hours as the MSO accumulated bounce times in storage mode.
When the relay opened it always had a max bounce time of 2. More variation appeared on contact closure: at 2. I have no idea. But it's clear there is some correlation between fast actuations and more bounce. These numbers suggest a tractable factor of two increase, though, not a scary order of magnitude or more. In the bad old days we used a lot of leaf switches which typically bounced forever. Weeks, it seemed. Curious I disassembled a number of cheap consumer products expecting to find these sort of inexpensive devices.
None found! Now that everything is mounted on a PCB vendors use board-mounted switches, which are pretty darn good little devices. Counters have to be simply incremented when two consecutive states are sampled at same value.
Otherwise, reset the counter. Once the counter reaches a threshold, the input state can be considered stable and the output state is updated. This kind of functions like schmitt trigger, where you have to cross the threshold for the other state to switch from the current state.
The following waveform shows how such a debouncer will behave with bouncing switches and ensures clean glitch-free state change at output. The counter threshold can be computed as a function of system clock frequency and bouncing time of the switch, and then round it off to the higher and nearest power of two for efficient hardware implementation.
The size of the N-bit counter can be calculated as:. Smaller the clock frequency, smaller the counter size. Fully synthesisable and tested Debouncer source codes are available in my github for free use in your designs. Time to get the hands dirty!
I have got a bunch of low-cost tactile toggle switches at home, which I tested out on breadboard with my DSO. Which is why, we shall now add our Debouncer at the switch output.
Oh yeah! We can notice pretty clean switch transitions after debouncing!! The yellow channel is the actual input with visible bouncing, and the green channel shows corresponding Debouncer output. Debouncer was configured for quite pessimistic scenario, i.
Switches can be simple and yet nasty customers. Always be on the safer side by properly debouncing switches before you feed it to the hardware. Use dedicated circuitry or software routine for debouncing.
Introduction to Microcontrollers Mike Silva. Forums More Forums comp. Chronological Newest First are there any vhdl codes that are available for free to debounce the pushbutton on my spartan 3E? I require the push button to generate only 1 clock for 50mhz only upon release.
I've gotten some code from the net but aint sure if it does what I need I think whether this code works for you depends on the push button. After just a week or two of use they bounce so badly that it is impossible to debounce them. The best switch to debounce is a double throw switch. The FF stays in a given state until the other contact is made. Very simple, but it requires two inputs and a more complex switch.
It filters single spikes, which are shorter than 20ms and filters any bouncing sequence shorter than 10ms. I would add a generic parameter for specifying the clock frequency to make the entity more resuable. Yes, a SPCO switch classic Micro-switch action is more complex, as it has an extra contact, but I cannot see the 'requires two inputs' in any I have used?
0コメント