We need an inexpensive LED driver IC that:
- Can source or sink at least 15mA/LED
- Has an SPI-like interface (not I2C)
- Has a separate latch pin
- Has at least 256 grayscale intensities
- Preferably at least 8 channels/chip
Can anyone recommend some devices to consider? I think multiplexed/charlieplexed devices will not work for this project, but I am open to opposing viewpoints.
Why the project needs this
We are looking to drive 120 RGB leds (320 total channels) in a persistence of vision display. The nature of this device (bicycle-spoke mounted) means that to get the "horizontal" resolution (along the wheel circumference) of 10mm/virtual pixel we need to be able to load a full "column" of pixels (a radius) at 0.746 mS. The latch line is to ensure that the entire column will turn on at once, rather than one-by-one. 1Mhz I2C ends up being slower than SPI: using ATmega chips running at 20Mhz, the SPI subsystem can load 24 16-channel drivers in roughly the needed time (at 12-bits/channel). I2C at 1Mhz and 8/bits/channel (zero overhead) can program 320 channels in 2.56mS or more than 3x the time. Given the architecture of the system, we would really prefer to stay with a single core processor for ease of control and communication.
TLC5940 We've used TLC5940 (which can be had on Ebay in quantities for about $1/piece) successfully timing-wise. These drivers can officially sink up to 120mA/chip, meaning 7.5mA/channel (8mA if only 15 channels are used). We are considering overdriving the TLC5940s to reach 15mA/channel (225mA/chip peak), however, this seems unsafe. Is it? Are there ways to overcurrent the LED driver in a more safe manner? The TLC5940 can signal thermal error on one of its pins. The project is expected to be deployed in the environment of high air velocity: heat dissipation isn't expected to be a problem.
75HC595 We have also tried using 74HC595 shift register for this. This has two problems. One is that 74HC595 can only source 8.75mA/channel if all channels are one. The second one is that using a PWM LEDdriver, we need to get 0.746 mS/update because each horizontal "pixel" lasts 0.75 mS. Manual PWMing means that for N linear greyscale levels we would have to update each shift register N times / 0.75 mS, which quickly becomes unwieldy once you realize that brightness is perceive exponentially.