It turns out there’s a considerable amount of free space inside the Nunchuk case, so [Giliam] found adding in the new hardware wasn’t nearly as difficult as you might expect. Of course, it helps that the diminutive SMD ATtiny44A and its support hardware are housed on a very neatly milled PCB that attaches to the back of the original board.
Most of the other hardware comes in the form of modular components, like the Bluetooth transmitter and TP4056 charge controller for the 300 mAh battery. A micro USB charging port is mounted where the original Nunchuk cable entered the case, making the whole thing look very professional.
Even if you aren’t interested in making your own controller, [Giliam] covers many interesting topics in this write-up such as handling different methods of Bluetooth connectivity and various power management techniques to eke out as much life from the relatively small battery as possible. It’s not only a fascinating read, but a great example of what thorough project documentation should look like.
For the casual Monopoly or Risk player, using plain six-sided dice is probably fine. For other games you may need dice with much more than six sides, and if you really want to go overboard you can do what [John] did and build electronic dice with a random number generator if you really need to remove the pesky practice of rolling physical dice during your games of chance.
The “digital dice” he built are based on a multimeter from 1975 which has some hardware in it that was worth preserving, including a high quality set of nixie tubes. Nixies can be a little hard to come by these days, but are interesting pieces of hardware in their own right. [John] added some modern hardware to it as well, including an AVR microcontroller that handles the (pseudo) random number generation. A hardware switch tells the microcontroller how many sides the “die” to be emulated will need, and then a button generates the result of the roll.
This is a pretty great use for an old piece of hardware which would otherwise be obsolete by now. [John] considers this a “Resto-Mod” and the finish and quality of the build almost makes it look all original. It’s certainly a conversation piece at the D&D sessions he frequents.
[Andrew] had a servo damaged by someone connecting the power supply to the wrong pins (whoops) which fried the microcontroller and a logic level shifter. With a bit of reverse engineering, he successfully restored basic servo functionality by writing some new code. The new code implements only basic features, but that’s enough to save the device from the junk bin.
Why bother reverse engineering a servo? Well, if dollars are reasons then there are many for saving a HerkuleX DRS-0602 from the junk heap; they cost around 320 USD before shipping. Another reason to try is that the microcontroller turned out to be an AVR XMega, which gave [Andrew] confidence in writing some new code.
If you want to understand more about how these servos work, [Andrew] provides good photos of the insides and identifies the major components and their connections and functions. There are some mysteries (such as details of the motor and embedded encoder, which are FAULHABER 2232DBHHO) but [Andrew] figured out enough to write some basic code to allow the servo to work as a standard servo with a UART interface.
Most people have at least seen those cheap component testers you can buy on the Chinese websites for $10 or so. If you haven’t seen them before, they usually have some kind of multi pin socket. You put a component in the socket and it will identify — with a push of a button — what the part is, which pin is which, and the value of the part. For example, you can insert a resistor, a capacitor, an inductor, a diode, or a transistor and get a readout of which pin is which. It seems like magic, but [Andreas Spiess] did the research on how it all works and summed up his findings in a recent video.
[Andreas] even quotes our earlier post on the topic and, as we did, dug into the original developers of the device which has been cloned over and over by Chinese sellers. Although there have been some divergence with all the different versions, the basic idea is the same. An AVR CPU uses some analog and digital trickery to make a lot of different measurements.
But be warned, this isn’t the easy way to learn AVRs. Not content with simply stripping away every layer of abstraction, this month-long “course” in AVR assembly starts off programming the chip initially with just two pushbuttons in its native machine language of high and low voltages. But still, especially if you can get a few assignments done in one sitting, you’re writing in the relative splendor of assembly language and uploading code with a proper programmer before long, because there’s a real limit to how much code one can toggle in before going mad.
There’s a beautiful minimalism to this entirely ground-up approach, and maybe it’s an appropriate starting point for learning how the machine works at its lowest level. At any rate, you’ll be able to lord it over the Arduino crew that you were able to get blink.ino up and running with just a pair of mechanical contacts and a battery. Real programmers…
And once you’ve mastered AVR assembly language, you can recycle those two buttons to learn I2C or SPI. What other protocols are there that don’t have prohibitive timeouts? What’s the craziest code that you’ve ever entered bit by bit?
The interesting aspect of these chips is how they use registers to change the audio output. Essentially, there is a complicated register map (one section of his write-up is simply called “Register Hell”) that can be called in order to access the various types of effects one would normally see on a synthesizer. It’s not straightforward at all, though, and got even more complicated once [Aidan] started adding MIDI functionality to it as well. Once he finished sifting through the Sega Genesis technical manuals and a bunch of registers, though, he had a unique synthesizer working that doesn’t sound like anything you’ve ever heard, unless you’ve ever played a Genesis.
If you’d like to check out his first project, the MegaBlaster, which plays the sound files of the old Genesis games directly, we featured that a while ago. Keep in mind though that his latest project isn’t just an updated MegaBlaster, though. He built this entire thing from the ground up.
It’s entirely possible to do your coding in vim or emacs, hammering out hotkeys to drive the interface and bring your code to life. While working in such a way has its charms, it can be confronting to new coders, and that’s before even considering trying to understand command line compiler settings. The greenhorn coder may find themselves more at home in the warm embrace of an IDE, and [morrows_end] has now built one for those working with AVR assembly code.
The IDE goes by the name of Simple AVR IDE, or savr_ide for short. Programmed in C++ with the FLTK widget library, [morrows_end] has tested it on Windows XP, but notes that it should successfully compile for Linux, Unix, and even MacOS too.
All the basic features are there – there’s syntax highlighting, as well as integration with the AVRA assembler and AVRDUDE for programming chips. It’s a tool that could make taking the leap into assembly code just that little bit easier. For another taste of bare metal coding, check out [Ben Jojo]’s discussion of x86 bootloaders.