Putting On My Hardware Hat

Recently, my son became interested in LED sneakers, so I pondered making something similar for him, which would be a good opportunity to explore the LilyPad textile friendly Arduino platform. I didn't like the odds of building something robust enough to survive in a shoe, and LilyPads are not all that small, so I decided on building a LED hat (with temperature sensitive LED patterns, to make it interesting).

Materials

Boxtec carries a reasonable selection of LilyPad compatible boards to get started. In particular the ProtoSnap LilyPad development board contains all the electronics used in this project, except for the colored LEDs, and also comes with a 110mAh LiPo battery, the conductive thread needed to connect everything, and an FTDI board for the USB connection (No separate charger for the battery is needed; the battery will charge when the LilyPad is connected to USB).

Pretty much any hat should be OK for this project; the one I picked turned out to be a bit on the small side for the customer, and picking a color so close to the color of the conductive thread was not as clever a decision as I had originally thought.

Layout

I started out by installing the LilyPad Simple processor board on the inside of the hat, at the very top, and a temperature sensor on the outside, at the top (The temperature sensor is not currently used, although I got it to work to some extent; more on this in a separate post).

The LEDs are arranged in two staggered rings of 4 LEDs each, red on top, and alternating blue/green on the bottom.

Sewing the Connections

This was the true challenge in this project. I may have learned a little bit of sewing as a child, but hadn't held a needle in more than 25 years. However, this Instructable on Sewing was quite helpful, and entirely sufficient to get the project done.

Initially, I started with a planned pin assignment for the LEDs, but it turned out to be easier in some cases to stitch a connection from whatever pin was closest to the LED I wanted to connect, and adapt the code to the physical layout, rather than the other way around. Since I was not using PWM, and only one analog input, most pins were largely interchangeable for my purposes.

Writing the Code

My plan was to run the red LEDs and the blue&green LEDs separately, so I could have one LED in each group lit. To save pins, I wired up the red LEDs using a Charlieplexing scheme using 3 pins. However, when testing the result, one of the LEDs would not work cleanly, with two of its neighbors lighting up as well. Despite testing all the connections for short circuits, I was unable to find the cause. I suspected that the high impedance state might not have worked as planned, due to the peculiarities of LilyPad connections.

To test this, I wired the blue/green LEDs using 4 pins, with a simpler multiplexing scheme that did not rely on tristate logic. Ultimately, though, the results were not much better, with one of the LEDs never lighting up. I probably would have been best off with a common cathode/anode, one pin per LED scheme, but for what it's worth, my code is here.

Tying up the Loose Ends

Having decided that my result was close enough to what I wanted to build, I installed the battery in place with some non-conductive thread.

(Visuals like this are why it may be inadvisable to take homemade electronics through airport security).

Finally, I wanted to cover up the LilyPad main board and the battery. Having the electronics in contact with someone's head seemed like a bad idea for the electronics, and the LilyPad has a rather prominent male 6 pin connector, which looked like an injury risk. A piece of black repair sheet, and some more non-conductive thread did the job reasonably well (with the opening of the stitching leaving enough space to insert the FTDI/USB board for reprogramming and recharging).

Customer Test

After some initial skepticism, my son decided that his hat was nearly as cool as a pair of LED sneakers:

Lessons Learned

• Working with conductive threat is the equivalent of building a circuit using non-insulated wires exclusively. It can be tricky to avoid short circuits.
• My idea of having most of the stitching run between the outer and inner layers of the hat made it even harder to find out what’s going on.
• It’s not clear whether the material of the hat might have been somewhat conductive itself.
• Redoing a stitched connection can be quite a bit more work than redoing a wire, especially since I tried to run a single thread through several destinations, instead of doing strictly point to point connections.
• That said, the stitching itself was not terribly difficult, as long as I was not overly fussy about the esthetics of the outcome.

Foca 2.1 as AVR ISP

Turning a Misunderstanding into Reality

Recently I started dabbling in ATtiny programming, and I became tired of tying up my Arduino UNO as an ISP, so I wanted a standalone ISP.

The Foca 2.1 board seemed to fit the bill. The product description mentioned it being a "Programmer for Arduino and compatible boards", and the data sheet showed a familiar looking 6 pin header in the "ISP Zone", so I bought the board from Boxtec.

Only when I started playing with the board did I realize that the 6 pin header simply was breaking out control pins for an RS232 serial interface, and that the "Arduino Programmer" was meant to program ATmegas with boot loaders through the serial port, not bare ATtinys through the SPI based in-system chip programming interface.

Enter Plan B

However, the FT232RL chip on the Foca board is very flexible, and supports a "Bitbang" mode, in which the data sent directly sets 8 control lines to arbitrary values, instead of being sent through a serial interface. Support for SPI based in-system chip programming was already in the avrdude SVN repository (though not in a release yet).

Dude, where's my AVR?

Checking out the latest version of avrdude from its SVN repository, I initially had little success getting the ftdi_syncbb method to work.

This turned out to be mainly due to the fact that OS X has linkable stubs for anonymous semaphore functions (sem_init, etc.), but actually returns errors from them. Code that does not check these functions for errors (like the ft245 code in avrdude) becomes wildly susceptible to race conditions. 

After fixing this problem, the code worked, but only at very slow bit rates (2400 or less). While better than nothing, this was rather disappointing performance, and at faster rates, scary things like reprogrammed fuses happened.

Faster, SPI! Kill! Kill!

A Technical Note from FTDI suggested a reason for my problems: The data in bitbang mode was written based on a clock that was not synchronized to the data clock, so signal pulse widths were not reliable. The suggested remedy was to pad out the data.

So I modified the writing code to write each data byte 4 times, and upon reading, only use every 4th byte (2x duplication helped as well, but beyond certain bit rates still failed). Despite having to write much more data for each bit (effectively 8 bytes per bit), thanks to the improved reliability, I now achieved data rates of more than 45000 bits per second, more than enough to program an ATtiny at blazing fast speeds.

Tweaking the Arduino IDE

Now that I had a working avrdude, all that I needed to do to get it working directly from the Arduino IDE was to copy the binary and the configuration file into the Arduino app, and to create a "programmer" entry in the hardware subfolder of my sketch folder.

Show me the code!

For those interested, the patches and detailed instructions are available in this archive.