LED Cube 8x8x8

• Basic electronics. (We would recommend against building this as your very first electronics project. But please read the Instructable. You'll still learn a lot!)
• How to solder.
• How to use a multimeter etc.
• Writing code in C (optional. We provide a fully functional program, ready to go)

• 512x  LEDs (plus some extra for making mistakes!)
• 64x resistors. (see separate step for ohm value)
• 1x or 2x large prototype PCBs. The type with copper "eyes", see image.
• 1x ATmega32 microcontroller (you can also use the pin-compatible ATmega16)
• 3x status LEDs. You choose color and size.
• 3x resistors for the status LEDs.
• 8x 74HC574 ICs
• 16x PN2222 transistors
• 16x 1k resistors
• 1x 74HC138 IC
• 1x Maxim MAX232 IC
• 1x 14.7456 MHz crustal
• 2x 22pF ceramic capacitors
• 16x 0.1uF ceramic capacitors
• 3x 1000uF electrolytic capacitor
• 3x 10uF electrolytic capacitor
• 1x 100uF electrolytic capacitors
• 8x 20 pin IC sockets
• 1x 40 pin IC socket
• 2x 16 pin IC socket
• 1x 2-pin screw terminal
• 1x 2wire cable with plugs
• 9x 8-pin terminal pins
• 1x 4-pin terminal pins, right angle
• 2x 16-pin ribbon cable connector
• 1x 10-pin ribbon cable connector
• Ribbon cable
• 2x pushbuttons
• 2x ribbon cable plugs
• 9x 8-pin female header plugs
• Serial cable and 4pin female pin header
• Piece of wood for template and base
• 8x optional pull-up resistors for layers
• 5v power supply (see separate step for power supply)

We gathered from the last step that an 8x8x8 LED cube requires 64+8 IO lines to operate. No AVR micro controller with a DIP package (the kind of through hole chip you can easily solder or use in a breadboard, Dual Inline Package) have that many IO lines available.

To get get the required 64 output lines needed for the LED anodes, we will create a simple multiplexer circuit. This circuit will multiplex 11 IO lines into 64 output lines.

The multiplexer is built by using a component called a latch or a flip-flop. We will call them latches from here on.

This multiplexer uses an 8 bit latch IC called 74HC574. This chip has the following pins:

• 8 inputs (D0-7)
• 8 outputs (Q0-7)
• 1 "latch" pin (CP)
• 1 output enable pin (OE)

The job of the latch is to serve as a kind of simple memory. The latch can hold 8 bits of information, and these 8 bits are represented on the output pins. Consider a latch with an LED connected to output Q0. To turn this LED on, apply V+ (1) to input D0, then pull the CP pin low (GND), then high (V+).

When the CP pin changes from low to high, the state of the input D0 is "latched" onto the output Q0, and this output stays in that state regardless of future changes in the status of input D0, until new data is loaded by pulling the CP pin low and high again.
To make a latch array that can remember the on/off state of 64 LEDs we need 8 of these latches. The inputs D0-7 of all the latches are connected together in an 8 bit bus.

To load the on/off states of all the 64 LEDs we simply do this: Load the data of the first latch onto the bus. pull the CP pin of the first latch low then high. Load the data of the second latch onto the bus. pull the CP pin of the second latch low then high. Load the data of the third latch onto the bus. pull the CP pin of the third latch low then high. Rinse and repeat.

The only problem with this setup is that we need 8 IO lines to control the CP line for each latch. The solution is to use a 74HC138. This IC has 3 input lines and 8 outputs. The input lines are used to control which of the 8 output lines that will be pulled low at any time. The rest will be high. Each out the outputs on the 74HC138 is connected to the CP pin on one of the latches.

The following pseudo-code will load the contents of a buffer array onto the latch array:

// PORT A = data bus
// PORT B = address bus (74HC138)
// char buffer[8] holds 64 bits of data for the latch array

PORTB = 0x00; // This pulls CP on latch 1 low.
for (i=0; i < 8; i++)
{

PORTA = buffer[i];
PORTB = i+1;

}

The outputs of the 74HC138 are active LOW. That means that the output that is active is pulled LOW. The latch pin (CP) on the latch is a rising edge trigger, meaning that the data is latched when it changes from LOW to HIGH. To trigger the right latch, the 74HC138 needs to stay one step ahead of the counter i. If it had been an active HIGH chip, we could write PORTB = i; You are probably thinking, what happens when the counter reaches 7, that would mean that the output on PORTB is 8 (1000 binary)on the last iteration of the for() loop. Only the first 8 bits of PORT B are connected to the 74HC138. So when port B outputs 8 or 1000 in binary, the 74HC138 reads 000 in binary, thus completing its cycle. (it started at 0). The 74HC138 now outputs the following sequence: 1 2 3 4 5 6 7 0, thus giving a change from LOW to HIGH for the current latch according to counter i.

• data
• clock

PORTB = 0x00; // Pull the clock line low, so we can pull it high later to trigger the shift register
PORTA = buffer[i]; // Load a byte of data onto port A
PORTB = 0x01; // Pull the clock line high to shift data into the shift registers.

• cut of the length of wire you need from the spool, plus an inch or two.
• Remove the insulation, if any.
• Get a firm grip of each end of the wire with two pairs of pliers
• Pull hard!
• You will feel the wire stretch a little bit.

• (14.7456MHz*1000*1000) / 9600 baud = 1536.0
• (14.7456MHz*1000*1000) / 19200 baud = 768.0
• (14.7456MHz*1000*1000) / 38400 baud = 384.0
• (14.7456MHz*1000*1000) / 115200 baud = 128.0

• A ribbon cable for the DATA and Address BUS.
• A 2 wire cable for GND and VCC.

• avrdude -c usbtiny -p m32 -U lfuse:w:0b11101111:m
• avrdude -c usbtiny -p m32 -U hfuse:w:0b11001001:m

• avrdude -c usbtiny -p m32 -B 1 -U flash:w:test.hex

• avrdude -c usbtiny -p m32 -B 1 -U flash:w:main.hex

• avrdude -c usbtiny -p m32 -B 1 -U eeprom:w:main.eep

When we first started writing effects and debugging them, we noticed that the functions using random numbers displayed the exact same animations every time. It was random alright, but the same random sequence every time. Turns out the random number generator in the ATmega needs to be seeded with a random number to create true random numbers.

We wrote a small function called bootwait(). This function serves two purposes.

1) Create a random seed. 2) Listen for button presses to select mode of operation.

