Embed With Elliot: Debounce Your Noisy Buttons, Part II

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.

Continue reading “Embed With Elliot: Debounce Your Noisy Buttons, Part II”

Embed With Elliot: Debounce Your Noisy Buttons, Part I

“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.

Continue reading “Embed With Elliot: Debounce Your Noisy Buttons, Part I”

Debounce Code – One Post To Rule Them All

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: debounce@hackaday.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.

Continue reading “Debounce Code – One Post To Rule Them All”

Open Call: Send Us Your Debounce Code

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.

Send your debounce code to: debounce@hackaday.com

Here’s some guidelines to follow:

  • Please only include debounce code. Get rid of other unrelated functions/etc.
  • You should send C code. If you want to also send an assembly code version that’s fine, but it must be supplementary to the C code.
  • Please comment your code. This will help others understand and use it. You may be tempted to explain the code in your email but this info is best placed in the code comments
  • Cite your sources. If you adapted this code from someone else’s please include a note about that in the code comments.

As an example we’ve included one of our favorite sets of debounce code after the break. Please note how it follows the guidelines listed above.

Continue reading “Open Call: Send Us Your Debounce Code”

Illustrated Kristina with an IBM Model M keyboard floating between her hands.

Keebin’ With Kristina: The One With All The LEGO

It seems like mechanical keyboard enthusiasts are more spoiled for choice with each passing day. But as broad as the open source pool has become, there’s still no perfect keyboard for everyone. So, as people innovate toward their own personal endgame peripherals and make them open source, the pool just grows and grows.

Image by [Bo Yao] via Hackaday.IO
This beautiful addition to the glittering pool — [Bo Yao]’s Carpenter Tau keyboard — is meant to provide an elegant option at a particular intersection where no keyboards currently exist — the holy trinity of open source, programmable, and tri-mode connectivity: wired, Bluetooth, and 2.4 GHz.

Come for the lovely wooden everything, and stay for the in-depth logs as [Bo Yao] introduces the project and its roots, reviews various options for the controller, discusses the manufacture of the wooden parts, and creates the schematic for the 61-key version. Don’t want to build one yourself? It’ll be on Crowd Supply soon enough.

Continue reading “Keebin’ With Kristina: The One With All The LEGO”

Nyan Keys: Because Your Keyboard Is Painfully Slow

You probably don’t notice keyboard latency when typing or doing mundane tasks, but if you start gaming, that’s also when you might start complaining. Every millisecond counts in that arena. Think your keyboard is fast? Think again. Because unfortunately, no matter what you’ve got in there, that key matrix is slowing you down. What you need is an FPGA-based keyboard with an overkill MCU. You need Nyan Keys.

[Portland.HODL] set out to make the lowest-latency mechanical keyboard possible that would accept any Cherry-compatible switches, and boy howdy, is this thing fast.

Coupled with the STM32F723VET6 MCU is USB 2.0 HS, which has an 8000Hz polling rate. At worst, key latency measures 30μS, which blows the 1mS average out of the water.

Because it uses a Lattice Semi iCE40HX 4k FPGA, each key switch can connect to its own I/O pin, which also eliminates the need for diodes.

It also means that each key switch can have its own “core” — an 8-bit timer that is always counting up to 255. The key can only change its state when the timer reads 255. This acts as a rather clever debounce mechanism.

If all that’s not enough, [Portland.HODL] built an operating system called NyanOS written in C to avoid any performance-reducing overhead. Oh, and it has an opt-in Bitcoin miner.

We’ve seen a lot of keyboards, the fast ones are fast because of the input side — they are chording keyboards that take combinations to type, rather than using one key (or so) per character. The Characorder is so fast that it was banned from competition.

Debouncing For Fun And… Mostly, Just For Fun

In our minds and our computer screens, we live in an ideal world. Wires don’t have any resistance, capacitors don’t leak, and switches instantly make connections and break them. The truth is, though, in the real world, none of those things are true. If you have a switch connected to a lightbulb, the little glitches when you switch are going to be hard to notice. Hook that same switch up to a processor that is sampling it constantly, and you will have problems. This is the classic bane of designing microcontroller circuits and is called switch bounce. [Dr. Volt] covers seven different ways of dealing with it in a video that you can see below.

While you tend to think of the problem when you are dealing with pushbuttons or other kinds of switches for humans, the truth is the same thing occurs anywhere you have a switch contact, like in a sensor, a mechanical rotary encoder, or even relay contacts. You can deal with the problem in hardware, software, or both.

Continue reading “Debouncing For Fun And… Mostly, Just For Fun”