Author Topic: TLC5940 vs TLC59116 vs ... for 105 RGB LED matrix  (Read 2570 times)

0 Members and 1 Guest are viewing this topic.

Offline 3dgeoTopic starter

  • Frequent Contributor
  • **
  • Posts: 289
  • Country: au
TLC5940 vs TLC59116 vs ... for 105 RGB LED matrix
« on: January 08, 2019, 01:37:25 am »
Hello there,

Currently my matrix setup is 3 x 16 output ICs that sinks 15 RGB LEDs at once (7 LEDs are connected to one input) and 7 PNP fets for multiplexing those 7 LEDs. So in total 105 RGB LEDs (15 * 7). Sorry if my matrix explanation is hard to understand   :palm:

Well, the matrix itself is not the issue, I'm happy with it, I just wanted to ask about ICs that controls it.
originally I was gonna use TLC5940, but it seems that TLC59116 would be a simpler option due to simpler hardware connections (coding is not an issue ether way).
Is there any advantages using one or the other?
I know that TLC59116 only has 8 bit resolution VS 12 bits on TLC5940 and it has more complicating constant current calculation, but other than that?
Is there any speed benefit? Potential artifacts? Others things I should know but don't?
I'm planing to code some pretty advance animations (if MCU can handle them  ^-^), so 8bit calculations will be faster compared to 12bit, and will it make that big of a difference between color gradients? I want to make at least 100 units, so price is a factor too, but it seems both ICs are priced similarly.

I have looked to other ICs, but I didn't found any that tickle my pickle, tho I'm open for suggestions.

Big jucy thatx for those who spend time reading my noob problems and try to help  :-+

EDIT: Ho bad of an idea is to buy these chips from places like Alibaba?
« Last Edit: January 08, 2019, 02:54:39 am by 3dgeo »
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1076
Re: TLC5940 vs TLC59116 vs ... for 105 RGB LED matrix
« Reply #1 on: January 08, 2019, 01:56:43 am »
I’m assuming the PWM control for the driver chip affects every LED that the chip is driving, rather than individual pixels,
so that an animation with different coloured pixels would be achieved through the use of multiple frame buffer bitplanes,
or am I mistaken here?
 

Offline 3dgeoTopic starter

  • Frequent Contributor
  • **
  • Posts: 289
  • Country: au
Re: TLC5940 vs TLC59116 vs ... for 105 RGB LED matrix
« Reply #2 on: January 08, 2019, 03:16:44 pm »
What different does it makes on driver selection?
 

Offline @rt

  • Super Contributor
  • ***
  • Posts: 1076
Re: TLC5940 vs TLC59116 vs ... for 105 RGB LED matrix
« Reply #3 on: January 08, 2019, 05:52:25 pm »
That it would make little difference for a complex animation, but I see now that at least TLC59116 is dealing with the individual LEDs.
 

Offline 3dgeoTopic starter

  • Frequent Contributor
  • **
  • Posts: 289
  • Country: au
Re: TLC5940 vs TLC59116 vs ... for 105 RGB LED matrix
« Reply #4 on: January 08, 2019, 09:32:44 pm »
Even tho one TLC output is connected to 7 LEDs, it will control only one LED at a time due to 7 fets that will disable other 6. I still don't understand how this impacts IC choice. I have matrix figured out, as I wrote – it's not an issue.
 

Offline Apollyon25_

  • Regular Contributor
  • *
  • Posts: 66
  • Country: nz
Re: TLC5940 vs TLC59116 vs ... for 105 RGB LED matrix
« Reply #5 on: January 31, 2019, 01:59:44 am »
The most common issues typically encountered in these LED matrix arrangements is either current sharing/splitting if two or more LEDs are enabled at any one time, or the control communications timing limiting overall frame rate.
I2C bus speed limitations generally more so than SPI. Some LED drivers will sequence the control to chips further down the chain like conventional shift registers.
I haven't looked to check which type these drivers are tbh, or to see if you'd posted a schematic.
Whether these issues are an issue for you in practice largely depends on your actual application.

ISSI have a few suitable chips as well which may be worth looking into...
 

Offline ajb

  • Super Contributor
  • ***
  • Posts: 2785
  • Country: us
