40x2 Output current capacity

[thunderace7]

Hi. I'm in the early stages of making a large led display. It will have a 40x2 driving 192 RGB less via 72 74HC595 shift registers and 72 ULN2803 drivers.
I am concerned that the picaxe output will not be able to feed the clock inputs of that many shift registers. I thought about a 2 transistor buffer (2 transistors to avoid signal inversion) but I would prefer to use a chip. Any ideas on what would be suitable, please?
I am also concerned about the speed of the display. There is a lot of data to transfer and it might take quite a while, slowing down the display. I will yet up a test on my 40x2 test rig and greatly reduced display to find out how long each display pattern takes to run before starting the next. I could then try different processor speeds and see how that affects it. If all this fails, I shall have to look at ways to speed up the program but I'm hoping to avoid that.

 

[inglewoodpete]

Hi. I'm in the early stages of making a large led display. It will have a 40x2 driving 192 RGB less via 72 74HC595 shift registers and 72 ULN2803 drivers.
I am concerned that the picaxe output will not be able to feed the clock inputs of that many shift registers. I thought about a 2 transistor buffer (2 transistors to avoid signal inversion) but I would prefer to use a chip. Any ideas on what would be suitable, please?
I am also concerned about the speed of the display. There is a lot of data to transfer and it might take quite a while, slowing down the display. I will yet up a test on my 40x2 test rig and greatly reduced display to find out how long each display pattern takes to run before starting the next. I could then try different processor speeds and see how that affects it. If all this fails, I shall have to look at ways to speed up the program but I'm hoping to avoid that.

You don't give much information on how you plan to connect up your hardware. Due to the heavy current required to drive up to ~600 LED junctions, you will need to manage the routing of power to the LEDs/ULNs and the PICAXE carefully to ensure that the PICAXE remains stable.

With the 74HC595s having MOSFET inputs, the current draw on the PICAXE outputs (clock and latch drive in particular) will not be much. However, the 74HC595 inputs have a capacitance of around 10pF, which will add up if 72 74HC595s are to be driven at high speed. It may be wise to use a single non-inverting MOSFET driver on each PICAXE output that is used. Experimenting will give you the answers you require.

Would it be better to use APA102 LEDs, which can be daisy-chained and driven with SPI? Much, much simpler and possibly cheaper in the long run.

 

[tmfkam]

How about some octal buffers? Link all the inputs of the buffers together and then take each output to a few of the 595s. Any inversion could be taken care of by inverting the output(s) from the PicAxe in your code. You could always run the output of one buffer out of eight, into a group of seven providing "double inversion" in hardware.

Big fan of the 595. All LED displays I've made use 74HC595s. From small half inch ones up to six inch, seven segment displays, all driven by the 595, and ULNs where 12V operation needed.

 

[westaust55]

@thunderace7,

First potential alternative to the ULN2803 with reduced volt drop and heat dissipation -see my past thread here:

ULN2803A/UDN2981A drop-in DMOS alternatives to consider

For the ubiquitous ULN2803A as often mentioned and used in PICAXE projects together with its high-side equivalent, the UDN2981A, there are DMOS alternatives available. These alternative parts are the: TBD62083A = 8 channel sink type DMOS transistor array TBD62783A = 8 channel Source type DMOS...

picaxeforum.co.uk

More information from you on how you intend to arrange the RGB LED array and the driver circuit would be good.

Seems you intent to drive each LED element discretely. Is there a particular reason?

Have you thought about multiplexing? The program will have more work to do to keep the display active but less hardware.
I did an 8 x 8 RGB display using multiplexing which is only one-third the number and used just two 16 IO i2c expander chips. Worked okay at 8 MHz so with the higher clock speeds on the 40X2 your larger display should still work well.
Furthermore, from recollection, the i2c was around 4 times faster than clocking out to 74HC595s.


what is the proposed arrangement of the RGB LEDs?
In an array such as 72 x 8 “pixels” or 36 x 16, 24 x 24, or some totally random physical layout?

Clearly there are insufficient pins even on a 40X2 to drive each of 72 74HC595s independently. So the ‘595s will need to be in a number of daisy-chained groups. As such the PICAXE will not be directly driving 72 off 74HC595s. Even with bit-bang to use multiple serial “channels” maybe only directly driving the first chip in say 8 Chains of ‘595s?

suggest that providing more information on your project will enable others here to provide more definite answers/suggestions

 

[thunderace7]

I shall certainly take a look at the TBD devices. Although, I already have all of the ULNs, shift registers and LEDs so I'm not too keen on a radical change of direction. That said, I was formulating a reply to inglewoodpete about how I envisaged it working when I saw a serious flaw in the design and it just will not work.
However, the basics of it are:
The display is actually a 4 foot diameter snowflake with leds all around the edge ( mostly). I am treating the RGB leds each as 3 individual leds. So 192 RGB leds give me 576 individual leds. The circuitry segregates the red, green and blue leds and also divides them into 6 sections representing the arms of the snowflake.
Each section contains 4 shift registers, 4 ULNs and 32 leds. The software sends a stream of 2 16 bit words to the SRs and then moves to the next section where it repeats until all 6 are full. It then repeats this for the next colour and then the next. When all the data is stored it latches it to the output, lighting the appropriate leds.
All the clock inputs are commoned and all the latch inputs are commoned. Thereby lies the problem, once the first section is loaded, loading the next will cause zeroes to be loaded into all the other SRs.
I seem to have a number of options:
1. Keep the clock inputs common but separate the latch inputs, latching the appropriate SRs immediately after loading. Subsequent zeroes won't matter because they won't be latched to the output. Depending how fast it runs (another worry I have), the display will build itself up rather than appear all at once.
2. Keep the latch inputs common but separate the clock inputs. This will allow me to load the SRs correctly and latch them all at the same time. The trouble with this and option 1 is that there are not enough outputs on the 40x2.
3. Redesign the circuit to make only 3 sections (red, green and blue). This will require 24 SRs to be daisy chained and 12 16 bit words to be sent serially. I'm not sure how well this would work.
4. Something else that I haven't thought of yet.

Westaus55, I don't know how to multiplex the leds. Is there something I can read to learn more?
As I understand it, daisy chaining SRs will require the clock and latch inputs to all be connected to the picaxe so it will be driving all 72 of them. Unless I am wrong.

Quite a long story which is why I didn't include it in my first post.
Thanks for your patience.