TLC5940 code understanding

DXC

Hello,

I heb 32 tlc's on a pcb, now I have a problem if I set more then 12 leds op full brightness.
The leds then go random.
Code I use are from BTX I believe(Alberto Geraci is his name)

the schematics.
- data lines from prop. go to the tlc pcb with 100 Ohm resistors
- on the every tlc had 100nF close to it
- every tlc also has 1uF parallel on the 100nF I mentioned
- supply of the tlc's consist of 2 lm1117 which make from 5V 3,3V, both have 10uF on 5V and 100uF on the 3,3V side.

Now I have 2 questions.
1.
What did I do wrong with the schematics?
Is the propagation making an issue here? Or will it help if I put a 2x 74hct240 between the line because the tlc's eats 1mA a piece.

2.
I want to make the code myself only 1 thing I dont understand.
The GSclock runs from 0 to 4095 and the a BLANK puls.
The data which is clocked in must be clocked in in time before the GSclock ends.

GSclock 0 1 2 3 4 5 6 7 8 9 .... 4090 4091 4092 4093 4094 4095
DATA shifted in x x x x x x x x x x .... x x x x

this should be the case, GSclock runs from 1 COG and the data clocked in from another clock.

My question now is how is the GSclock synced with the DATAshift code.

I mean the GSclock runs continiously , but the DATA that has to be clocked in must start at 0 or somewhere, so it will fit in the time then GSclock reaches 4095.

maybe some here knows my questions.

gr,

Timmoore

It sounds more a power supply problem than a software problem, you talk about lm1117 but what is feeding thoses and the LEDs and how much current can it supply

DXC

Well the power supply is 5V 12A, which would be enough for the all the leds at max.
20mA per led time 512 makes ~10amps.
2A reserved for proc and chips.
*note* leds have 5V on the anode.

below is a bit how the io lines are positioned on the PCB(233*160)

|

---

11TLC's

---

maybe buffer here |
|

---

11TLC's

---

|
| maybe buffer here
SCLK

---

10TLC's

---

|

First thing I thought was propagation delay, the data line SIN take en couple of ns to go from SIN to SOUT when SCLK is set high.
believe is was 10ns * 32 makes 320nseconds delay viewed from the SCLK.


Maybe you also know, why they say the data has to clocked in before the GSCLK reaches 4095.
If so the shifting of data has to begin when GSCLK is '0' but if I look at the code this is not the case.

gr,

RickB

In this forum thread is a link to a free pdf book on the TLC5940. Code is in C and shematics are included.

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=94590

Rick

DXC

will look at that link soon,

Below is a link of the pcb's.
http://www.youtube.com/watch?v=DKH6jzZL3hw

Link below shows the fault, first you see it work ok, 3 leds going up after 5 seconds I load the prop which then fills it from the bottom.
After some lines are filled it goes crazy.
http://www.youtube.com/watch?v=HdZ7-cJYpHE

DXC

I allready have the demystifying.pdf.
It all state that when the GSCLK has reached 4095 the data must be clocked it.
The reason I ask this is, I think that if you send halve the data in , is will not be visual, but will in the second GSCLK row.

The code I use is in ASM and when I put a delay on every time it wants to set an output.
The de leds will skip a couple of leds, the more I set the delay higher.
In the original code is also a delay, dont know why.

gr,

RickB

You might register with AVR Freaks and in the tutorial thread ask for some help with your problem.

Rick

Jack Buffington

If I am understanding correctly, those are white LEDs that you are driving. If that is the case, then you could really save some cash and drive the LEDs more or less directly. I recently did a project where I was driving an 8x8 RGB LED array with a propeller. At first I looked at using a PIC chip and a couple (or three, I forget) of TLC5940 chips. I was using the propeller in another area of my design and came to realize that it would actually be cheaper and would use less board space to just use a propeller chip instead. I drove one row of LEDs at a time and used a multiplexer and a mosfet to select the row. It totally exceeded the published capabilities of the propeller but I drove the LEDs directly from the I/O pins. It worked out fine. In the end though, even though I was only driving the individual LEDs at maximum of 1/8th of the time, they were too bright. I ended up dimming them to a maximum of 1/32nd of the time so most likely I wasn't really exceeding the current specs for the chip.

In any case, looks like you have 16 LEDs up and more than that across. Maybe you could consider something like what I did except maybe use two or more propellers to drive the LEDs and one master propeller to drive them. That way you can come up with your own protocol and will know how to use it perfectly. In my project, I was streaming video to many of these 8x8 arrays so data rate won't be a problem.

