8x8x8 multiplexed LED cube with an Arduino Mega 2560

Hi Everybody!

I'm a new member in this forum, who has just received an Arduino Mega 2560 as a Christmas gift :slight_smile: This means that I've never ever worked with Arduino before. but I have a big dream for about 2 years now, building an 8x8x8 LED cube and I'm going to try that as my first Arduino project. For this I need a little bit of help :slight_smile: Please help me verify my theory about how I plan to construct it and give me useful advice if you can.

I'm an amateur when it comes to electronics. I've done some electronics projects in my life (like a binary LED clock controlled with a Raspberry Pi or a miniature locomotive driver which controls H0 locomotives with PWM signals), so know a few things, but there are quite many things out there that I don't know. In the last two years I have searched the Internet for how an 8x8x8 LED cube can be created. I've read many things, half of which I don't understand at all, so I'd like to create my cube in the simplest fashion possible, but not compromising the perfection of it. I hope to avoid using shift registers, latch circuits and other additional complications which I think will be possible, as it seems that I'm in a lucky situation because the Mega 2560 has a lot of I/O pins (54 digital pins + 16 analogue pins = 70 pins in total). That gives me enough pins to create the 8x8x8 cube with multiplexing.

Usually what people do is to connect the anodes of all the LEDs which are above each other, obtaining 64 columns and to connect the cathodes of all the LEDs which are in the same horizontal plane, obtaining 8 planes. This way you can light up the LEDs using multiplexing and you need 64+8 pins. But even the Arduino Mega 2560 does not have that many pins, so I had to find another way. And there is a pretty simple way to reduce the number of pins: divide each horizontal plane into two half planes. This way you will only need 64/2=32 pins to connect to the anodes and 8*2=16 pins to connect to the cathodes, a total of 32+16=48 pins! Well, the multiplexing software will have to handle the special kind of multiplexing which uses half planes, but that's OK (I've never written software for Arduino so far, but I'm confident that I can do it, I have more doubts about the hardware part :slight_smile: ).

Based on the above approach, the LED cube can be made by dividing the cube into 16 zones (half planes). The anodes of the vertical LED columns are all connected together and the 32 resulting column groups are connected to a digital Arduino pin. The cathodes in each of the 16 half planes are also soldered together and each such group is connected to an Arduino digital pin. These 16 half plane groups are multiplexed from software, meaning that at any given time the current can only run through one half plane and the 16 half plane pins are switched very fast one after the other. Persistence of vision makes it possible for humans to see the cube as if all 16 half planes would be lit up at all times. This is the theory. To light up a given LED in the 8x8x8 matrix, we would have to pull the appropriate anode pin high and the appropriate cathode pin low, if I understood this correctly from other similar projects.

In theory it is that simple. In practice, however, it is far more complicated because of the Arduino's current limitations (global current limitation and per pin current limitation). I think the total current limitation of the 5V rail is 50 mA and in addition each pin has a maximum limitation of 40 mA. So it's clear that I'll need to power the LED cube from an external power source and that I'll need to add some transistors between the Arduino and the actual LEDs. I will use the signals coming from the Arduino pins to switch the transistor inputs and the transistor outputs will switch the actual, higher power LEDs. And this is the point where things start to become unclear to me. As we have established above, at any given point in time only one half plane should be lit up. that means that in the worst case 32 LEDs should be on at any given time. But as we all know, the multiplexing software can have bugs, which is likely to happen since it's my very first Arduino software. That means that we need to assume the worst: that it could happen that al 512 LEDs light up at the same time. That means quite an amount of current and we'll need some kind of hardware protection to limit the current and to protect the Arduino from such dangers.

