And guess what the binary codes for "G" look like when stacked up, from bottom to top? Like a backwards G.

DisplayChar Colors...OK, so remember that DisplayChar also takes in 3 4-bit values to define the intensity of Red, Green and Blue? DisplayChar uses an internal array structure called dots_color which controls how the Rainbowduino sends signals to the LEDs. For each color and coordinate, the dots_color array requires 4 bits which will describe the intensity of that color. A 4-bit value of {0000} denotes the lowest intensity (off), and a 4-bit value of {1111} denotes the brightest intensity, with 14 values in between ({0001}, {0010}, {0011}, and so on).

DisplayChar has an outer loop over all the colors. For each iteration, it takes the 8-byte code and processes it byte-by-byte (row-by-row). Everywhere it finds an ON bit, it copies the 4-bit intensity value for the current color it's processing (the outermost loop) into the dots_color array. The illustration below shows how a byte value of 9A (10011010) would be loaded into dots_color if we wanted to display the maximum intensity for the Green LEDs.

Creating a Custom Rainbowduino Command

The sample code doesn't enable you to display multiple colors (unless it's one of the preloaded patterns already in Rainbowduino memory). I need to extend the Rainbowduino firmware beyond that to enable me to send On/Off data for each color on-the-fly. This means I needed to send more data over the wire from the arduino. Specifically, I have to send over 192 bits for the command (8 rows * 8 columns * 3 colors). The nice part is that since I only care about Eight Colors: Red, Green, Blue, Purple (R+B), Yellow (R+G), Cyan (G+B), White (R+G+B), and Black (if you count "off" as a color). This means I can assume that my intensity values will always be {1111}. So I have no need to send granular intensity data over the wire. An LED will be full-on or completely off, like a bipolar weiner dog.

Like the preloaded patterns, the character data mappings are stored in the Rainbowduino, which means that all you need to send over the wire for a DisplayChar command is a single byte that corresponds to that character's ASCII code. Then, the Rainbowduino looks up the predefined 8-byte array for that ASCII value. This makes the DisplayChar command a very lightweight, compact message. I won't have that luxury of knowing predefined mapped-row hex values. However, I can piggyback on the DisplayChar technique to encapsulate all the On/Off row data I need (for a single color and a single row) into a single byte. So, I'll increase my message size by 24 bytes (8 rows * 3 colors).

I made the new command look like this:

DisplayCustom(int Address, byte RedRow1, byte RedRow2, byte RedRow3, byte RedRow4, byte RedRow5, byte RedRow6, byte RedRow7, byte RedRow8, byte GreenRow1, byte GreenRow2, byte GreenRow3, byte GreenRow4, byte GreenRow5, byte GreenRow6, byte GreenRow7, byte GreenRow8, byte BlueRow1, byte BlueRow2, byte BlueRow3, byte BlueRow4, byte BlueRow5, byte BlueRow6, byte BlueRow7, byte BlueRow8)

I resized the RainbowCMD array on the firmware and wrote logic to handle the new incoming command. If you do this, you have to change the function "receiveEvent" in the Rainbowduino code to accept more bytes in the message, and "SentCMD" in the Seeedmaster code to send more bytes. Below is a snippet of the code I used on the Rainbowduino that loads dots_color from the new RainbowCMD array:

void DispshowCustom(void)
{

unsigned char color,row,dots;
int i;

RainbowCMD[1]=0;

byte wholerowdata;
byte dotpair;

//render
for(color=0;color<3;color++)
{
    for (row=0;row<8;row++)
    {
        if (color == 0)
            wholerowdata = RainbowCMD[13+row]; //green rows in 13-20
        if (color == 1)
            wholerowdata = RainbowCMD[5+row]; //red rows in 5-12
        if (color == 2)
            wholerowdata = RainbowCMD[21+row]; //blue rows in 21-28
        for (dots=0;dots<4;dots++)
        {
            dotpair = 0x00;
            //higher order 4-bits
            if ((wholerowdata<<(dots*2))&0x80)
                dotpair|=0xF0;

            //lower order 4-bits
            if ((wholerowdata<<(dots*2+1))&0x80)
                dotpair|=0x0F;


            dots_color[((Buffprt+1)&1)][color][row][dots]=dotpair;
        }
    }
}

Buffprt++;
Buffprt&=1;

}

I had a small problem with the command, where the last byte of the command (corresponding to the top row of the blue LEDs) was getting corrupted somehow.

This was resolved by tacking on an extra byte onto the RainbowCMD. I don't know why this worked but it did, and I played around with feeding random(255) into each DisplayCustom argument to give it a final test. Disco, Disco!

bool pattern[3][8][8] and the Blinking Cursor

To make life a little easier, I wanted to have an easy-to-work-with data structure in the arduino so that I could easily turn on and off bits without having to do a bunch of binary math (as fun as that is). I decided to use a bool array called pattern[3][8][8].

So for the above desired display, I can set the following bits in the pattern array:

pattern[0][4][2] = true;

pattern[1][2][7] = true;

pattern[2][7][2] = true;

The code snippet which translates pattern[3][8][8] data to R/G/B byte arrays (called argument_arrays) follows. I almost forgot what fun bitshifting was.

  for (color = 0; color < 3; color++)
  {
    i = 0;
    for (int gridrow = 7; gridrow >= 0; gridrow--)
    {
      ThisRow = 0x00;   
      for (int gridcol = 7; gridcol >= 0; gridcol--)
      {
        if (gridcol != 7)
          ThisRow = (byte)(ThisRow << 1);                       

        ThisRow |= ((pattern[color][gridrow][gridcol])?0x01:0x00);       
                                          
      }
      argument_arrays[color][i] = ThisRow;
      i++;
    }               
  }

Using this technique and a little 500ms delay, I was able to get a blinking red cursor in the 0,0 position. Whew. It feels like I just walked 70 miles to get to a McDonald's. Surely the reader feels the same way.

Waiting for the joystick, Other ideas surface

While waiting on the joystick to arrive in the mail, I had an idea for an offshoot project....What if we used a Maze Generation algorithm to put a maze onto the LED matrix and then let the user go through the maze with the joystick? Of course an 8x8 pixel maze would be incredibly easy, but you could easily stitch several of these mazes together and have a large maze that becomes quite a challenge. Here is a proof of concept with the cursor moving around randomly. And here is the writeup for that project, currently in progress.

The other offshoot idea I had was interfacing the arduino (via USB/serial connection) to capture data from a webcam, and send that data to the rainbowduino. Of course it would be all pixellated and pretty much unrecognizable, but we're just going for proof-of-concept here. I lifted some free code from devx (here) and changed it to suit my needs (added "pixellation" logic and the resulting RGB color levels are filtered down to 4-bit values so that they can be understood by the Rainbowduino). Apparently, I2C Communication through the arduino is limited to 32 bytes though, so I'll need to get creative with how to send over the extra intensity data values (since I can't rely on pure ON/OFF values with this idea). This guy has figured out some way to do it. I lifted some of his code from here for a future project (BriteCam!!)