It does the following:

1) Set counter x to 0.

2) Start an infinite loop, while(1).

3) Increment counter x by one.

4) Use x as a random seed.

5) Delay for a while and set red status led on.

6) Check for button presses. If the main button is pressed, the function returns 1. If the PGM button is pressed it returnes 2. The return statements exits the function thus ending the infinite loop.

7) Delay again and set green led on.

8) Check for button presses again.

9) Loop forever until a button is pressed.

The loop loops very fast, so the probability that you will stop it at the same value of x two times in a row is very remote. This is a very simple but effective way to get a good random seed.

Bootwait() is called from the main() function and its return value assigned to the variable i.

If i == 1, the main loop starts a loop that displays effects generated by the ATmega. If i == 2, it enters into RS232 mode and waits for data from a computer.

The heart of the LED cube code is the interrupt routine.

Every time this interrupt runs, the cube is cleared, data for the new layer is loaded onto the latch array, and the new layer is switched on. This remains on until the next time the interrupt runs, where the cube is cleared again, data for the next layer is loaded onto the latch array, and the next layer is switched on.

The ATmega32 has 3 timer/counters. These can be set to count continuously and trigger an interrupt routine every time they reach a certain number. The counter is reset when the interrupt routine is called.

We use Timer2 with a prescaler of 128 and an Output Compare value of 10. This means that the counter is incremented by 1 for every 128th cpu cycle. When Timer2 reaches 10, it is reset to 0 and the interrupt routine is called. With a cpu frequency of 14745600 Hz, 128 prescaler and output compare of 10, the interrupt routine is called every 1408th CPU cycle (128*11) or 10472.7 times per second. It displays one layer at a time, so it takes 8 runs of the interrupt to draw the entire cube once. This gives us a refresh rate of 1309 FPS (10472.7/8). At this refresh rate, the LED cube is 100% flicker free. Some might say that 1300 FPS is overkill, but the interrupt routine is quite efficient. At this high refresh rate, it only uses about 21% of the CPU time. We can measure this by attaching an oscilloscope to the output enable line (OE). This is pulled high at the start of each interrupt and low at the end, so it gives a pretty good indication of the time spent inside the interrupt routine.

