Go Down

Topic: What will happen if I drive LEDs in parallel from a TLC5947? (Read 4582 times) previous topic - next topic


Also, I'm not familiar with buffering, but if by that you mean put another chip on the line, that seems like it would be way too expensive,

Do you want it to work or not?

Given a choice of being able to afford to have my PCBs manufactured and only being able to connect 6 LED modules, or making the PCBs so expensive to manufacture that I can't afford to manufacture them but allowing them to run 10 modules in theory, I'd chose "not".

I literally spent every last dime I had getting these boards made Grumpy.  If I had had to spend another $500 on another chip, I would have had to have had fewer boards made, and I would not have had any spares to sell, and I would not be sitting here asking you how to improve the boards when I do a second run, because I wouldn't be able to afford to do a second run. 

In fact, whether I will be able to do a second run is still up in the air.  I have 35 kits I need to sell in less than a month to get there, and I only sold 6 this week.

You need buffering on the signals that go to all the chips when the driver can not cope with that number of inputs. Normally I would recommend one buffer to drive 4 chips. The buffer's inputs can be common.

Well the "driver" here is the Atmega1284P I have on my board.  It drives 6 of those chips without a problem. 

Layout should be tight and short to increase signal integrate and reduce pickup and radiation.

There's my boards.  I made the LED driver boards as small as I could, and the traces as short as I could.  Of course there is nothing I can do about the longish ribbon cables I need between the boards.  The whole point is to be able to install them in various locations around a prop. 


Buffers are one of the cheapest ICs you can get. You get 6 buffers in one package for less than $0.20.

Okay, well I had 440 of these LED driver boards made.  So that's another $88 in parts, plus the additional assembly cost, plus the cost for any capacitors needed, plus the cost associated with having to make the PCBs larger and fitting fewer on each panel.  Probably looking at around $100 more.  Which may not seem like much, but I was treading on a razor's edge with my budget for this, since the project ran three months past when it was supposed to and I missed my prime sales season. 

Also, I was kinda limited for space on the LED modules.  They gotta fit in the props they'll be used in.  Honestly, if the price I have to pay for not including he chip is only being able to run 6 modules at once, that's better than the alternative of not having the boards fit where they need to go.

But I'll definitely look into the buffers when I do redesign the modules. Needing more than 6 modules in a single prop however is extremely rare. 


Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.


One of these buffers http://uk.farnell.com/texas-instruments/sn74lvc1g125dbvr/ic-buffer-gate-bus-smd-sot-23-5/dp/1470768 would take up very little space on your board.

Well I guess the question then is, is it just my clock line which needs buffering here?  I would assume the led modules themselves are acting as buffers for the data line since it passes through them.  Would that be correct?

I do also have lines for chip select and blank but I suspect those aren't as susceptible to whatever issue is plaguing the clock line.


It's almost certainly the clock line causing the problem. As you say, the LED driver chips themselves buffer the data. Ideally you would buffer CS and blank as well, however ringing or slow rise/fall times on those lines are unlikely to cause anything like the same scale of problems. If you did want to buffer those as well, you can get quad buffers such as http://uk.farnell.com/texas-instruments/sn74ahc126pw/logic-bus-buffer-tri-st-qd-14tssop/dp/1740922.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131