16-Channel LED Drivers

[Sponge Bob]

Ok newbie post here and I tried searching for the answer but couldn't find any hits, and the captcha image challenge were really complicating searches. I guess my eyes are not as good as I thought.

Anyway I'm looking for what is probably some very simple code, but my serial communication programming skills are in the gutter, so I'm hoping someone can give me some basic starter code to give me a jump start.

I have the TLC5940 and MAX16809 chips for testing and I'm open to other chips as well, if someone is more familiar with a certain 16 channel LED driver chip go with that.

Basically I just want to use a 16 channel LED driver to replace multiple darlington arrays, resistors and free up ports on the micro. I'm not all that interested in the dimming and grey scale abilities of the chip. More interested in just turning on and off the LEDs independently at full level.

Also at this point I'm not tied to any chip so lets just say some generic code or pick a chip.

If anyone can toss together some code that lets say, turns on the LEDs sequentially and then turns them off sequentially I would be a happy camper as I'm sure I can figure the rest out from there. Also if I understand things correctly I need to clock the chips so that part of the code and maybe some explanation of hookup would be helpful.

Thanks in advance.

[Jerson]

Squarepants

Welcome to the forum.

You havent mentioned what you really want to do and with which PIC. Will multiplexed LEDs suit your need ? What is your intended application? Why the particular chips you mention? These clarifications and I'm sure, someone will be able to help you out.

[Sponge Bob]

Squarepants

Welcome to the forum.

You havent mentioned what you really want to do and with which PIC. Will multiplexed LEDs suit your need ? What is your intended application? Why the particular chips you mention? These clarifications and I'm sure, someone will be able to help you out.

What I want is independent control of the 16 (or more) LEDs while removing most of the resources from the PIC side. If that makes any sense. I want to be able to still use the majority of the other I/O ports on the pic for other things while not being burdened by constantly controlling the 16 (or more) LEDs... Also the use of a driver chips increases the source/sink levels and allows me to limit all channels current with a single resistor. Lower parts count and smaller circuit size. I figure even for basic applications the single chip replaces darlington arrays and multiple current limiting resistors, lowering the parts count almost immediately.

As for the particular chips I mentioned only because I have those on hand, any 16 channel controller will work, not picky at all right now, and I'm open to other chips... The reason I want to go this way instead of multiplexing is the ability to cascade these chips and expand to lots of LEDs while not increasing the number of used I/O pins on the chip... If my understanding is correct, I should be able to control 100s of LED independently from even a pic16f628a with plenty of left over I/O lines by cascading the controller chips. Multiplexing directly off the pic in the end (unless I'm missing some trick) will incur substantially more parts and I/O lines as the number of LEDs increase.

Hope that clarifies things.

[Jerson]

I get it now. You want a serial to parallel converter with darlington drivers to handle LEDs and you want it to be expandable. You're right in saying that the 16F628A could handle lots of LEDs with this technique. However, you should be aware that though you are saving on the pins at the PIC, you are not lowering the burden on its coding. It will keep updating the LEDS at a regular rate to let you have the moving patterns you wish for.

The commands could help you are SHIFTOUT or maybe I2C_READ depending on which is relevant to the chips you want to use and how 'low cost' you want to design.

[Sponge Bob]

You want a serial to parallel converter with darlington drivers to handle LEDs and you want it to be expandable.

Yep, exactly PICs are great but once you start compounding high numbers of LEDs at 20mA a piece you start to tax the PICs sink/source limits pretty fast.

However, you should be aware that though you are saving on the pins at the PIC, you are not lowering the burden on its coding. It will keep updating the LEDS at a regular rate to let you have the moving patterns you wish for.

Yes I'm aware of this, in applications where there is constant motion it won't save much cpu time, but vs the alternative of multiplexing where you need the tight loop just to simulate shared pin LEDs being illuminated at the same time I believe it really shines.

Just for example if I wanted a large debounce on a switch, or flat out pause in the code multiplexing would fall flat on it's face unless you slowly chunk away the pause(s) within the multiplexing loop. I would rather avoid this and simply have a driver chip keep the LEDs illuminated independent of the PIC when it take a deep breath.

The commands could help you are SHIFTOUT or maybe I2C_READ depending on which is relevant to the chips you want to use and how 'low cost' you want to design.

Yeah, but as I said I'm a little challenged on the code, so a little helper code would go a long way... It's one of those things I understand the whole concept but for some reason I can't put two and two together and actually write the code. Just one of those stupid brain blocks.

Also maybe to make this simpler I will narrow it down to the PIC16f628A and the TLC5940. That way everyone is on the same page.

[sinoteq]

Check out National's Funlight driver. http://www.national.com/mpf/LP/LP3943.html

Works like a charm but is pig to solder.