When [Alain] wanted to use some of the new TinyAVR 0 chips — specifically, the Attiny406 — it seemed overkill to use the Windows IDE. There are plenty of sources of information on programming other AVR chips using simple command line tools, but not for these newer 0-series parts which use a new programming protocol known as UPDI. That led to a deep diving into how to program a TinyAVR 0 with a text editor, makefile, and USB-to-serial cable.
The Attiny406 has 4K of flash, 256 bytes of RAM and can run at 20 MHz with no external clock. You might think programming would be similar to a regular AVR part, but these tiny devices use UPDI (Unified Programming and Debug Interface) which uses 3 pins for programming. Older devices used different protocols.
It is very easy to create a UPDI programmer. A USB to logic-level serial cable and a 4.7K resistor is all it takes. There’s Python code that knows how to drive the protocol, too. You can also use the logic-level serial port on the Raspberry Pi with some device tree modifications explained in the code’s documentation.
[Alain] made a nice breakout board for the device. It fits a breadboard, allows for 5V or 3.3V operation, and has an LED and switch. Nothing fancy, but handy. Once you know how to ship a hex file to the chip, the rest is pretty standard. While the AVR version of gcc doesn’t cross-compile for the ATTiny out of the box, there is a device pack from Microchip that enables that feature.
The trend is to go to bigger processors, not smaller, but when you need to cram something in a small space, save a few pennies per unit, or draw very little power, these tiny processors can be just the ticket. The processors may be small, but if you work you can do some pretty big things with them.
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.