If you’ve ever turned a rotary encoder or pushed a cursor button and had it skip a step or two, you’ve suffered directly from button bounce. My old car stereo and my current in-car GPS navigator both have this problem, and it drives me nuts. One button press should be one button press. How hard is that to get right?
In the last session of Embed with Elliot, we looked into exactly how hard it is to get right and concluded that it wasn’t actually all that bad, as long as you’re willing to throw some circuitry at the problem, or accept some sluggishness in software. But engineers cut corners on hardware designs, and parts age and get dirty. Making something as “simple” as a button work with ultra-fast microcontrollers ends up being non-trivial.
And unsurprisingly, for a problem this ubiquitous, there are a myriad of solutions. Some are good, some are bad, and others just have trade-offs. In this installment, we’re going to look at something special: a debouncer that uses minimal resources and is reasonably straightforward in its operation, yet which can debounce along with the best of ’em.
In short, I’ll introduce you to what I think is The Ultimate Debouncer(tm)! And if you don’t agree by the end of this article, I’ll give you your money back.
“Psst…hey buddy! Wanna see the sweetest little debouncing routine this side of Spokane? C’mon over here. Step right over those bit-shift operators, they don’t bite. Now look at this beauty right here: I call her The Ultimate Debouncer(tm)!”
Everybody who works with microcontrollers eventually runs into the issue of switch bounce or “chatter”, and nearly everyone has their own favorite solution. Some fix it in hardware, others fix it in software. Some hackers understand chatter, and others just cut-and-paste the classic routines. Some folks even try to ignore it, and they might even get lucky, but everyone’s luck runs out sometimes.
In the next two “Embed with Elliot” installments, I’ll look a little bit at bouncing, look into doing hardware debouncing both the simple way and the right way, and build up a basic software routine that demonstrates some of the principles and which works just fine, though it’s not optimized. We’ll be laying the groundwork.
In the next installment, I’ll let you in on my personal favorite debounce routine. It’s a minor tweak on a standard, but with some special sauce that’s worth spreading around. I’ll call it the Ultimate Debouncer(tm), but will it stand up to the scrutiny of the Hackaday commenteers? (How’s that for a cliffhanger?!?)
For now, though, let’s look into switch bounce and the standard ways to fix it in hardware and software.
Last month we asked you to send in your debounce code. You didn’t disappoint and it’s time to share the code received. There were some guideline for sending in code so if you don’t see yours here, it probably didn’t follow the rules, sorry. We also tried to weed out code that using delay loops for debounce. These tend to be a poor way to handle inputs because they monopolize the processor.
We wanted to add upvote/downvote buttons to each set of code to give some idea of a group consensus on code quality but there’s no good system available for multiple up/down vote widgets on one wordpress page. This results in a huge code dump for any one person to go through. If you’ve got any ideas on how to better organize this let us know: email@example.com.
We make no guarantees that this code is safe to use, or that it even works. Test it carefully before using for important tasks.
Join us after the break for a whirlwind of code examples.
If you’ve ever designed an embedded system with at least one button you’ve had to deal with button debouncing. This is also know as contact bounce, a phenomenon where a button press can be registered as multiple button presses if not handled correctly. One way to take care of this is with a hardware filter built from a resistor-capacitor setup, or by using a couple of NAND gates. We find that [Jack Ganssle] put together the most comprehensive and approachable look at contact bounce which you should read through if you want to learn more.
We’re interested in software solutions for debouncing buttons. This seems to be one of the most common forum questions but it can be hard to find answers in the form of reliable code examples. Do you have debounce code that you depend on in every application? Are you willing to share it with the world? We’d like to gather as many examples as possible and publish them in one-post-to-rule-them-all.
There is an old saying: “In theory, theory and practice are the same. In practice, they are not.” We spend our time drawing on paper or a computer screen, perfect wires, ideal resistors, and flawless waveforms. Alas, the real world is not so kind. Components have all kinds of nasty parasitic effects and no signal looks like it does in the pages of a text book.
Consider the following problem. You have a sine wave input coming in that varies between 0 V and 5 V. You want to convert it to a square wave that is high when the sine wave is over 2.5 V. Simple, right? You could use a CMOS logic gate or a comparator. In theory…
The problem is, the sine wave isn’t perfect. And the other components will have little issues. If you’ve ever tried this in real life, you’ll find that when the sine wave is right at the 2.5 V mark the output will probably swing back and forth before it settles down. This is exacerbated by any noise or stretching in the sine wave. You will wind up with something like this:
Notice how the edges of the square wave are a bit fat? That’s the output switching rapidly back and forth right at the comparator’s threshold.
The answer is to not set the threshold at 2.5 V, or any other single value. Instead, impose a range outside of which it will switch, switching low when it leaves the low end of the range, and high when it exceeds the high end. That is, you want to introduce hysteresis. For example, if the 0 to 1 shift occurs at, say, 1.9 V and the 1 to 0 switch is at 0.5 V, you’ll get a clean signal because once a 0 to 1 transition happens at 1.9 V, it’ll take a lot of noise to flip it all the way back below 0.5 V.
You see the same effect in temperature controllers, for example. If you have a heater and a thermal probe, you can’t easily set a 100 degree set point by turning the heater off right away when you reach 100 and then back on again at 99.9999. You will usually use hysteresis in this case, too (if not something more sophisticated like a PID). You might turn the heater off at 99 degrees and back on again at 95 degrees, for example. Indeed, your thermostat at home is a prime example of a system with hysteresis — it has a dead-band of a few degrees so that it’s not constantly turning itself on and off.
Schmitt Triggers and How to Get One
A Schmitt Trigger is basically a comparator with hysteresis. Instead of comparing the incoming voltage with VCC / 2, as a simple comparator would, it incorporates a dead band to ensure that logic-level transitions occur only once even in the presence of a noisy input signal.
Assuming you want a Schmitt trigger in a circuit, you have plenty of options. There are ICs like the 74HC14 that include six (inverting) Schmitt triggers. On a schematic, each gate is represented by one of the symbols to the right; the little mark in the box is the hysteresis curve, and the little bubble on the output indicates logical negation when it’s an inverter.
You can also make them yourself out of transistors or even a 555 chip. But the easiest way by far is to introduce some feedback into a plain op amp comparator circuit.
Below are two op amps, one with some positive feedback to make it act like a Schmitt trigger. The other is just a plain comparator. You can simulate the design online.
If you haven’t analyzed many op amp circuits, this is a good one to try. First, imagine an op amp has the following characteristics:
The inputs are totally open.
The output will do whatever it takes to make the inputs voltages the same, up to the power supply rails.
Neither of these are totally true (theory vs. practice, again), but they are close enough.
The comparator on the right doesn’t load the inputs at all, because the input pins are open circuit, and the output swings to either 0 V or 5 V to try, unsuccessfully, to make the inputs match. It can’t change the inputs because there is no feedback, but it does make a fine comparator. The voltage divider on the + pin provides a reference voltage. Anything under that voltage will swing the output one way. Over the voltage will swing it the other way. If the voltages are exactly the same? That’s one reason you need hysteresis.
The comparator’s voltage divider sets the + pin to 1/2 the supply voltage (2.5 V). Look at the Schmitt trigger (on top). If the output goes between 0 V and 5 V, then the voltage divider winds up with either the top or bottom resistor in parallel with the 10K feedback resistor. That is, the feedback resistor will either be connected to 5 V or ground.
Of course, two 10K resistors in parallel will effectively be 5K. So the voltage divider will be either 5000/15000 (1/3) or 10000/15000 (2/3) depending on the state of the output. Given the 5 V input to the divider, the threshold will be 5/3 V (1.67 V) or 10/3 V (3.33 V). You can, of course, alter the thresholds by changing the resistor values appropriately.
Schmitt triggers are used in many applications where a noisy signal requires squaring up. Noisy sensors, like an IR sensor for example, can benefit from a Schmitt trigger. In addition, the defined output for all voltage ranges makes it handy when you are trying to “read” a capacitor being charged and discharged. You can use that principle to make a Schmitt trigger into an oscillator or use it to debounce switches.
If you want to see a practical project that uses a 555-based Schmitt, check out this light sensor. The Schmitt trigger is just one tool used to fight the imprecision of the real world and real components. Indeed, they’re nearly essential any time you want to directly convert an analog signal into a one-bit, on-off digital representation.
The Intel 8085 microprocessor was introduced 40 years back, and along with its contemporaries — the Z80 and the 6502 — is pretty much a dinosaur in terms of microprocessor history. But that doesn’t stop it from still being included in the syllabus for computer engineering students in many parts of the world. The reason why a 40 year old microprocessor is still covered in computer architecture text books instead of computer history is a bit convoluted. But there’s a whole industry that thrives on the requirements of college laboratories and students requiring “8085 Microprocessor Training Kits”. [TisteAndii] just finished college in Nigeria, where these kits are not locally built and need to be imported, usually costing well over a 100 dollars.
Which is why his final year project was a low cost Intel 8085 Microprocessor Trainer. It’s a minimalist design with some basic read/write memory, program execution and register inspection, with no provision for single stepping or interrupts yet. The monitor program isn’t loaded in an EEPROM. Instead, a PIC18 is used and connected to the 8085 address, data and control pins. This makes it easier to write a monitor program in C instead of assembly. And allows use of a 1.8″ LCD with SPI interface instead of the more usual 7-segment displays used for these kind of kits. [TisteAndii] built a 6×4 keyboard for input, but couldn’t solve debounce issues and finally settled on a 5×4 membrane keypad.
Being a rookie, he ended up with a major flaw in his board layout — he missed connecting the SRAM and the PPI devices to the data bus. A bunch of jumper links seemed to solve the issue, but it wasn’t perfect. This, and a few other problems gave him a lot of grief, but towards the end, it all worked, almost. Most importantly, his BoM cost of about $35 makes it significantly cheaper compared to the commercial units available in Nigeria.
While some hackers may consider this a trivial project, it solves a local problem and we hope the next iteration of the design improves the kit and makes it more accessible.
Rotary encoders are great devices. Monitoring just a few pins you can easily and quickly read in rotation and direction of a user input (as well as many other applications). But as with anything, there are caveats. I recently had the chance to dive into some of the benefits and drawbacks of rotary encoders and how to work with them.
I often work with students on different levels of electronic projects. One student project needed a rotary encoder. These come in mechanical and optical variants. In a way, they are very simple devices. In another way, they have some complex nuances. The target board was an ST Nucleo. This particular board has a small ARM processor and can use mbed environment for development and programming. The board itself can take Arduino daughter boards and have additional pins for ST morpho boards (whatever those are).
The mbed system is the ARM’s answer to Arduino. A web-based IDE lets you write C++ code with tons of support libraries. The board looks like a USB drive, so you download the program to this ersatz drive, and the board is programmed. I posted an intro to mbed awhile back with a similar board, so if you want a refresher on that, you might like to read that first.
Reading the Encoder
The encoder we had was on a little PCB that you get when you buy one of those Chinese Arduino 37 sensor kits. (By the way, if you are looking for documentation on those kinds of boards, look here.; in particular, this was a KY-040 module.) The board has power and ground pins, along with three pins. One of the pins is a switch closure to ground when you depress the shaft of the encoder. The other two encode the direction and speed of the shaft rotation. There are three pull-up resistors, one for each output.
I expected to explain how the device worked, and then assist in writing some code with a good example of having to debounce, use pin change interrupts, and obviously throw in some other arcane lore. Turns out that was wholly unnecessary. Well… sort of.