But how much maximum current will be flowing exactly through the LED cube at a given time? To determine that, the fundamental question to be answered is: how much current is needed by a single LED? I'm planning to use standard superbright 5mm LEDs. Their datasheet states that they should be operated at 20 mA and people use this value most of the time. However, I have found that giving those LEDs 20 mA is a complete and utter waste of current. I've done some experiments and those LEDs are very bright even at 0.5-1 mA! Surprising, but true. SO I plan to limit the current through each LED with a resistor of appropriate value to 1 mA. I hope this can work with multiplexing (fast on/off switching of the LEDs), not just when the LEDs are continuously on. Please let me know what you think about this. If this can work, then at any given time no more than 32 mA should flow through the cube, or if the software has a bug and all LEDs light up, no more than 512 mA. Now this even questions the need to use transistors between the Arduino and the LEDs. The digital pins connected to the anodes would only be supplying 1 mA each and the digital pins connected to the cathodes would only be sinking 32 mA each. I'm thinking that I could add resistors to the anodes to limit the current to 1 mA and resistors to the cathodes to limit the current to 32 mA, for safety. Is this safe enough? Would this work?
If the above suggestion is unsafe, I plan to use ULN2803 ICs for switching the LEDs based on the signal coming from the Arduino pins. If I do this, I don't know if I should add current limiting resistors between the Arduino pins and the ULN2803 input legs, or the ULN2803 chips already include some current limitation mechcanism which will make sure that the current flowing through each of the Arduino pins and the total current flowing through all the Arduino pins is small enough. Between the ULN2803 output legs and the LEDs I plan to add current limiting resistors which would limit the current through each LED to 1 mA. Also, if I'm going for the ULN2803 based approach, I'm still thinking of avoiding an external power supply and taking the current from the Arduino's 5V rail. I'll still need to add a resistor to limit the total current taken from the 5V rail to a toal of 32 mA, in case the software goes nuts and turns on all the LEDs.

What do you think of my approach. Is this achievable at all? is it oversimplified? As I said in the beginning, I want to keep it as simple as possible, but I do not want to endanger my Arduino board in any way, so hardware protection against too big currents is a must have in all possible ways.

Thanks in advance for any good advice you might be able to give me!
Andras

What do you think of my approach. Is this achievable at all? is it oversimplified? As I said in the beginning, I want to keep it as simple as possible, but I do not want to endanger my Arduino board in any way, so hardware protection against too big currents is a must have in all possible ways.

My advice is:

Start with a smaller cube, say 5x5x5. You will learn a lot about both the electronics and the software that will put you into a much better chance at being successful when you scale up to 8x8x8 cube.

