8X8X8 LED Cube - What Data Structure to Use?

Hey all,

So I have decided to make an 8X8X8 led cube. here is what i have going for me already. I have 8 MAX7219 that i am going to use to control each of the 8 - 8X8 layers of with cube. I have already done a few projects with the MAX7219's so i am familiar with the programming, wiring and such for these chips. My question lies in the "which data structure should i use" category. I know there are 512 LEDS, or 64 bytes of data. if i were to keep track of all the leds for each change of the system, just to cycle thur all the leds one time would take about 32k of space to store this info and that doesn't include the timing information. As i am using the original Arduino Mega, I don't have this sort of memory to store these light patterns. so much for my first idea. My second idea is to just track the led's that are changing. like a coordinate system (x,y,z), which would need only 9 bits. This would leave me 7 bits to hold the timing information and if it is on or not. so recrunching the number for the above example of cycling thru the LEDs is now 3k. It is TON better as far as space, but again, with a Flash Memory of 128 KB (of which 4 KB used by bootloader), SRAM of 8 KB and EEPROM of 4 KB, i will still only be able to store one pattern. and i am not even talking about a complex one either. Am i attacking this the wrong way???

              O-O-O-O-O-O-O-O
             / / / / / / / /| 
            O-O-O-O-O-O-O-O O
           / / / / / / / /|/|
          O-O-O-O-O-O-O-O O O
         / / / / / / / /|/|/|
        O-O-O-O-O-O-O-O O O O
       / / / / / / / /|/|/|/|
      O-O-O-O-O-O-O-O O O O O
     / / / / / / / /|/|/|/|/|
    O-O-O-O-O-O-O-O O O O O O
   / / / / / / / /|/|/|/|/|/|
  O-O-O-O-O-O-O-O O O O O O O
 / / / / / / / /|/|/|/|/|/|/|
O-O-O-O-O-O-O-O O O O O O O O
|/|/|/|/|/|/|/|/|/|/|/|/|/|/|
O-O-O-O-O-O-O-O O O O O O O
|/|/|/|/|/|/|/|/|/|/|/|/|/|
O-O-O-O-O-O-O-O O O O O O 
|/|/|/|/|/|/|/|/|/|/|/|/|
O-O-O-O-O-O-O-O O O O O 
|/|/|/|/|/|/|/|/|/|/|/|
O-O-O-O-O-O-O-O O O O 
|/|/|/|/|/|/|/|/|/|/|
O-O-O-O-O-O-O-O O O
|/|/|/|/|/|/|/|/|/|
O-O-O-O-O-O-O-O O
|/|/|/|/|/|/|/|/|
O-O-O-O-O-O-O-O
| | | | | | | |

I know there are 512 LEDS, or 64 bytes of data.

If you save off/on as one bit, yes.

if i were to keep track of all the leds for each change of the system, just to cycle thur all the leds one time would take about 32k of space to store this info and that doesn't include the timing information.

I'm not following this leap. Why would you need 32k of space to store 64 bytes of data? Any given LED is either on or off.

So math time...so to do it the first way you would have 1 bit per led...so each played is 64 bit or 8 bytes and then we have 8 layer...64 bytes. To light one led...turn it off, then move to the next led for 512 LEDs is a total of 32k for the one pattern

To light one led...turn it off, then move to the next led for 512 LEDs is a total of 32k for the one pattern

Only if, for some reason, you need to save the state independently each time you change the state of one LED. It is that premise that I do not accept.

That would only be more logical if I was changing a massive amount of LEDs at once...I only used that example as a base line to do a calculation...and note I vetoed that idea pretty quick and moved on to the next idea...so do u have any suggestions other than the 2 ideas I had???

So math time...so to do it the first way you would have 1 bit per led...so each played is 64 bit or 8 bytes and then we have 8 layer...64 bytes. To light one led...turn it off, then move to the next led for 512 LEDs is a total of 32k for the one pattern

Whether you change one LED or all 512 at the same time the data still only takes up 64 bytes at one bit per LED. You seem to be suggesting that you need to hold 512 different sets of 64 bytes in order to light 1 LED after another. That is not the case.

Change the pattern in the 64 bytes to the next pattern to be displayed, then display it Use an algorithm to change the required bits and you still only need 64 bytes in total.

Typically a popular structure to use in led cubes is to keep the led data in separate levels, so for a 8x8x8 you would need eight long- long variables (64 bit variables) to store the led data. That way you can transfer a level at a time to the shift registers that drive the 64 columns and then enable one of the either level drivers.

Lefty