Before any timed interrupts can start, we have to set up the Timer 2. This is done in the ioinit() function.

TCCR2 (Timer Counter Control Register 2) is an 8 bit register that contains settings for the timer clock source and mode of operation. We select a clock source with a 1/128 prescaler. This means that Timer/counter 2 is incrementet by 1 every 128th CPU cycle.

We set it to CTC mode. (Clear on Timer Compare). In this mode, the counter value TCNT2 is continuously compared to OCR2 (Output Compare Register 2). Every time TCNT2 reaches the value stored in OCR2, it is reset to 0 and starts counting from from 0. At the same time, an interrupt is triggered and the interrupt routine is called.

For every run of the interrupt, the following takes place:

1) All the layer transistors are switched off.

2) Output enable (OE) is pulled high to disable output from the latch array.

3) A loop runs through i = 0-7. For every pass a byte is outputed on the DATA bus and the i+1 is outputed on the address bus. We add the +1 because the 74HC138 has active low outputs and the 74HC574 clock line is triggered on the rising edge (transition from low to high).

4) Output enable is pulled low to enable output fro the latch array again.

5) The transistor for the current layer is switched on.

6) current_layer is incremented or reset to 0 if it moves beyond 7.

That's it. The interrupt routine is quite simple. I'm sure there are some optimizations we could have used, but not without compromising human readability of the code. For the purpose of this instructable, we think readability is a reasonable trade-off for a slight increase in performance.

There are three main reasons for doing this.

Memory footprint

The easiest way to address each voxel would be through a three dimensional buffer array. Like this:

unsigned char cube[x][y][z]; (char means an 8 bit number, unsigned means that it's range is from 0 to 255. signed is -128 to +127)

Within this array each voxel would be represented by an integer, where 0 is off and 1 is on. In fact, you could use the entire integer and have 256 different brightness levels. We actually tried this first, but it turned out that our eBay LEDs had very little change in brightness in relation to duty cycle. The effect wasn't noticeable enough to be worth the trouble. We went for a monochrome solution. On and off.

With a monochrome cube and a three dimensional buffer, we would be wasting 7/8 of the memory used. The smallest amount of memory you can allocate is one byte (8 bits), and you only need 1 bit to represent on and off. 7 bits for each voxel would be wasted. 512*(7/8) = 448 bytes of wasted memory. Memory is scarce on micro controllers, so this is a sub-optimal solution.

Instead, we created a buffer that looks like this:

unsigned char cube[z][y];

In this buffer the X axis is represented within each of the bytes in the buffer array. This can be quite confusing to work with, which brings us to the second reason for making a library of low level drawing functions:

Code readability

Setting a voxel with the coordinates x=4, y=3, z=5 will require the following code:

cube[5][3] |= (0x01 << 4);

You can see how this could lead to some serious head scratching when trying to debug your effect code ;)

In draw.c we have made a bunch of functions that takes x,y,z as arguments and does this magic for you.

Setting the same voxel as in the example above is done with setvoxel(4,3,5), which is _a lot_ easier to read!

draw.c contains many more functions like this. Line drawing, plane drawing, box drawing, filling etc. Have a look in draw.c and familiarize yourself with the different functions.

Reusable code and code size

As you can see in draw.c, some of the functions are quite large. Writing that code over and over again inside effect functions would take up a lot of program memory. We only have 32 KB to work with. Its also boring to write the same code over and over again ;)

