not sure about your measurements, they don't sound right. In general I would say that I have never seen a design for driving LEDs that does not use a resistor to limit current, other than connecting them straight to a current-limited source. Driving directly without current limiting is generally a bad idea. resistors are less than a cent each
I bought one of the tiRGBLED boards. Drives 10 seperate RGB LEDs via a straightforward interface that lets you identify colors, transitions, pacing plus lets you group individual LEDs together. Right now, I'm just driving it via a DB9 cable hooked up to my PC using hyperterminal; but my plan was to plug into the rgbled board's Peripheral Communications Interface so I can have an arduino device drive the lighting.
Anyone else working on this? Would like to have a collaborator on this especially on figuring out the PCI communications flags to get Arduino to speak to the rgbled board.
Shoot, kindof lost my mind there for a second. The rgbled systems use SPI (Serial Peripheral Interface) not PCI. Forget anything I said about PCI. Too many acronyms on my mind. :o
The rgbled project guy (Gerry Duprey) says the SPI interface settings should be:
Clock idle state is low (i.e. CPOL == 0)
Transmission happens on active-to-idle (i.e. CPHA == 1)
Byte order is MSb first
i'll need to do a some more experimentation on this. Once I get it working, I can report back on configuration settings for Arduino to make this work.
But I am not convinced of the approach of using an arduino to drive it. The RGBLED is basically a PIC uC driving two TI TLC5940s... so adding an arduino seems like a lot of duplication.
You can drive the TLC5940s (as many as you need, just $5 each) directly with one arduino, using the examples in the playground... it will give you a much more flexible and cheaper solution, as you can put whatever logic you want in it.