Other Parts Discussed in Thread: TLC5947, TLC59581, TLC5955, TLC5957, TLC5958, TLC59582, TLC59731
I am working on building a solution for controlling a few hundred RGB LED Pixels using only a SPI port (data out, data in, clk, and CS). I have full control of CS as a GPIO pin, so I can control it as a chip select, a data latch, output enable, etc. My microcontroller will be on a separate board from my LED pixels.
I think the TLC5951 will work. The datasheet indicates that dot correction data (which I don't expect to need) can be written through the grayscale data input. I won't be able to transmit a grayscale clock from my microcontroller, that will have to be generated locally at the LED driver. So I'm thinking that I just put a clock IC on the LED board and drive all three GSCLKs with it. Is there anything I'm overlooking as to why this shouldn't be done?
I can use my CS signal for the data latch since I have full GPIO control of this signal. I will NOT have control of the BLANK signal. The datasheet states:
For this reason,data should only be latched when XBLNK is low. If data are latched with XBLNK high, the outputs may turn on or off unexpectedly.
Am I correct in thinking that this shouldn't be an issue in most use cases? I'm not trying to synchronize the lighting to high speed cameras or anything, I just want it to look nice to the human eye (and hopefully Android/iPhone cameras). I assume that this simply means the outputs are updated immediately and appropriately for the new grayscale data register (GSDR) vs the grayscale clock (GSCLK) value. In other words, if outputs are currently off because the GSDR is 10 and the GSCLK is 50 and I latch 70 into GSCLK, the output will turn on for 20 more clock cycles and then turn off. Is this accurate? I hesitate because TLC5947 doesn't behave in this fashion. It turns the outputs off until the GSCLK rolls over or until BLANK is pulsed. This causes noticeable flickering.
TLC59581 looks, at a glance, like an appropriate device. It seems to have internal memory to support multiplexing LEDs. However, it has a max sink current of 25mA. Multiplexing will divide that current among each of the channels, and I need to drive my LEDs at 20mA. I think I would also need an FPGA locally near the driver(s) to support switching the multiplexing lines synchronized with the grayscale clock rolling over which drives the cost back up. Without multiplexing, it might be a marginally cheaper solution than the TLC5951.