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: firstname.lastname@example.org.
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.
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”
Microcontrollers existed before the Arduino, and a device that anyone could program and blink an LED existed before the first Maker Faire. This might come as a surprise to some, but for others PICs and 68HC11s will remain as the first popular microcontrollers, found in everything from toys to microwave ovens.
Arduino can’t even claim its prominence as the first user-friendly microcontroller development board. This title goes to the humble Basic Stamp, a four-component board that was introduced in the early 1990s. I recently managed to get my hands on an original Basic Stamp kit. This is the teardown and introduction to the first user friendly microcontroller development boards. Consider it a walk down memory lane, showing us how far the hobbyist electronics market has come in the past twenty year, and also an insight in how far we have left to go.
Continue reading “Before Arduino There was Basic Stamp: A Classic Teardown”
Morse code used to be widely used around the globe. Before voice transmissions were possible over radio, Morse code was all the rage. Nowadays, it’s been replaced with more sophisticated technologies that allow us to transmit voice, or data much faster and more efficiently. You don’t even need to know Morse code to get an amateur radio license any more. That doesn’t mean that Morse code is dead, though. There are still plenty of hobbyists out there practicing for the fun of it.
[Dan] decided to take a shortcut and use some modern technology to make it easier to translate Morse code back into readable text. His project log is a good example of the natural progression we all make when we are learning something new. He started out with an Arduino and a simple microphone. He wrote a basic sketch to read the input from the microphone and output the perceived volume over a Serial monitor as a series of asterisks. The more asterisks, the louder the signal. He calibrated the system so that a quiet room would read zero.
He found that while this worked, the Arduino was so fast that it detected very short pulses that the human ear could not detect. This would throw off his readings and needed to be smoothed out. If you are familiar with button debouncing then you get the idea. He ended up just averaging a few samples at a time, which worked out nicely.
The next iteration of the software added the ability to detect each legitimate beep from the Morse code signal. He cleared away anything too short. The result was a series of long and short chains of asterisks, representing long or short beeps. The third iteration translated these chains into dots and dashes. This version could also detect longer pauses between words to make things more readable.
Finally, [Dan] added a sort of lookup table to translate the dots and dashes back into ASCII characters. Now he can rest easy while the Arduino does all of the hard work. If you’re wondering why anyone would want to learn Morse code these days, it’s still a very simple way for humans to communicate long distances without the aid of a computer.
The Progressive Snapshot is a small device that plugs into the ODB-II port on your car, figures out how terrible of a driver you are, and sends that data to Progressive servers so a discount (or increase) can be applied to your car insurance policy. [Jared] wondered what was inside this little device, so he did a teardown. There’s an Atmel ARM in there along with a SIM card. Anyone else want to have a go at reverse engineering this thing from a few pictures?
[Alex]’s dad received a special gift for his company’s 50th anniversary – a Zippo Ziplight. Basically, its a flashlight stuffed into the metal Zippo lighter we all know and love. The problem is, it’s battery-powered, and Zippo doesn’t make them any more. It also uses AAAA batteries. Yes, four As. No problem, because you can take apart a 9V and get six of them.
‘Tis the season to decorate things, I guess, and here’s a Hackaday snowflake. That’s from [Benjamin Gray], someone who really knows his way around a laser cutter.
HHaviing trouble wiith a debounce ciircut? HHer’s a calculator for just thhat problem. Put iin the logiic hhiigh voltage level, the bounce tiime, and the fiinal voltage, and you get the capaciitor value and resiistor value.
A harmonograph is a device that puts a pen on a pendulum, drawing out complex curves that even a spirograph would find impressive. [Matt] wanted to make some harmonographs, but a CNC and a printing press got in the way. He’s actually making some interesting prints that would be difficult if not impossible to make with a traditional harmonograph – [Matt] can control the depth and width of the cut, making for some interesting patterns.
The Mooltipass, the Developed On Hackaday offline password keeper, has had an interesting crowdfunding campaign and now it’s completely funded. The person who tipped it over was [Shad Van Den Hul]. Go him. There’s still two days left in the campaign, so now’s the time if you want one.
[JP] was looking for a bicycle light to do some night biking around his home. He found a reasonably priced light that suited his needs, but when he started using it he found that the controller was a little lackluster. To solve some of its problems, he ended up building his own lighting controller from scratch.
The original controller’s main problem was that the it didn’t debounce the input from the single pushbutton. This meant that a single press of the button might cause it to cycle through two or three different modes, which was inconvenient and annoying. The new controller took care of this along with implementing several new brightness modes and a “strobe” mode for commuting to work to help alert other drivers of [JP]’s presence on his bicycle.
While [JP] notes that an Arduino would have been very easy to use in this situation, it wouldn’t have fit in the original enclosure. He went with an 8-pin ATtiny45, which was perfectly sized for what he needed. Everything fit together perfectly and is much more useful than the original. Maybe next he could pair it with a light that is even brighter than the one he’s currently using.
Let’s face it, we all have keyboard peculiarities. Don’t try to deny it, everyone who types a lot has an opinion of the keyboard they stroke so frequently. We know [Brian Benchoff] swears by his model M, and we’re guessing he was the one that bumped into [Evan] and convinced him to write about his conversion of a Commodore 64 keyboard for use as a USB device.
This is not [Evan’s] first rodeo. We recently saw him fixing up the worn off letters of his own model M. But this time around there’s some clever microcontroller work at play. Apparently mapping 122 keys using an Atmel AVR 32u4 chip (built in USB connectivity) is quite a task. Luckily someone’s already worked out all kinds of good things and is sharing the love with the Soarer’s Keyboard Controller Firmware. Of course it handles scanning, but also includes debounce, muxing, and the trick to scan more keys than the uC has pins for. We still don’t fully understand that bit of it. But [Evan] did post the config file he’s using so perhaps after we get elbow-deep in the code we’ll have a better understanding.
If you give this a try, we want to hear about it. Anyone have any modern keyboards they’re in love with? Leave a comment below.