16-Channel LED Drivers

[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.

[Jumper]

If you really don't want dimming or blinking the LED why don't you go for an i/o expander chip such as MCP23016. I2C controlled and you can even use it as inports for different stuff.

Best invention since canned beer!

They do the same job as a led driver but you have alot less registers to fight with.

/me

[Sponge Bob]

why don't you go for an i/o expander chip such as MCP23016

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

I would consider the above if the source/sink wasn't so low, I would like a little more available juice. I know for most LED applications the 25mA will work but I would still prefer a little bit more.

The TLC5940 gives me 120mA a channel, part of the reason I picked that one.

[elec_mech]

Sponge_Bob,

I think I've got your solution. I've been doing similar things with LEDs lately and my favorite driver IC to date is the SP16DP05. It has 16 channels and uses a simple SPI interface to the PIC to turn LEDs on or off. I've included a schematic showing several LEDs in series per pin, but you can just as easily use one per channel. I don't immediately recall what the upper current limit of this chip is, but it is healthy. Here's a snippet of code:

	SHIFTOUT SDI, CLK, 1, [16bit_value\16]	' Send data to STP16DP05
	HIGH LE						' Enable the STP16DP05
	LOW LE						' Disable the STP16DP05

Setting 16bit_value to $FF or %1111111111111111 would turn on all the LEDs while sending $00 or %0000000000000000 would turn off all LEDs. Each bit in the 16-bit value controls one of the 16 outputs.

I also bought an Allegro A6278 which looks to do about the same thing - upper limits are a little lower - and it's almost half the cost of the STP16DP05 on Digikey. I haven't played with it yet, but it should work and hook up nearly the same way if cost is a big concern. Otherwise go with STP16DP05. I hope this helps.