Now that we have a cube buffer and a nice little collection of low level draw functions to populate it, we need to agree on which ways is what, and what is up and what is down ;)

From now on, the native position of the LED cube will be with the cables coming out to the left.

In this orientation, the Y axis goes from left to right. The X axis goes from front to back. The Z axis goes from bottom to top.

Coordinates in this instructable is always represented as x,y,z.

Position 0,0,0 is the bottom left front corner. Position 7,7,7 is the top right back corner.

Why did we use the Y axis for left/right and X for back/front? Shouldn't it be the other way around? Yes, we think so too. We designed the the LED cube to be viewed from the "front" with the cables coming out the back. However, this was quite impractical when having the LED cube on the desk, it was more practical to have the cables coming out the side, and having cube and controller side by side. All the effect functions are designed to be viewed from this orientation.

for (i=0; i < EFFECTS_TOTAL; i++)
{

launch_effect(i);

}

launch_effect(rand()%EFFECTS_TOTAL);

Another simple effect, effect_planboing(int plane, int speed).

This effect draws a plane along the specified axis then moves it from position 0 to 7 on the axis and back again. This is very simple, but it really brings out the depth of the 3d LED cube :)

This function doesn't have an iteration loop. Instead it is called twice for each axis in launch_effect().

Here is what it does:

1) For()-loop i from 0 to 7.

2) Clear the cube with fill(0x00);

3) Call setplane() to draw a plane along the desired axis at position i. The plane isn't actually drawn on the axis specified, it is drawn on the other two axis. If you specify AXIS_Z, a plane is drawn on axis X and Y. It's just easier to think of it that way. Instead of having constants named PLANE_XY, PLANE_YZ etc.

4) Delay for a while.

5) Repeat the same loop with i going from 7 to 0.

Very simple, but a very cool effect!
 

This effect sends voxels up and down the Z axis, as the implies.

void sendvoxels_rand_z() takes three arguments. Iterations is the number of times a voxel is sent up or down. Delay is the speed of the movement (higher delay means lower speed). Wait is the delay between each voxel that is sent.

This is how it works:

1) The cube is cleared with fill(0x00);

2) Loop through all 64 positions along X/Y and randomly set a voxel at either Z=0 or Z=7.

3) Enter the main iteration loop

4) Select random coordinates for X and Y between 0 and 7. If the X and Y coordinates are identical to the previous coordinates, this iteration is skipped.

5) Check if the voxel at this X/Y coordinate is at Z=0 or Z=7, and send it to the opposite side using sendvoxel_z().

6) Delay for a while and save the coordinates of this iteration so we can check them against the random coordinates in the next iteration. It looked weird to move the same voxel twice in a row.

The actual movement of the voxels is done by another function, sendvoxel_z. The reason for this, is that a couple of other effects does the same thing only in different ways.

The function sendvoxel_z() takes four argument. X and Y coordinates. Z coordinate, this is the destination and can either be 0 or 7. Delay which controls the speed.

This is how it works:

1) For()-loop i from 0 to 7.

2) If the destination is 7, we set ii to 7-1, thus making ii the reverse of i. Clear the voxel at Z = ii+1. When moving down, ii+1 is the previous voxel.

3) If the destination is 0, let ii be equal to i. Clear ii-1. When moving upwards, -1 is the previous voxel.

4) Set the voxel at z=ii.

5) Wait for a while.
 

We made two box animation functions for the LED cube. Effect_box_shrink_grow() draws a wireframe box filling the entire cube, then shrinks it down to one voxel in one of 8 corners. We call this function one time for each of the 8 corners to create a nice effect. Effect_box_woopwoop() draws a box that starts as a 8x8x8 wireframe box filling the entire cube. It then shrinks down to a 2x2x2 box at the center of the cube. Or in reverse if grow is specified.

Here is how effect_box_shrink_grow() works.

It takes four arguments, number of iterations, rotation, flip and delay. Rotation specifies rotation around the Z axis at 90 degree intervals. Flip > 0 flips the cube upside-down.

