Pic Cube

Description

This project was done for CCS while I was an intern during my senor year at MSOE. The goal was to create a large distributed display device using only PIC18 micro controllers.

Unfortunaly, any pictures or video is lost on a backup hard disk. Once I find it, I'll post it. There is a release page here.

This was a very large project done for an embedded trade show. The basic idea was to use modular blocks to build a larger display device that we could use for advertising our products and showing other interesting things. Each block consisted of one PIC18 microcontroller and 64 leds arranged in an 8 by 8 grid. Each block also had four port, one on each edge of the cube. Each port consisted of a power connection, a ground connection, and a connection for transmitting serial data. When assembled, the full display was 8 by 8 boxes which worked out to 4096 leds. It required a 100 amp power supply go light all of the LEDs at the same time.

Three things were displayed at the trade show. The first was a bouncing ball demo. This was similar to a screen saver in which circles bounced around the display and showed off the ability to pass balls from box to box but still draw them accross mutliple boxes. The second was animated advertisments. There were a number of these each representing on of the major CCS products. The third was the game of live which would start out with a pattern and iterate for a set period of time.

Challenges

There were a number of pieces to this project

1. The actual communication between each node
2. A pc application for loading animation data
3. A boot loader for updating firmware

Communication

I wrote all of the communcation software for communicating between blocks. The communcation was done using a serial protocol that included commands and parameters. Commands included assigning node numbers, signalling a firmware update, and passing neighborhood data. This same protocol was used to communicate with a controller PC. The lower left block was considered a special block because it communicated with the PC. Once the first block was running, it would send out a command that would propogate through the sturcture and assign addresses to each block. From there, the control PC sent commands to switch animations and reload the firmware.

PC controller software

I did not write this piece. It's purpose was to load the animations and firmware.

Boot Loader

I also wrote this part. One of the challenges with this project was setting the blocks up and taking them down. Programming each block was time consuming and requierd the disassembly of the entire structure. To aleviate the issue, I added bool loading code. The controller PC would send updated firmware to the master block which would propogate it to the other blocks. Each block would write the firmware to a block of memory reserved for staging the firmware. Once each block had loaded it's firmware, the controller would send out a second command which would cause each of the blocks to copy the staged firmware into the main application memory space. This posed some interesting technical challenges as the code that was copying the staged memory could in no way rely on the original main memory.