• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 351 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TLC5951: Controlling TLC5951 Without GSCLKs Synchronized to Data

Henry McDonald1
Prodigy 20 points
Part Number: TLC5951
Other Parts Discussed in Thread: TLC5947, TLC59581, TLC5948, 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.

  • 0
    TI__Genius 12915 points

    Hi Henry,

    I think it is not OK to set XBLNK continually high. One reason is that here are three GS counters are implemented and count the rising edge of GSCKx to control each of the three color outputs. The falling edge of XBLNK resets the three counter values to 0. The counters cannot be set to 0 by themselves. Another reason is to prevent the outputs from turning on when power on, since there are no default value in PWM control registers.

    TLC5948, TLC5955, TLC5957, TLC59581 or TLC694x are suitable for you case that only have 4 interface port. You can use them only in series like TLC5951 and not need to use matrix structure.

  • 0 in reply to Hardy Wu
    Prodigy 20 points

    Thank you for the response!

    > I think it is not OK to set XBLNK continually high. One reason is that here are three GS counters are implemented and count the rising edge of GSCKx to control each of the three color outputs. The falling edge of XBLNK resets the three counter values to 0. The counters cannot be set to 0 by themselves.

    I don't think that this is accurate. In the TLC5951 datasheet, figure 41 has this note:

    An internal signal also works to turn the constant outputs, the same as the XBLNK input. The internal blank signal is generated at the rising edge of the GSLAT input signal for GS data with the display-timing reset enabled. Also, the signal is generated at the 4096th GSCKR,-G, or -B when auto repeat mode is enabled. XBLNK can be connected to VCC when the display timing reset or auto-repeat is enabled.

    So it does appear that if I enable auto-repeat mode, the clocks will automatically roll over back to 0. Flashing at startup might be a problem though.

    • TLC5948 - LED Vmax of 10v may be an issue for us. We typically run at 12v rail for our LEDs. I also don't particularly like that it is 16 outputs as it doesn't divide evenly for RGB pixels. We could use 3 drivers though, one each for RG and B.
    • TLC5955 - Biggest drawback is the 10v LED Vmax. That said, this is a solid suggestion from what I can see.
    • TLC5958/TLC59581/TLC59582 - I'd like to fill my DMA buffer, fire it off, and then pulse the latch after all the data is out. I don't particularly like the idea of pulsing latch (keeping it high for three clocks?) every 48 bits.
    • TLC5957 - This one looks a lot like the TLC5958, but without the dual frame buffer. It also appears that I have to pulse the latch every 48 bits.
    • TLC694x - I think documentation is missing. There are links in the datasheet to a Technical Reference Manual, but those links are broken on the TI website. I suspect those documents describe how to communicate with the device as I don't see that information in the main datasheet.

    We're currently using  a TLC5947 driver on our prototype board, but it flickers because the outputs turn off when data is latched in. We can pulse the blank signal to significantly reduce, but not eliminate, the flickering. I think my ideal controller would be the TLC5955 with 24 (or maybe 12 outputs). Some of our boards will be about 1" x 24" and routing all those signals may be difficult. We're using TLC59731 for those narrow boards.

    Again, thank you for your assistance!