To make the function as simple as possible, it just draws a box from 0,0,0 to any point along the diagonal between 0,0,0 and 7,7,7 then uses axis mirror functions from draw.c to rotate it.

1) Enter main iteration loop.

2) Enter a for() loop going from 0 to 15.

3) Set xyz to 7-i. This makes xyz the reverse of i. We want to shrink the box first, then grow. xyz is the point along the diagonal. We just used one variable since x, y and z are all equal along this diagonal.

4) When i = 7, the box has shrunk to a 1x1x1 box, and we can't shrink it any more. If i is greater than 7, xyz is set to i-8, which makes xyz travel from 0 to 7 when i travels from 8 to 15. We did this trick to avoid having two for loops, whith one going from 7-0 and one from 0-7.

5) Blank the cube and delay a little bit to make sure the blanking is rendered on the cube. Disable the interrupt routine. We do this because the mirror functions takes a little time. Without disabling interrupts, the wireframe box would flash briefly in the original rotation before being displayed rotated.

6) Draw the wireframe box in its original rotation. side of the box is always at 0,0,0 while the other travels along the diagonal.

7) Do the rotations. If flip is greather than 0, the cube is turned upside-down. rot takes a number from 0 to 3 where 0 is 0 degrees of rotation around Z and 3 is 270 degrees. To get 270 degrees we simply mirror around X and Y.

8) Enable interrupts to display the now rotated cube.

9) Delay for a while then clear the cube.

The other function involved in the wireframe box effect is effect_box_woopwoop(). The name woopwoop just sounded natural when we first saw the effect rendered on the cube ;)

The woopwoop function only does one iteration and takes two arguments, delay and grow. If grow is greater than 0, the box starts as a 2x2x2 box and grow to a 8x8x8 box.

Here is how it works:

1) Clear the cube by filling the buffer with 0x00;

2) For()-loop from 0 to 3.

4) Set ii to i. If grow is specified we set it to 3-i to reverse it.

5) Draw a wireframe box centered along the diagonal between 0,0,0 and 7,7,7. One corner of the box uses the coordinates 4+ii on all axes, moving from 4-7. The other corner uses 3-ii on all axes, moving from 3-0.

6) Delay for a while, then clear the cube.

These two functions are used as one single effect in the effect launcher. First the shrink grow effect is called 8 times, one for each corner, then woopwoop is called four times, two shrink and grow cycles.

To launch the shrink grow function, we used a for loop with some neat bit manipulation tricks inside to avoid writing 8 lines of code.

The second argument of the shrink grow functions is the rotation, in 4 steps. We are counting from 0 to 7, so we can't simply feed i into the function. We use the modulo operator % to keep the number inside a range of 0-4. The modulo operator divides by the number specifies and returns the remainder.

The third argument is the flip. When flip = 0, the cube is not flipped. > 0 flips. We use the bitwise AND operator to only read bit 3 of i.

Bitwise operators are an absolute must to know about when working with micro controllers, but that is outside the scope of this instructable. The guys over at AVR Freaks have posted some great information about this topic. You can read more at http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=37871
 

This is one of our favorite effects. The voxels randomly suspended in the cube gives a nice 3d depth, especially if you move your head while viewing the effect.

64 voxels start out on one of the side walls. Then they all get assigned a random midway destination between the side wall they started at and the wall on the opposite side.

The function then loops 8 times moving each voxel closer to its midway destination. After 8 iterations, the voxels are suspended at different distances from where they started. The function then pauses for a while, thus the name axis_updown_randsuspend ;). It then loops 8 times again moving the voxels one step closer to their final destination on the opposite wall each time.

The actual voxel drawing is done in a separate function, draw_positions_axis() so it can be used in different effects. For example, the voxels could be suspended midway in a non-random pattern. We will leave it up to you to create that effect function! :D

You may have noticed that the description for this effect was less specific. We encourage you to download the source code and read through the functions yourself. Keep the text above in mind when reading the code, and try to figure out what everything does.
 