DXC

I think you mean a 8x8 matrix Jack?
I know that principle yes, would be much cheaper to build, would consider it next time I build a matrix leds.
The sensing part in this project is a matrix like build tho.

I know how the TLC works but what I dont understand is what would go wrong if it takes longer to clock the data in then the GSCLOCK to finish at 4095.

I cannot find comments about that...

I found it strange my the code I used had een delay build in(just before it started to clock data in).

gr,

DXC

Ok the mystery about that the GSCLK has to be longer than de data clocked is know.
I think I know it.
It does not matter if you start the data clocking at the end of the GSCLK count.
Tho it would be better to sync the dataclocking when the GSCLK is resetted.

Next problem still exist, why is the last TLC in the row getting very hot and after a while disabled(or dead?).
I already swapped it with a new one but same result.
Think they will get warm bit the last one is just not thouchable.
And why cant I set all the 16 outputs on 3 tlc's.

gr,

Jack Buffington

Just a quick note about what I found when messing around with those chips. I found that I could tie the gray scale clock and the shift clock together and make one big SPI routine that always shifted out 4096 bits. That was working for me. I don't know how you have your code set up but maybe you should give that a try. I had my code read from some variables in RAM for the first N clocks and then shifted out zeros for the rest of it if I remember correctly.

-Jack

DXC

Jack was it also a tlc?
I now use 2 cogs:
1 for data shifting and the 2e I use the GSCLK from BTX.

But I must spend more time on my tlc pcb.
There are 32 on it, between the 9,10 and 20,21 tlc I have put a 74hct244.
Put 1k resistors on the outs of my prop.
lowered the clock so the data shift has a speed of ~600khz.

Is it true that when the data is clock in with a rising edge, the falling end shifts the data out? after 192 ofcourse?

DXC

Today I unplugged 10 tlc's from the rest.
So only 10 are programmed by the prop.

I thought lets take the GSCLK loose from the prop and set it on 3,3V and measure the current.
This current was ~40mA, so too much for the prop to deliver.
But in de TLC5940 data sheet I cant find current draws on de input sides.
http://focus.ti.com/lit/ds/symlink/tlc5940.pdf

so maybe more drivers(74hct244) are needed...?

kevin101

Are you using the blank pin(s) on the driver chips? You should use it to sync the gray scale cycle and the data latch inputs.

The data input and brightness control are almost two completely separate circuits. The gsclk pin on the chip is connected to a 12 bit counter, the outputs of each led looks to this counter to tell when to turn off. Each output has a 12 bit register programed with a brightness that you shifted in. When the gsclk register reads 0, all outputs are on unless that output a brightness of "0" in its register. If you send 1 pulse to the gsclk pin, the counter increments to the value of 1 and any output with the value of 1 will turn off and so on. This works with any value up to 4096, at which time you use the blank pin to reset the gsclk counter and start the process over. If GSCLK > OUTPUTx, turn OUTPUTx off. For 8 bit color, you only run the gsclk up to 256 pulses before blanking the outputs and shift the data in for each channel with 4 dummy bits at the beginning. This works for any color resolution you require.

Data input is separate from the brightness control circuit and only influences the other when the latch is pulled high. With this in mind, you can shift all the data into the registers of the devices during the brightness control cycle, it doesn't matter how many have passed, the old brightness data stays intact. You want to wait until you pull the blank pin high to latch the data, as it immediately becomes relevant in the outputs. If you latch the data during the gray scale cycle, the outputs will change immediately to the new values and may add some noticeable irregularities in the brightness of the LEDs.

You only need to shift data in at the desired picture refresh rate and you can run the brightness control at a much higher frequency to eliminate flicker. Synchronizing the data latch with the blank input will eliminate any flicker due to the brightness values changing.

I don't know anything about the hardware problems that you are having other than if you left out the current set resistor. If you don't have one for each chip, than this may be why some outputs turn off randomly.

DXC

Hello Kevin,

I dont think the code is wrong.
If I turn a couple of leds on, 4 leds, the everything goes ok.
I if I turn more and more leds on they seen to flikker.

The GSCLK I use is written by BTX, and the data shift in is my own.
Also used the complete code from BTX, same result.

As said I looked at the current draw, 40mA, thats allot.
The prop only can handle 24mA/pin.

will have to take a good look at that.

gr,