While looking for something to do with my 3.5″ Insignia Infocast, I came across this post about some controllable RGB Christmas lights: http://www.deepdarc.com/2010/11/27/hacking-christmas-lights/
WiFi-enabled Christmas lights seemed like a good way to test out a variety of things, and hopefully something to show to family members who don’t quite get what I do for work and play (while I’m not sure that WiFi Christmas lights is the best example for this, it fit the season). The result didn’t see any use during Christmas, unfortunately…setting up a Linux machine on a wireless network via the command line is not as straightforward as I’d hoped, so it never got hooked up at my family’s place. I never got around to coding any lighting programs, so only the most basic functionality is actually implemented and tested. But those basics are there: a CGI program that runs on the Infocast (which is essentially a Chumby One, with a 454 MHz ARM processor, 64 MB of RAM, and a WiFi dongle), displaying a web page and sending I2C commands to an AVR Xmega board, which itself is loaded with firmware that communicates with the LED string. A hex inverter is used as a 5V driver for the LED string communications line, and to provide some measure of protection should mishaps occur while wiring things up.
The Infocast main board plugs neatly into a solderless breadboard with the addition of a couple right angle headers to the “mod port”. I used single-row headers on both sides of the board, the header on one side soldered in “backwards” and extended with a straight header to get the needed length and spacing. The result worked quite well:
The lights themselves have simply been modified to remove the original remote control receiver, replacing it with a bit of ribbon cable and a header connector for plugging into a solderless breadboard. This is not ideal…if the connector pulls out of the breadboard, I’ve got exposed pins with 5VDC and fairly high maximum current flailing around near my largely-3.3V Infocast and AVR. It’s far more secure than the first approach, which had the connectors attached straight to the thick, unwieldy light string cables, though:
The long green jumpers are the I2C lines, the small DIP IC is a hex inverter powered off the 5.6 V from the lights and driving the LED comm line. There’s a FTDI USB-serial module that takes up entirely too much board space, but gives a serial console into the Infocast/Chumby One board. The black box underneath is the case and power supply for a dead Ethernet switch, adapted as a base for the protoboards. (someday, I’ll stuff one of the USB-serial modules into that box as well and free up some board space)
The Xmega32A4 board is one of my own design, made with Eagle, boards done by Seeed Studio, and put together with a Home Depot heat gun. A good part of the goal with this project was simply to get an Xmega talking with the embedded Linux devices via I2C, as a general purpose controller/data acquisition peripheral. This turned out to be quite trouble-free, once I figured out that my I2C addresses needed to be shifted by one bit on the Linux side (for those unfamiliar with I2C, some things consider I2C addresses to be 8 bits with the LSB a read/write flag, others consider them to simply be 7-bit addresses with the flag considered separately).
Due to various delays with the toolchain (do not run Bingo’s toolchain build scripts from avrfreaks.net, they have an entertaining failure mode in which they crawl up your directory tree executing “rm -fr *” as they go, and the script maintainers refuse to recognize this as a significant problem…fortunately I was able to restore from a recent Time Machine backup, and am now using an old toolchain until I can build a newer one that works), wireless configuration, and general lack of time, the code is nowhere near a finished product, but here it is in all its hodge-podge, undocumented glory: