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.

TLC5957: TLC5957 operation flow

Part Number: TLC5957

Hi Ti Team,

We are using TLC5957 LED driver. Below i provided the how we want to use the LED driver. 

We will get the Mode & Sub-mode details as input to the FPGA, we want to drive the each LED(16 LEDs totally) based on the mode & sub-mode. It includes below functionality

  1. Changing the color of each LED
  2. Toggling each LEDs based on the mode & sub-mode

MODE

SUB-MODE

COLORS

Color Values

(48 bit- {B,G,R})

Toggling

A

1

Green

{0000,FFFF,0000}

 

2

Red

{0000,0000,FFFF}

0.2 Hz

3

Blue

{FFFF,0000,0000}

 

4

Orange

{0000,7FFF,FFFF}

 

5

Purple

{FFFF,FFFF,0000}

 

6

Yellow

{0000,FFFF,FFFF}

0.2 Hz

B

1

Green

{0000,FFFF,0000}

 

2

Red

{0000,0000,FFFF}

1.0 Hz

3

Blue

{FFFF,0000,0000}

 

4

Orange

{0000,7FFF,FFFF}

 

5

Purple

{FFFF,FFFF,0000}

 

6

Yellow

{0000,FFFF,FFFF}

0.2 Hz

C

1

Green

{0000,FFFF,0000}

 

2

Red

{0000,0000,FFFF}

1.5 Hz

3

Blue

{FFFF,0000,0000}

 

4

Orange

{0000,7FFF,FFFF}

 

5

Purple

{FFFF,FFFF,0000}

 

6

Yellow

{0000,FFFF,FFFF}

 

 

Please find the below queries

  1. Global Brightness control (BC) : 3 bit à It is meant for the Brightness control of all LEDs at a same time. Please confirm?
  2. Global Brightness Control (CC) : 9 Bit à It is meant to represent the brightness of each color for all LEDs. Please confirm?
  3. We are keeping 30 SCLK cycle(idle clock cycle) in between the FCWRTEN command and WRTFC command. We presume it won’t be a issue, Please confirm?
  4. “During the same period of step 4, GS data for next line should be written into GS data latch. Using LATGS command for loading 48-bit GS data.” à We understand that GCLK is used to set the brightness. So during GS data write (768 bit write operation), we need to provide the GCLK edge from 0 to 65536 rising edge. By that time LATGS command applied, whatever the GCLK edge counter value provided, that value is set as brightness level.
  • When new GS data (768 bit) is loaded, do we need to provide GCLK again?(for each new GS data).

          Please confirm our understanding w.r.t point 4 is correct or not?

  1. When LATGS command is provided, we understand GCLK edge counter will be reset. Please confirm?
  2. We need more clarity on XREFRESH bit. From user guide, we understand below points
    1. XREFRESH = 0, GCLK must reach 65536, then only GS data from Latch 1 will move to Latch 2.
    2. XREFRESH = 1, during last line when LATGS is provided, then GS data from Latch 1 will move to Latch 2. During this mode of operation, do we need to provide the GCLK ?

            What is the difference in GCLK when XREFERSH = 0 and XREFERSH = 1 ?

  1. We are not using Poker mode, in this case do we need to use LINERESET command? When it is required for normal mode?
  2. To blink the LEDs, we understand below methods can be used
    1. Change GS data to zero (change respective group’s 48 bit data to zero in GS Data latch register)
    2. Change BC value to zero in FC register
    3. Change CC value for R,G,B to zero in FC register

              Please confirm our understanding is correct or not?

Regards,

Jagan

  • Hi Jagan,

    1. Yes 3-bit BC is for all LEDs at a same time.

    2. Yes 7-bit CC is for each color group.

    3. Yes it is OK to have some idle SCLKs between CWRTEN command and WRTFC command.

    4. No the GSCLK is used for output PWM reference clock. It need keep sending during device operation. It is paralleled with data writting.

    5. No, the GSCLK counter is not related with data input.

    6. Nothing difference between XREFERSH enable or not for the GSCLK. It still need continuously input. The difference is about the output channels. The outputs would be forced off after 65536 GSCLK and counter reset to 0, if this function is disable.

    7. LINERESET is used to reset line counter. It may need to be used if you use multiplexing structure.

    8. Yes these ways are all OK. Usually we prefer to keep FC register and use GS register for a pattern display, since GC control effect quickly. But the frequency of your patterns are quite low, all ways should be OK.

  • Hi Hardy Wu,

    Your answer helped us to understand better.

    Still I need more clarity on GSCLK. Please find my below queries based on your answers:

    1. GSCLK is output PWM reference clock. Hence TLC5957 to operate, we have to provide GSCLK continuously (irrespective of we are sending data or not). Please confirm.

    2. When GSCLK=65536, it will force off the value and reset the counter. This operation will always happening  (irrespective of we are sending data or not). Please confirm.

    3. Do we have any detailed timing diagram that correlate the GSCLK(Grayscale Control Clock) and SCLK (Data Transfer Rate) ?

    4. we understand that we can use different clocks for GSCLK and SCLK. Do you have any suggestion for selecting the ideal GSCLK and SCLK based on our toggling frequency?

     

    Regards,

    Jagan

  • Hi Jagan,

    I have one question that why do you choose this device for your application, which is hard to use if you do not need to display complex videos. How many LEDs and the current your design needs?

    1. Yes the GSCLK need continuously input.

    2. Yes the counter would be reset. When XREFRESH=0, auto refresh function is enabled and the device keeps running. If XREFRESH=1, the outputs would be forced off once GSCLK counter reaches 65536.

    3. Basically there is no relationship between GSCLK and SCLK. They are 2 separated parts.

    4. For GSCLK frequency, to ovoid flicker captured by human eyes, at least 200Hz is required for one output PWM cycle. So that 200 * 65536 = 13MHz is needed, for traditional PWM mode. Using ES PWM mode could increase the virtual refresh rate. Also taking example to achieve 200Hz output PWM, GSCLK need 200 * 65536 / 128 = 101kHz.

    For SCLK frequency, only need to update all the data within 1.5Hz. So at least 1.5 * 768 = 1kHz is OK.