2009-12-20
19 LED Animated Christmas Star
As promised, now that I have largely finished the Christmas Star I am documenting it for those that have emailed me for the details.
Hardware
The hardware is quite similar to the Christmas Tree except 19 of the possible 20 drive vectors of the K5 charliplexing topology are used. The drive board is identical, except I am using the pin-compatible but more resourced Atmel ATtiny45 to fit the more sophisticated software.
Construction began with designing the star and LED layout. While a fairly simple geometrical problem to construct with compass and straight-edge I decided to use software to render a cutting template for accuracy and repeatability. Some postscript was written to render both the star outline and place the 19 holes for the LEDs. Using postscript allowed many variations to be assessed before the final 6-pointed star was settled upon. The resulting full-size template image was printed out and tacked (in waste places) with some paper adhesive to the dense "art board" cardstock used selected as the basic substrate of construction.
The 5 mm LED holes were then punched out using the partner's eyelet punch and the outline cut carefully with a craft knife and steel rule. The punching was easy and very clean compared to drilling, like the Dekatron emulator I was very pleased with the result. The border cutting was a bit more difficult as significant care and a large amount of cutting pressure (in several passes) was required because of the thickness and density of the cardboard.
Next the 19 bright white defused LEDs were inserted, paired up and soldered together in reverse-parallel pairs.
Each was numbered and the charlieplexing scheme topology translated into a corresponding wiring list that was all soldered up using 200 um copper wire with the wiring pencil.
The five trailing wires were twisted into a bundle and terminated (arbitrarily) in a 5 pin fragment of IC socket as a plug.
Similarly to the Tree project, the drive-line to LED mappings were recovered by injecting a current-limited signal into each of the 20 possible pin pairings and polarities. A table was constructed and put into the firmware indexed by LED identifier. The 0 is the centre LED, they then number spiralling out anti-clockwise starting from the top inner most LED. The 20th drive vector is unused, but I did toy with the idea of making the centre LED a reverse-parallel bi-colour device - I decided against it as the brightness of the available devices was significantly poorer and the pure white star is more aesthetically pleasing.
Finishing touches to the hardware were added later, including attaching a 4xAAA cell holder and the MCU board to the back of the star using double-sided foam tape "dots" (from the partner's craft supplies), and placing a slide-action power switch with some hot-melt glue. Finally a cone was rolled from overhead transparency (to mate with my fibre-optic Christmas tree) and socketed onto the star back using a small piece of plastic tube and a ring of hookup wire held in place with hot-melt glue. This socket system enables the cone and star to be easily separated.
Software
The software builds upon the Christmas Tree prototype, but controls more LEDs and adds the ability to execute byte-coded animation logic at a variable rate rather than just cycling through a simple list of states. The charlieplexing routine and control vector encoding is identical to the tree (but uses a 32 bit state vector instead of a 16 bit one because of the larger number of LEDs) and simply runs as fast as possible.
The display state transitions are handled by a ~30.5 Hz timer interrupt that sets a global flag (after an adjustable number of interrupts). When the global flag is set the byte-code interpreter is called from the charlieplexing loop. The interpreter can change the display state or perform other tasks before surrendering the CPU back to the charlieplexing (until the next timer interrupt) - it can however reset the global flag and cause itself to be recalled immediately to execute multiple instructions before allowing the display multiplexing to continue.
In addition to "immediate" style display vector assignment and individual LED set/unsets, the instruction set includes operations to change the display rate, set state from a pseudo-random source, perform display geometry specific rotations, or execute loops.
Originally the program just fit in the Atmel ATtiny13's 1k of FLASH and 64 byte RAM, but when the rotate operations were added and additional state needed for the looping constructs there was insufficient room available so I was forced to upgrade to the ATtiny45. The increase in resources allowed the addition of the random number generation routines, which vastly improves the display options available. It is likely possible to squeeze the bytecode interpreter into the tiny13 by using ASM exclusively, but the C-level programming is much more expedient.
As usual the software is taking much longer to perfect than the hardware. The Star is in place on the Christmas tree, but improvement ideas continue. Effort is under way to back-port the new byte-code interpreter features to the Tree code. The Tree with its 16 bit display state may permit an abridged version of code to fit in a tiny13. Alternatively a PC hosted interpreter could generate the state list for the original firmware from the more compact and easily used format. The rotate operations specific to the display geometry are much easier to work with than hand-computing the next state. I have already sketched an improved byte-code instruction set for devices like the tree that have just 16 bit display vectors - which allows compression of many immediate values into a nibble of the byte-code itself. Generic mask-and-rotate maps could be used in other geometries, leading into my other desire to make a PC-hosted tool for program design assistance. Pushing the 8-pin devices to their 6-line, 30-LED limit is also a natural progression, but before I do that I need to make my HV-programmer a more permanent circuit (it still sits on a breadboard).
4 comments.