Maximum Number of 595's ?

I would like to hook up my Arduino to an 8x8 array of 8x8 Dot Matrix Bi-colour modules. Hence making a total of 64 Dot Matrix modules with 8192 LED's in total.

I want to use 74HC595's to drive them and will obviously need 3 per module making a total of 192 Shift Registers in total.

Question is - Has anyone done this before and if so will it work? A lot of data will need to be shifted out for each screen refresh. Will this amount overdo it?

One thing I'd worry about is the maximum current handling of each 74HC595 -- datasheet suggests it's only 70mA total for the entire package, so you can't really count on all outputs driving LED's.

I'm also not getting the math on how an 8x8 LED array needs only 3 74HC595's so maybe I'm missing the point entirely (apologies if so).

You'd only need 2 if it was single colour. One for the anodes and one for the cathodes. As it's bi-colour I'll need 3. I'm using multiplexing.

70mA should be fine, remember you are only displaying one row at a time in each module.

Like this for example -

That's pretty sweet!

My gut feeling is that if you're doing multiplexing AND trying to scale to 192 74HC595's you will overload the processing capabilities of a single Arduino.

If it were me I'd either do some heavy math computation to estimate how this will scale or use a digital I/O pin being set high when the Arduino is "busy" and low when it's idle then use an oscilloscope to get a sense for how burdened it is in real-time, then estimate how many separate 8x8 displays a single Arduino could handle.

This RGB matrix project here concludes that the time spent in ISR (to display (shiftOut) the video memory, I would guess) is 50%. And this is only 1 RGB LED matrix (4 x 595s). You would also have to spend some time doing heavy bit shifting (for scrolling). Another aspect is the "video memory": 8192 LEDs means at least 8192 bits, that is 1KB (out of 2).

50% sounds a lot to me. The ISR routine is simply reading the contents of the display buffer then doing a shiftout routine to the 595's. Even though the ISR routine is running around 100 times per second to reduce flicker, in most cases the display won't need to change 100 times per second. As long as the output buffer is changed around 25 times per second it will be seen as smooth motion.

Either way, i'd need to find out what is the maximum number one Atmega168/328 could handle. If I need to use more than one 'core' to get the job done then so be it. One chip could handle a small number of arrays, like 4x4 or something and a central chip could simply spit out data to the relevant display buffers. Of course i've not done this so i'm talking theoretically.

I guess you could cut down the shiftOut time (in ISR) by coding in assembly (accessing the ports directly?). If the display time for 1 RGB is 50%, you can hardly connect 2 RGBs per processor, I would assume.

A lot more than 2 can be connected to an Arduino. Take a look on YouTube, there are lots of examples using multiple arrays.

Well, are you sure that they use 595s and just one ATmega328? Can you point to one example?

Not an Atmega - But here is one with 4 modules -

Heres one with 3 -

Your output speed will be limited by the processing capabilities of the Arduino. Flashing all of those shift registers is going to take a lot of time. If you divide them into eight strings of 24, writing each cycle is going to take 192 cycles through your loop. Since eight flashes are required to write the entire array once (due to the muxing), you're looking at a minimum of 1536 loop cycles to write to the whole display once. With reasonable amounts of cleverness in C or assembly, you can probably cut the loop execution to and average of four instructions per cycle, or 6144 instructions for a write. That can be accomplished in 0.4 ms, which is probably fast enough for most purposes, but is going to consume most of your computing resources.

I am using 8 shift registers per 3 pins, for totally controlling 225 relays, It worked for me event without transistors, just connected straight to the 595 output, but i supply current to shift registers from pc hard disk cable because there is 5V 12A so enought for that many registers. But actually here I don't care much about refresh rate, because relays maximum switch speed is about 8ms

Of course i've not done this so i'm talking theoretically.

I have just been playing with a single 8X8 matrix multiplexed in software with the Arduino this weekend. No shift registers, column drivers straight off the data pins, row drivers from a demultiplexer (74LS42) so only 4 pins with direct port access. I am having to refresh at a rate of 2mS to stop any flickering. 2ms * 8 = 16mS per frame so about 60Hz, I am not confident about doing more.

In which case, i'd need some kind of external Circuitry. So the question now becomes - Can anyone tell me what I can use to drive lots of arrays at once for a display? With the Arduino just sendign serial commands maybe?

Sparkfun ( has an RGB backpack that can be chained. Now the question is "how many can you control from one arduino?". Their photo shows 7 RGBs linked together.

At that price no thanks !! I'd be cheaper with an RGB Matrix each one with it's own Arduino chip controlling it. Could do that for less than $20 each.

So I guess it is looking like each Matrix would need it's own controller chip. With one master chip sending data out along a daisy chained serial line.

Could data be sent out fast enough?

FWIW, the AtXMEGA chips (the next step up from AtMEGA series) support DMA channels, which means you could just ask the DMA controller to pump out your "video buffer" (the LED bit buffer) to the output without using CPU resources (might have to use SPI or a UART for that though). So your CPU could spend the rest of its time calculating the next frame, etc., rather than having to sit there and pump out bits for the shift-out.

Of course, the XMEGA's run at 32MHz as well, so it might be a moot point, but is something to consider.


I think that the amount of cells (one RGB + one atmega) one can connect to a master uC depends on the application. If you want control over each specific cell, pixel by pixel, that may take more bandwidth than just scrolling a string of characters. In the latter case, each cell could control itself, receiving an "input" character from the previous cell, and sending an "output" character to the next cell. Thus, for this scenario (scrolling text) you could have an unlimited number of cells, each taking care of its own slice of action.

I was thinking of having each unit have it's own font array, plus an array for sprites. Then the master controller could send simple commands for what character or sprite is to be displayed and where.