To generate the most awesome effects, we use a desktop computer. Computers can do floating point calculations and stuff like that much quicker than a micro controller. And you don't have to re-program the micro controller for every effect you make, or every time you want to test or debug something.

The USART interface in the ATmega is configured to work at 38400 baud with one stop bit and no parity. Each byte that is sent down the line has a start bit and a stop bit, so 10 bits is sent to transmit 8 bits. This gives us a bandwidth of 3840 bytes per second. The cube buffer is 64 bytes. Syncing bytes make up 2 bytes per cube frame. At 38400 baud we are able to send about 58 frames per second. More than enough for smooth animations.

0xff is used as an escape character, and puts the rs232 function into escape mode. If the next byte is 0x00, the coordinates for the buffer are restored to 0,0. If the next byte is 0xff, it is added to the buffer. To send 0xff, you simply send it twice.

The rs232 function just loops forever. A reset is needed to enter the cube's autonomous mode again.

The cube just receives binary data via RS232. This data could easily be generated by a number of different programming languages, like python, perl or even php.

We chose to use C for the PC software, since the micro controller software is written in C. This way effects from the micro controller code can just be copy-pasted into the PC software.

Just like in the micro controller code, this code also does two things. Where the micro controller has an interrupt routine that draws the contents of cube[][] onto the LED cube, the PC software has a thread that continually sends data to the LED cube.

In cube.c we have a function called cube_push(). This takes the 64 byte array and sends it down the serial line to the LED cube.

It also handles the formatting, sending every 0xff byte twice because 0xff is our escape character. 0xff and 0x00 is sent first to reset the LED cubes internal x and y counters.

In main.c we have the function cube_updater(). This function is launched as a separate thread using pthread_create(). The main thread and the cube updater thread shares the memory area rs232_cube[8][8]. The cube updater thread is just a while true loop that calls cube_push() over and over.

The first attempt at an updater thread turned out to create some flickering in the animations. After some debugging, we found out that frames were being transmitted before they were fully drawn by the effect functions. We generally do a fill(0x00), then some code to draw new pixels. If a frame is transmitted right after a fill(0x00), the cube will flash an empty frame for 1/60th ish of a second.

This wasn't a problem in the code running on the LED cube, since it has a refresh rate of over 1000 FPS, but at 60 FPS you can notice it.

To overcome this we create a double buffer and sync the two buffers at a point in time where the effect function has finished drawing the frame. Luckily all the effect functions use the delay_ms() function to pause between finished frames. We just put a memcpy() inside there to copy the cube buffer to the rs232 buffer. This works beautifully. No more flickering!

This is the first effect we made for the PC software, and we think it turned out very nice.

While this may seem like a complicated effect, it's really not!

All the effect functions running on the micro controller mostly use if() statements to create effects. The effects on the PC software are built a little different. We use a lot of sin(), cos() and other math functions here. Most coordinates are calculated as floating point coordinates then typecast into integers before being drawn on the cube.

The effect you see in the video is actually just a sine wave eminating from the center of the cube, x=3.5, y=3.5.

Here is how it works:

1) Loop through the iteration counter.

2) Loop through all 64 x and y coordinates.

3) Calculate the distance between the center of the cube and the x/y coordinate.

4) The z coordinate is calculated with sin() based on the distance from the center + the iteration counter. The result is that the sine wave moves out from the center as the iteration counter increases.

Look how easy that was!
 

This is basically the exact same function as the ripple function.

The only difference is the coordinates of the point used to calculate the distance to each x/y coordinate. We call this point the origin, since the wave emanates from this point.

The origin coordinate is calculated like this:

x = sin(iteration counter) y = cos(iteration counter)

The result is that these x and y coordinates moves around in a circle, resulting in a sin wave that comes in from the side.

We just wanted to show you how easy it is to completely alter an effect by tweaking some variables when working with math based effects!
 

To make this effect, we really had to sit down and think about how fireworks work, and which forces influence the firework particles.

We came up with a theoretical model of how fireworks work:

