16-Channel LED Drivers

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

[Sponge Bob]

Thanks for the suggestion on chips, the STP16DP05 and A6278 both look like viable options, the higher mA and single max current limiting resistor are exactly what I was looking for.

I will have to order a few of them for testing.

Also thanks for the pseudo code, but is there anyway I could beg, plead or cry for a snippet of real code that I could immediately compile and load on a pic16f628a so I could be off and running without the inevitable frustration of one stupid missed syntax or dumb hardware mistake that leads me down the debugging road with no solid working basis?

I'll pick up the STP16DP05 and A6278 so no preference on what one the code is for...

Nothing fancy even just the all on all off example you hinted at. Just something to build upon.

I know it sounds lazy and it is no doubt, but many times the frustration takes all the fun out of the hobby and I never get things working.