Re: TLC5940 vs TLC59116 vs ... for 105 RGB LED matrix
« Reply #6 on: January 31, 2019, 05:51:00 pm »
For any sort of matrix I would definitely go with the 5940 over the 59116, especially if you want to get full color mixing (IE, intensity control of each individual color in each pixel).  The extra connections on the 5940 are there to allow you to synchronize its internal PWM with your matrix scan.  Most reasonable MCUs these days allow you to link timers, so you can use one hardware timer to generate the GCLK, and then a second timer clocked by the first to drive the blanking signal and trigger the row update transaction on the SPI bus. (Actually instead of using a timer for GCLK, you could use one of the MCU's clock outputs, if you have one available at a suitable frequency.)  That way your matrix scan is fully synchronized via hardware, and at most your MCU only needs to attend to one or two ISRs.  The 59116 doesn't offer a direct hardware sync, so it's going to be tricky to get good results at reasonable scan rates.

Plus, even at fast mode, I2C on the 59116 is only 1MHz and has a fair bit of overhead, so the 30MHz (IIRC) SPI on the 5940 is going to be way faster and also simpler to program.
 

Offline 3dgeoTopic starter

  • Frequent Contributor
  • **
  • Posts: 289
  • Country: au
Re: TLC5940 vs TLC59116 vs ... for 105 RGB LED matrix
« Reply #7 on: March 05, 2019, 03:31:41 pm »
I'm reviving this thread – I made a prototype so I can share how it works.


The most common issues typically encountered in these LED matrix arrangements is either current sharing/splitting if two or more LEDs are enabled at any one time, or the control communications timing limiting overall frame rate.
I2C bus speed limitations generally more so than SPI. Some LED drivers will sequence the control to chips further down the chain like conventional shift registers.
I haven't looked to check which type these drivers are tbh, or to see if you'd posted a schematic.
Whether these issues are an issue for you in practice largely depends on your actual application.

ISSI have a few suitable chips as well which may be worth looking into...

Well, yes, I2C speed might be a potential problem – in my matrix MCU turns off LEDs anodes with Pfet then pushes I2C update to ICs and turns LEDs on again. By itself this seems to work just fine, even LED dimming while I2C code gets pushed isn't noticeable. With my current setup anodes gets updated at 500 Hz and cathodes 100-200 kHz, frequencies are too far apart to get any PWM artifacts.

But I also added I2C cap touch IC, and getting data from touch IC seems to introduce slight flickering (I wrote my own RAW I2C communication code, no libraries cos they are just too slow).

I looked at ISSI chips, they look really good, I definitely consider using them, they are even cheaper than my current LED drivers.


For any sort of matrix I would definitely go with the 5940 over the 59116, especially if you want to get full color mixing (IE, intensity control of each individual color in each pixel).  The extra connections on the 5940 are there to allow you to synchronize its internal PWM with your matrix scan.  Most reasonable MCUs these days allow you to link timers, so you can use one hardware timer to generate the GCLK, and then a second timer clocked by the first to drive the blanking signal and trigger the row update transaction on the SPI bus. (Actually instead of using a timer for GCLK, you could use one of the MCU's clock outputs, if you have one available at a suitable frequency.)  That way your matrix scan is fully synchronized via hardware, and at most your MCU only needs to attend to one or two ISRs.  The 59116 doesn't offer a direct hardware sync, so it's going to be tricky to get good results at reasonable scan rates.

Plus, even at fast mode, I2C on the 59116 is only 1MHz and has a fair bit of overhead, so the 30MHz (IIRC) SPI on the 5940 is going to be way faster and also simpler to program.


I made a prototype with 59116, matrix seems to work reasonably well. I can see huge advantage of 5940 that it has latching, if I understand it correctly MCU can push data to 5940 first, and after data is sent it lathes it to outputs – if it works like this, this is a huge benefit compared to 59116. While digging in 59116 I2C registers I didn't find functionality like this – sent data goes directly to output thus MCU have to wait till all 3 IC gets their data and then turn anodes on again. But there is other side of the coin – price of these ICs, cos this is not one off product – 59116 is half in price compared to 5940 and it seems to work well enough, so I just might stick to 59116 or change to ISSI ICs recommended by Apollyon25_ cos they look promising. Also I'm changing MCU from 32U4 to STM32 cos 32U4 is just too slow in LED animation calculation, so I will have 2 I2C lanes and hopefully slight flickering while using LED drivers and cap touch IC at same I2C lane will be eliminated (probably I could optimise code itself as well).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf