acleone

The TLC5940 is a 16-channel, constant-current sink LED driver. Each channel has an individually adjustable 4096-step grayscale PWM brightness control and a 64-step, constant-current sink (no LED resistors needed!).

This library supports daisy-chaining multiple chips together. I haven't tried this library on anything but a Diecimila, so YMMV.

v001 - 08-08-08: Cleaned everything up a bit. Renamed stopPWM() to stopTimers() and made a resetTimers(). Added a setPWMuPeriod(uPeriod) for setting the PWM period in microseconds. Changed readXERR() to return 1 if there is an error (LED shorted/broken), 0 otherwise.[/size]

acleone

A bit more on how this library is using Timer1 and Timer2 to run GSCLK and BLANK:

The PWM on the TLC5940 works by counting the number of GSCLK pulses; a setting of 2048 will mean the LED stays on for 2048 pulses and then turns off for the rest of the cycle. After 4096 pulses, the counter needs to be reset by a pulse on BLANK. In the library, I'm using Timer2 to generate the GSCLK pulses and Timer1 to generate the BLANK pulse.

melka

acleone

I'm trying to fade multiple LEDs, independently, and at different rates. Is it possible to have the TLC5940 (or the arduino, for that matter) to run a series of "analogWrite" commands independently?

In other words, send one "fade channel0 from 4095 to 0 in 5000ms" and, before it's finished, send "fade channel1 from 0 to 4095 in 2500ms".

I know I could chain them together, so that as soon as channel0 finishes its fade, channel1 would begin...but that's not what I'm aiming for.

I'm writing some improvements this weekend that changes to the way the library handles the BLANK pulses, and I think it would be pretty easy to add fading too:1. When we pulse BLANK, check to see if any fades should happen, and calculate the PWM output2. set an "updated" flag or something to let the user know they should call updatePWMs(). <- I don't think you could call updatePWMs() in 1. because it would put too much code in an interrupt, breaking Serial and stuff

The changes I'm making to the way BLANK pulses:- Instead of outputting BLANK as a PWM on TIMER1, use TIMER1 to count GSCLK pulses and call an interrupt to pulse BLANK.

acleone

Your project sounds impressive - does that mean you'll be controlling 3x30 led outputs? are you going to need 6 TLC5940 to control the lot - or is it possible to multiplex the TLC5940 output pins?

I wasn't planning on multiplexing, so at least 6. I'm assuming that a single rotation of the wheel will have ~30 PWM periods, which means one image is (24 bytes per tlc)*(6 tlc's)*(30 periods) = 4.32KB. That comes out to ~231 frames per 1MB of SD card space.

Added fading functionality: Tlc.newFade(channel, ms duration, start value, end value, when to start). See the examples.

Added the ability to play animations from program memory (14kB!) . See the examples again.

See TLC5940LED.h for all the function name changes

I'll release a finished version soon which will include an animation creator to make animations.

This is excellent! I have a bunch of the TLC5940's here and have been wanting to tinker and see what I can do with them. One thing I want to do is use 3 of these for a 16 channel RGB LED controller. Thank you very much for making chips like the TLC5940 easier for us to use!

At 10mph you're getting about 2 revolutions per second. With a single spokepov, that's too flickery to be called a persistent image. You'll probably want three spokes, and that only gets you the equivalent of a 6Hz update. And then both sides...and then two wheels. That's a lot of TLC5940s. 72 of them, actually.

You might not be happy with the brightness control. It's PWM, which will be visible on a moving LED. If you can achieve a 5MHz grayscale clock, you get almost 10 full PWM cycles for each of the 256 radial slices. That might be enough to not confuse the image you're trying to generate.

I know a guy who makes POV displays that have variable brightness, and he's actually using a simple resistor DAC for 3 bit brightness control on each LED. This doesn't use pulses to vary the apparent brightness, so it doesn't disrupt the virtual pixels on the POV display.