1) A rocket is shot up to a random position, origin_x, origin_y, origin_z.

2) The rocket explodes and throws burning particles out in random directions at random velocities.

3) The particles are slowed down by air resistance and pulled towards the ground by gravity.

With this model in mind we created a fireworks effect with a pretty convincing result. Here is how it works:

1) A random origin position is chosen. (within certain limits, x and y between 2 and 5 to keep the fireworks more or less in the center of the cube. z between 5 and 6. Fireworks exploding near the ground can be dangerous! :p)

2) The rocket, in this case a single voxel is moved up the Z axis at the x and y coordinates until it reaches origin_z.

3) An array of n particles is created. Each particle has an x, y and z coordinate as well as a velocity for each axis, dx, dy and dz.

4) We for() loop through 25 particle animation steps:

5) A slowrate is calculated, this is the air resistance. The slowrate is calculated using tan() which will return an exponentially increasing number, slowing the particles faster and faster.

6) A gravity variable is calculated. Also using tan(). The effect of gravity is also exponential. This probably isn't the mathematically correct way of calculating gravity's effect on an object, but it looks good.

7) For each particle, the x y and z coordinates are incremented by their dx, dy and dz velocities divided by the slowrate. This will make the particles move slower and slower.

8) The z coordinate is decreased by the gravity variable.

9) The particle is drawn on the cube.

10) Delay for a while, then do the next iteration of the explosion animation.

We are quite pleased with the result.
 

• A dead cell becomes alive if it has exactly 4 neighbors
• A live cell with 4 neighbors live
• A live cell with 3 or fewer neighbors die
• A live cell with 5 or more neighbors die

Since we published our last LED Cube instructable, we have gotten a lot of questions from people wondering if they could use an Arduino to control the cube.

This time, we are one step ahead of you on the "Can i use an arduino?" front :D

The IO requirements for an 8x8x8 LED cube is:

• Layer select: 8
• Data bus for latches: 8
• Address bus for latches: 3
• Output enable (OE) for latches: 1

Total: 21

The Arduino has 13 GPIO pins and 8 analog inputs, which can also be used as GPIO. This gives you a total of 21 IO lines, exactly the amount of IO needed to run the LED cube!

But why write about it when we could just show you?

We hooked the cube up to an Arduino and ported some of the software.

Since the multiplexer array and AVR board are separated by a ribbon cable, connecting the IO lines to an Arduino is a simple matter of connecting some breadboard wires. Luckily, we soldered in a female 0.1" pin header for the transistor lines when we were debugging the first set of transistors. Just remove the ATmega and connect wires from the Arduino to these pin headers.

We connected the cube like this: DATA bus: Digital pins 0-7. This corresponds to PORTD on the ATmega328 on the Arduino board, so we can use direct port access instead of Arduinos digitalWrite (which is slow). Address bus: Digital pins 8-10. This corresponds to PORTB bit 0-2. On this we HAVE to use direct port access. Arduinos digitalWrite wouldn't work with this, because you can't set multiple pins simultaneously. If the address pins are not set at the exact same time, the output of the 74HC138 would trigger the wrong latches. Output Enable: Digital pin 11. Layer transistors: Analog pins 0-5 and digital pins 12 and 13.

We had to go a bit outside the scope of the Arduino platform. The intention of Arduino is to use digitalWrite() for IO port access, to make the code portable and some other reasons. We had to sidestep that and access the ports directly. In addition to that, we had to use one of the timers for the interrupt routine.

The registers for the interrupt and timers are different on different AVR models, so the code may not be portable between different versions of the Arduino board.

The code for our quick Arduino hack is attached.
 

We love getting feedback on our projects! The 4x4x4 LED cube has received a ton of feedback, and many users have posted pictures and videos of their LED cubes.

If you follow this Instructable and make your own LED cube, please post pictures and video!

Oh, and don't forget to rate this Instructable if you liked it :)

As a token of gratitude for all the great feedback, here is a collage of some of the feedback on our 4x4x4 LED cube instructable: