Here is a picture of the breadboard prototype
 |
| faerii breadboard prototype |
The ATtiny85 is mid centre, and immediately above it is the ISP header. To the left of the ISP header, near the centre, is a 4 pin header that provides USB connectivity. Obscuring it is two filter capacitors, pull resistors, and zener diodes. Finally on the far left edge is a common-anode RGB LED.
Here is a video of it in operation:
The project is based around the hid-data example from vusb. The EEPROM contains control blocks, consisting of 4 bytes. The first 3 bytes specify the red, green and blue intensities, in that order. The last byte specifies a duration. Upon reading a control block, the LED transitions, over the specified duration, from its current colour to the new colour. Currently the duration specified in multiples of 20ms.
Lists of control blocks, which I call a control sequence, can be delimited using delimiter blocks. These blocks have a specified duration value of 0xff. When such a block is encountered, the sequence is restarted from the beginning. Multiple sequences can be programmed into EEPROM.
The host software performs the job of programming sequences into EEPROM. It also provides additional commands, such as RESET and GOTO. The latter allows a collection of sequences to be stored in EEPROM, and activated individually. This feature was provided to minimise the amount of EEPROM writes required to change patterns. For example, sequences might be stored for an idle and new mail state. Activation then simply requires sending the correct GOTO command, without rewriting the EEPROM which as a limited write/erase cycle.
Currently a total of 62 control blocks can be stored. This is due to incomplete support for writing to arbitrary EEPROM address, and the fact the first block is reserved. It should be no great difficulty to fix this.
Two major features I have no implemented yet are REVERSE and MODIFY-ON-READ. These are animation options, where REVERSE specifies that upon reaching the end of a sequence, instead of starting again from the beginning, control blocks should be read backwards. MODIFY-ON-READ is more interesting. The intention is that after reading and executing a control block, the block's RGB values should be modified. This allows free-running random colour cycling without explicit programming.
The firmware and commandline utility source code is hosted at github. I will add proper schematics next weekend, though you can probably figure most of it by googling and looking at the photo above.
Cheers,Steve