Your desire to not use shift registers is a poor choice and makes your project require more components and complexity then it needs to. There are special 16 bit serial shift registers that also include programmable constant current outputs that solve the led current control problem. Datasheet: ( http://www.onsemi.com/pub_link/Collateral/CAT4016-D.PDF ) I can't emphasize how much simpler the whole project becomes when using these special shift register/driver chips then if you instead try some other method of current control for the leds. You will need an external source of +5vdc to power the cube, but it will only need to be rated at about 2 amps max output current capacity (64x.02A = 1.28 amps)

Be sure to buy 'diffused' leds as their wider dispersial of light gives a much better effect then narrow beam brighter leds.

Here is a very good led cube project page where you can learn a whole lot before committing to buying stuff. While it's based on using a PIC micro chip the hardware design is 100% applicable to an arduino based project. I used their basic design for my arduino (actually a standalone 328p chip ) driven 5x5x5 blue led cube and while challenging from both a construction point of view and software design (I wrote the sketch from stratch) it was successful from the git go.

Once completed I think you will find the biggest challenge is coming up with creative and complex pattern displays. I found this very tedious and time consuming and stopped after building maybe 6 or 7 pattern scripts. What is really required is some kind of PC based GUI led pattern generator editor where you can build your pattern frame by frame and then get the raw binary data patterns that you can copy and paste into your cube sketch.

Lefty

I would agree with lefty that you should really start smaller, 8x8x8 is a lot, really a lot. You will have to complete many stages of the project before you understand why not do do something a specific way, but by then you will have used up 500 leds, and have a huge mess.

I would suggest starting with a 3x3x3, you can probably build one and get it working within a day, it will only waste 27 leds, you wont really need other hardware (should also use 9 resistors), so you can focus on learning how to build a cube, which itself is fairly difficult.

I would then progress to controlling the cube with serial data instead of parallel data. This will mean using shift registers or LED driver. I did an instructable about converting parallel to serial with shift registers, it might be useful http://www.instructables.com/id/4x4x4-LED-cube-upgrade-with-Shift-Registers-74hc5/

You may want to charlieplex your cube, this will probably reduce the number of pins to where you can control it with a mega. By my calculations you will need a minimum of 24 pins to control 512 LEDs using charlieplexing. Charlieplexing is a bit difficult because it requires that some LEDs face one way, while others need to face another way, so building is a little more difficult. It also takes advantage of tri-state micro-controllers, so programming is a bit more difficult too.

Besides Persistance of Vision, and Multiplexing, you also need to think about duty cycle. If you have a 4x4x4 cube, you will have a 25% duty cycle (no LEDs will be on longer than 1/4 of the time), with an 8x8x8 you usually have a 12.5% duty cycle which may make things dramatically dimmer than you think. If you split your planes into 2 planes of 32 LED, then you will have a 6.25% duty cycle, pretty low! That may not work out too well, it would be best to test that before building 500 LED cube.

The other real problem with spliting the plane is that each plane creates dimensional stability, if you split the plane, you are splitting the cube into 2 rectangles that may not be as dimensionally stable.

There are many ways to skin that cat, and I've just mentioned the more common ways that I have seen.

You might want to look at the MAX7219 chip. That multiplexes 64 LEDs:

It's not particularly cheap, from memory, but it could save you buying a lot of transistors and current-limiting resistors.

The chip does its own current limiting, and its own multiplexing. Since it uses SPI you could add additional chips, using only one extra SS line for each additional chip.

My personal advice would be to start smaller initially, just get comfortable with coding on this platform, using LEDs, resistors, current flows etc.

Hi Guys!

First of all, thank you for your replies!

I've read the suggested articles. The one that has really caught my attention is this one:

It's a very good explanation of how the MAX7219 chip can be used to drive a 8x8 LED matrix relatively easily. This is not the first time I've read about the MAX72XX chips, but the articles I have found in the past were not as friendly as this one and they did not explain how to program the MAX72XX chips, so I just threw that information away because I did not really understand it. Now, on the other hand, I think I do understand it. The wiring diagram is pretty clear and also the programming examples are easy to understand.
I did a quick search on eBay and found that you can buy 10 pieces of MAX7219 for about 5$, which is quite cheap. I'm very tempted to go for this approach.

Starting out with a smaller LED cube (3x3x3 to 5x5x5) is probably good for practice and I'll probably regret not taking your advice and doing it, but somehow I feel that 'll go straight for the 8x8x8. First of all, creating a bigger LED cube (just the LED cube, not the additional electronics) is just a matter of exponentially more soldering, right? Second of all, the MAX7219 is designed to drive exactly 8x8 LEDs which are exactly the number of LEDs needed in one layer of my 8x8x8 cube, so why not go for the real thing from start? If at this point you feel that I'm making a huge mistake and that there are a lot of problems with a big cube and that I need to experience some failures with a smaller cube first, please outline a few of those, maybe I'm not seeing something important here after all...

OK, so let's assume for a second that I'll build that 8x8x8 cube (sooner or later I will, I hope :slight_smile: ). Let's also assume that I'll use MAX7219 chips to drive the LEDs and to make my life easier :slight_smile: I have a few questions related to this solution:

  1. What would you recommend to consider a layer in the cube? Would you drive each horizontal plane of the cube (8x8) with a MAX7219 or would you drive each vertical plane which faces the "front" of the cube with one MAX7219. In other words, would you divide the cube into layers horizontally or vertically? This is an important question. If one would like to display text (letters) in the cube, which face the "front" side of the cube, programming would become a lot easier if the layers were vertical. On the other hand, for generic animations, I get the feeling that dividing the cube into horizontal layers would be more practical...
  2. The following wiring diagram: http://www.gammon.com.au/images/BL-M12A881_e.png shows that 3 pins are used from the Arduino to communicate with the MAX7219: MOSI (D11), SCK (D13) and SS (D10). Now this is great if you only have one layer of 8x8 LEDs. But I need 8. Which additional pins would I use in this case? I get the feeling that pins D11, D13 and D10 are part of some special group on the Arduino and that they are used for some special protocol. If so, how could I use 8 groups of 3 pins to communicate with 8 MAX7219 chips?
  3. Again, using 8 layers (8 MAX7219 chips), how would I need to modify the code from the article to talk to each of the MAX7219 chips? When you have only one layer (one chip), the code looks like this:
void sendByte (const byte reg, const byte data)
  {    
  digitalWrite (SS, LOW);
  SPI.transfer (reg);
  SPI.transfer (data);
  digitalWrite (SS, HIGH); 
  }  // end of sendByte

How would I modify this to be able to talk to the layer (MAX7219) of my choice?

I'm also thinking about whether I should use standard clear white LEDs or diffused ones. retrolefty pointed out that diffused ones look much better when turned on. I've never actually seen a diffused LED until now, but I believe you :slight_smile: However, clear LEDs are brighter (is that good or bad?) and look a lot more elegant when turned off. Also, I'm thinking that the luminous flux of standard clear LEDs is usually higher, so maybe I can drive them with less current (as I wrote, in my experience 1 mA is more than enough when continuously lit, but multiplexing might make a difference). Luckily the MAX7219 chips need a single resistor to specify the current running through all the 64 LEDs, so I'll only need a total of 8 resistors for this purpose in the entire cube. I'll add lower value resistors calculated for 20 mA through the LEDs and I'll add variable resistors in series with the regular ones, to be able to modify the LED currents and turn them down to 1 mA. How the resistor value can be calculated for a given current value, I don't know. I've seen some tables somewhere, but those tables were only considering current values of 20 mA and 10 mA, they never went down to 1 mA...

What would you recommend to consider a layer in the cube?

Can't you just turn the cube? If not, I would probably have a layer be one letter (depending which way the letters are going to face). It's probably not critical.

But I need 8. Which additional pins would I use in this case?

You parallel up MOSI and SCK for all 8 chips. Then you use one SS line for each chip (ie. pins 10, 9, 8, 7, 6, 5, 4, 3). However looking at the datasheet the chip has a DOUT pin (pin 24) which is for daisy-chaining.

What you could possibly do (although I haven't tested this) is to parallel up SCK and SS, and then feed DOUT from the first chip to DIN on the second (and so on for second to third, etc.). Then you could use just 3 wires for the entire lot.

You would then bring SS low, clock out all the bytes and bring SS high to latch the lot. The datasheet says "The last 16 bits of serial data are latched on CS’s rising edge.".

So, you send out 16 bits (2 bytes). It goes into the first chip. Keeping SS low, you send another 16 bits. The first 16 leave the first chip and get clocked into the second. Then you do the third 16 bits. Now the bits end up in the third chip. And so on. So 16 bytes later (16 x SPI.transfer) you have set up one row for each of the 8 chips. Then you latch, and that row gets committed. Repeat for the next row, and so on.

I haven't tried that (I don't have enough patience) but clearly the design is supposed to allow for that. Effectively you could set up any number of chips in sequence like that, but only need 3 data lines from the processor, no doubt which is what they intended.

Again, using 8 layers (8 MAX7219 chips), how would I need to modify the code from the article to talk to each of the MAX7219 chips?

As I described above.

What would you recommend to consider a layer in the cube?

You probably set up in memory the bit pattern for all 512 bits anyway in an array. How they are physically wired is not critical, it would just be whether you go through the array X direction first or Y direction first.

Thank you for this information! :slight_smile:

I have found another article somewhere (Arduino Playground - MAX72XXHardware) which seems to confirm what you just mentioned:

  • Parallel the CLK and CS(Load) for all the MAX7219 chips (I guess we also call these two SLK and SS)
  • Take the DOUT from one chip to the DLN of the next chip

And using just 3 wires to communicate with the whole thing? Wow, that's impressive!

There's one thing I'm not sure I understand in your explanation about how to program the whole batch of chips. You say that if I send packages of 16 bits multiple times, the bits are pushed from the nearest chip to the next one every time a new package is sent while SS is kept low. This is clear and wonderful. But you also wrote "Then you latch and that row gets committed". What does it mean to latch?
Sorry if I ask such beginner questions, but as I wrote, my knowledge in this area is merely starting to develop and I'm having a hard time understanding some of the basics...

As for how to divide the cube into layers, I guess you are right, it doesn't really matter that much, the software can handle it either way.

I don't really where to buy the MAX7219 chips from. As I wrote earlier, I found them on eBay, where you can buy 10 pieces for 5$. That would be nice, but I've read that they are not original and that must be true because Maxim is selling them for a lot more. I've also checked them in a local electronics parts store and here I could buy original ones, 10 pieces for 40$... I wonder if it's worth buying the original ones...

Thank you!

I've juts realized that the fact that driving the LEDs with MAX7219 chips in such a simple and elegant fashion has a price to be paid during construction of the LED cube. If I drive each horizontal plane of 8x8 LEDs with one MAX7219, I'll need to have 16 wires go to each horizontal plane, I no longer have the advantage of connecting the vertical legs of each column together and sending signals through that... It's going to get ugly... :frowning:

Un4Seen:
But you also wrote "Then you latch and that row gets committed". What does it mean to latch?

When you bring CS (chip select) high the data is latched. That is, it is transferred from internal holding registers to the actual chip outputs, connected to the LEDs. Until it is latched you don't see it, so you don't notice the data being pushed from one chip to the next one, it is all internal.

Un4Seen:
If I drive each horizontal plane of 8x8 LEDs with one MAX7219, I'll need to have 16 wires go to each horizontal plane, I no longer have the advantage of connecting the vertical legs of each column together and sending signals through that... It's going to get ugly... :frowning:

I don't see how you can individually control 64 LEDs with less than 16 wires unless you use Charliplexing maybe, but that could be a bit difficult for 512 LEDs. Plus you need the 512 resistors then.

On this diagram for the 8x8 LED:

On the right, notice how 8 anodes are connected together and 8 cathodes? It will be tedious wiring 512 LEDs whatever way you look at it, but only 16 wires isn't too bad.

So why not stick with your original plan:
64 cathode drivers, and 8 anode drivers.
Can be done with 9 TPIC6B595 shift registers and 8 PNP or p-channel MOSFETs.
8 of the 6B595's will drive the cathodes.
Each bit of the 9th 6B595 will be used to pull the Base/Gate of the Anode transistor low to turn the part on, pullup resistor pulls it high to turn it off.
83 cents each at avnet.com
Have to play with the timing, see if 9 SPI transfers will do it, or if need to turn the anode off, drive the cathodes, and then turn the next anode on to prevent ghosting. 9 SPI tranfers or 11, quick either way.
Lots of time available while watching millis() go by to update the 64 bytes that hold the array information.

This board I sell will hold all the shift registers, you can not populate the '328 part of it and feed in your SPI controls signals from your Mega if you wanted to.
They're all daisy chained, so you couldn't easily split the transistor driver from the other drives.

I used 2 of them, 10 shift registers each card, just passing power and the control signals along to the 2nd card, to drive this 5x20 display with no multiplexing:

Thank you again for your replies!

Nick Gammon, in a theoretical sense you are right that 16 wires to drive 64 LEDs is pretty good. However, the LED cube is all about being able to see through it, about being elegant, about not seeing wires... I was thinking that I could cheat out half of the wires by dividing the cube not into horizontal, but vertical planes. Each MAX7219 would drive a vertical plane. This way 8 legs (all anodes or all cathodes) would go directly into the PCB beneath the cube, so only an additional 8 wires would have to crawl up along the edges of the plane. Dividing it equally, I could manage with 4+4 wires. Maybe I can buy some very thin wires and it would look nice. I wonder how thin is not too thin. I'm thinking that the resistance of the wires might matter...

CrossRoads, your idea is also tempting because I could create a cleaner (wire-free) and more robust cube. It also has the advantage that the cube would be made only by soldering LED legs together, as opposed to the MAX7219-based solution where I would have to find a way to make the cube more rigid by adding some non-conducting sticks between the planes, to hold them together. That would probably mean glueing.
What did you mean by "Lots of time available while watching millis() go by to update the 64 bytes that hold the array information." Were you suggesting that in the MAX7219-based approach needs a lot of time to fill up the registers?

You also wrote this:
"64 cathode drivers, and 8 anode drivers.
Can be done with 9 TPIC6B595 shift registers and 8 PNP or p-channel MOSFETs.
8 of the 6B595's will drive the cathodes.
Each bit of the 9th 6B595 will be used to pull the Base/Gate of the Anode transistor low to turn the part on, pullup resistor pulls it high to turn it off."
Is there a place I could find an exact wiring diagram for this? What about an example on how to program it?

As I wrote, I really am an amateur with high aspirations (the 8x8x8 LED cube). I'm struggling really hard to understand the answers you guys give me :slight_smile: Because of this the MAX7219-based solution is more appealing to me. The chip takes care of LED currents, of multiplexing the LEDs. Also less components, less room for error. The only two problems with it are the price and the wires that would make the cube look less aesthetic... Because of this I'd like to try to understand the other solution too, with TPIC6B595 shift registers, but I need some diagrams and some programming example to see if I can work with it.

I really do appreciate your answers. Thank you!
Andras

How's this for a start?

It looks understandable enough :slight_smile: Thank you!
A few questions, though:

  1. The micro controller on the left would be an Arduino. How would that be connected to the TPIC6B595s? Which Arduino pin would be connected to which pin of the shift registers?
  2. For the 64 coulmns 8 pieces of TPIC6B595 are needed. In your diagram I see that pin 18 of each shift register goes to the next shift register. But to which pin of the next shift register?
  3. Which input pins of the TPIC6B595s would be used and how exactly (how would they be connected to the Arduino and how would the 8 column driving shift registers be connected to each other) (In a sense this extends question 2).
  4. For the 8 layers I would need 8 transistors. If I understand correctly, this is the part of the circuit which decouples the low currents used to get signals from the Arduino to the LEDs from the high currents that actually pass through the LEDs. You wrote above the diagram that each transistor must be able to handle 6420 mA (makes sense as it switches 64 LEDs in a layer). Is there some packaged chip like the ULN2809 for example which could handle the whole cube (I mean that it contains 8 transistors, each capable of handling 6420 mA)? If not what kind of transistor can do the job?
  5. These shift registers don't do multiplexing. Does this mean that the multiplexing will have to be done from software?
  6. How would you switch LEDs on/off with this hardware approach? How would you send data to the shift registers?

Thank you!
Andras

I'm wondering about what 5V power supply to get for powering the cube...
What would be the maximum current consumption of the two solutions when all the LEDs are turned on at full brightness (assuming we give each LED 20 mA of current)?

With the MAX7219 I saw something in the datasheet that it consumes 330 mA, but I wonder if that includes the current consumption of the 64 LEDs it drives or it consumes 330 mA by itself...

Any useful tips regarding the power supply?

Thanks,
Andras

1,2, 3: Yes, an Arduino. Connections would be via SPI as I previously described.
Specifically: D13/SCK to SRCK on all chips
D11/MOSI to SerDataIn on 1st chip, then SerOut goes to SerDataIn down the chain
D10/SS to RCK on all chips
SerClr/ to +5 on all chips
OE/ to Gnd on all chips. You could also experiment with connecting to a PWM output for dimming.
4. 64 * 20mA = 1.28A. I don't know of a PNP equivalent to ULN2803 that can do this.
I would suggest a P-channel MOSFET such as this

I also realize some resistors are missing. See corrected shematic below.
5. Yes, software does the multiplexing as I described earlier; one layer's transistor is turned on at a time while the cathodes are pulled low for on, and not for off.
Having each layer on for 4mS would yield about a 30Hz refresh rate. Better results may be seen if the transistor shift register is seperately written from the cathode shift register, have to experiment some & see.
6. I would keep the image of the cube in a 64 byte array, writing out 8 bytes at a time for a layer using SPI.

Cube would use 1.28A if a layer was turned full on at 20mA. 5V, 2A supply would be sufficient
http://www.dipmicro.com/store/DCA-0520

I suppose one could also use 4x TLC5940 or 4XWS2803 for the cathodes, and have PWM capability per channel. Have to send out more data tho, at least a full byte per column for 256 level brightness control. Vs just 8 bytes per layer & on/off only.

MAX7219, controls both the anodes & cathode, haven't thought of a way to multiplex that. Would think something like 8 transistors between MAX7219 and the anodes, or cathodes, of each layer to be able to isolate the control for that layer? Then have to control turning layers on/off in software and writing out data for each layer in software.

A lot clearer now. Thank you!
What is the role of those resistors that you have newly added and what would their value be?

Now that I think I'm very close to fully understanding both the TPIC6B595-based solution and the MAX7219-based solution I'm trying to evaluate the advantages and disadvantages of both:

  1. The TPIC6B595 solution would only require a 2A power supply because the total theoretical current consumption is only 1.28A. The MAX7219-based solution needs at least 8x330 mA (2.64 A), so I'd probably need at least a 3A power supply, which are harder to come by.
  2. The TPIC6B595 solution has cosiderably more components, it's easier to make a mistake and the software multiplexing must be bulletproof, otherwise it could accidentally turn on all layers, leading to a current consumption of 8x1.28 A. Software multiplexing would of course complicate the code in unnecessary ways, compared to the MAX7219 solution which only needs the bytes to be sent via SPI.
  3. The MAX7219 solution is expensive, the TPIC6B595 is magnitudes cheaper.
  4. The MAX7219 solution requires some additional wires to crawl up to all LED planes, making the construction a bit uglier, but I could come around that by putting the wires into two sets of 8 additional columns in the cube (with no LEDs, just wires). MAybe it would look acceptable. The TPIC6B595 solution solves this problem in a natural way by allowing the current to travel up the cathodes of the LEDs soldered together in 64 distinct columns.
  5. The MAX7219 solution would make it easier to solder the LEDs together because the 8 distinct levels (planes) would need no contact. I could just add some non-conducting sticks in the end among these 8 distinct planes to make the structure more robust. For the TPIC6B595 solution, on the other hand, it's needed to solder all the LEDs together (cathodes to cathodes in 64 unconnected columns and anodes to anodes in 8 unconnected planes). Makes the soldering trickier.

Are there any other pros/cons for these two solutions that I don't see?

Thank you!
Andras

I disagree with many of your assumptioms.

  1. MAX7219 multiplexes 64 digits. It has no more than 8 LEDs on at a time, thus not much more than 160mA if 20mA/LED is being used.
    Additionally, 5V/4A supply is easy to find - I use this one in several projects
    5V 4A Power Adapter OPENPEAK OP-20004
    For my 8x32 display using 4 of MAX7219 and a Duemilanove, a 9V, 1A supply was used, drawing under 1A of power as all 5V current went thru the onboard regulator.
  2. More components, yes, but easier to assemble LED cube as all columns are connected, and all Layers are connected, thus just 8 wires need to be hidden away. With non-multiplexed MAX7219, need isolated layers and 16 wires per layer.
  3. MAX7219 is $1.25/chip from taydaelectronics.com. TPIC6B595 is 83 cents from avnet.com, plus PNP or P-channel MOSFETS. Seems comparable when totalled.
  4. Agree with you on wiring. Don't know how you solve the cube stability while maintaining layer isolation.
  5. There are many examples of LEDs cubes. The soldering together is less tricky than you think, there is just a lot of it. Here is one of the best writeups I have seen.
    http://www.jameco.com/Jameco/workshop/JamecoBuilds/4x4x4ledcube.html