I think you're confusing the data structure used to represent the LEDs (which is almost certainly that 64byte array), with the data structure and algorithms used to "set" a pattern in the LED data structure. To make one "ON" LED at a time, it would be sufficient to have three "nybbles" (or bytes, to make it easier) of data representing the LED that you want to be ON, and you could do arbitrary patterns of one LED on all 64 LEDs with 64*3 bytes of data. If you can describe how the LED moves algorithmically, that might consume less (or more.) You can also consider storing your patterns as lines (two points), or blocks, or whatever...

Don't forget that patterns can be stored in FLASH; you don't need to have them in RAM.

westfw:
ITo make one "ON" LED at a time, it would be sufficient to have three "nybbles" (or bytes, to make it easier) of data representing the LED that you want to be ON, and you could do arbitrary patterns of one LED on all 64 LEDs with 64*3 bytes of data.

I agree with the nybbles...the first way means the pattern would be like:

{B10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, 
B01000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, 
B0010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000,

Just as an example...but with the nybbles...i can even crunch it down into 2 bytes instead of 3bytes

[ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 ] [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 ] 
[  X-Axis   |  Y-Axis   |   Z-Axis    |        Duration       |   ] <-- State (On/Off)

here is how i figure it:

X-Axis 0-7 3 Bits
Y-Axis 0-7 3 Bits
Z-Axis 0-7 3 Bits
Duration
Will be multiplied by 50
0-64 6 Bits
State 0-1 1 Bits

so with this i can hold 1 toggle instruction in 2 bytes. So if i wanna turn the whole thing on, I would need 512 instructions, or 1 KB of data...am i right??? so to turn on one layer, it would be more like:

B0000000000000001,B0000000010000001,B0000000100000001,B0000000110000001,B0000001000000001,B0000001010000001,B0000001100000001,B0000001110000001,
B0000010000000001,B0000010010000001,B0000010100000001,B0000010110000001,B0000011000000001,B0000011010000001,B0000011100000001,B0000011110000001,
B0000100000000001,B0000100010000001,B0000100100000001,B0000100110000001,B0000101000000001,B0000101010000001,B0000101100000001,B0000101110000001,
B0000110000000001,B0000110010000001,B0000110100000001,B0000110110000001,B0000111000000001,B0000111010000001,B0000111100000001,B0000111110000001,
etc...

but that to me still take up a shit ton of memory...does it not??? has anyone else made a cube this big with stored patterns?

So if i wanna turn the whole thing on, I would need 512 instructions, or 1 KB of data...am i right???

Only if you insist on holding the patterns instead of generating them as needed.

Have a look at Kevin Darrah's you tube site he has 8x8x8 rgb cube

http://www.kevindarrah.com/

At some point you want to think about designing your own "drawing instruction set"

POINT val,X, Y, Z
XLINE val,Y,Z
YLINE val,X,Z
ZLINE val, X,Y
XYPLANE val,Z
YZPLANE val,X
XZPLANE val, Y
ALL val
DELAY n

I can still do special instructions and still keep the 2 bytes per instructions...i have done this on other systems where space/bandwidth needs to be conserved...so here is my idea for that

[ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 ] [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 ] 
[    Type   |                   Instruction Data                  ]

Type		Name			Parms (Bits:Parm:[Notes], Bits:Parm:[Notes], Etc)
0		Delay			7:Multiplier, 6:Duration:In ms
1		Single			1:State:On/Off, 3:X-Axis, 3:Y-Axis, 3:Z-Axis, 3:Delay:Multiplied By 50 - in ms - Used as minor delay
2		Row			1:State:On/Off, 2:Axis, 7:Location:8x8 grid on that side - 64 locations, 3:Delay:Multiplied By 50 - in ms - Used as minor delay
3		Layer			1:State:On/Off, 2:Axis, 3:Location:8 different locations, 7:Delay:Multiplied By 50 - in ms - Used as minor delay
4		Random Single		1:State:On/Off, 12:Delay:Multiplied By 50 - in ms - Used as minor delay
5		All			1:State:On/Off, 12:Delay:Multiplied By 50 - in ms - Used as minor delay
6		Intensity		5:level:max7129 allows 16 levels by the chip, 1:All Layers:1=yes 0=no, 3:Layer:8 layers, 4:Delay:Multiplied By 50 - in ms - Used as minor delay
7		AND I WILL STILL HAVE ONE TO USE

so give you 8 different instruction types...if i take 1 bit of the aux delays on 2 - 6, you can up it to 16 instructions. but I couldn't come up with any others...i think i might have to make separate functions for each pattern...limit them to like 600 instructions at the time...so there might be multiple functions for each pattern...that would make it so it doesn't exceed the 2k ram...i also might do function based patterns to...like random LED changing for 20 seconds...or the falling rain ones...those might be better as dynamics functions rather than set patterns...combine both and TADA!!!

what u guys think