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.You want a serial to parallel converter with darlington drivers to handle LEDs and you want it to be expandable.
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.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.
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.
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.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.
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.
Bookmarks