A(nother?) Successfull Matrix

This saturday I received my chip samples from Maxim and finished wiring up a 5x5 (water clear red) matrix.

Not many details just yet, but maybe more later http://www.robertcarpenter.net

I have been writing the arduino code to implement a set(x,y,state) method with double buffering for animations in an LED matrtix. So far (and it is not that far just yet) the program is 4262bytes and reads an integer from an array and decodes the binary bits to figure out a 2d position and state. The code is in its infancy but as of now I am able to put an array like this:

int aniSteps[] = {
  0x0001, 0x0009, 0x0049, 0x0041,
  0x0000, 0x0008, 0x0048, 0x0040
};

And that will get turned into a series of light blinks on my 5x5 matrix. Planned additions are function calls etc embedded into each integer. More details are included in my source code posted on my website. If it all works the way I imagine it would allow an animation sequence to be loaded into EEPROM or fed via serial or something.

Source Code: http://robertcarpenter.net/drop/ani_lib0.1.cpp

Documentation included.

:slight_smile:

Hmm. I realize now that I should not post at 1am. It is true what I said earlier, but I had meant to include this bit too:

The buffering mechanism works like this:
In this example we would see a line going down column 1. Nothing would be sent to the Maxim until bufSwap() is called, at which point only rows 0-4 would be sent (5-7 would still be marked as clean).

set(0,1,state);
set(1,1,state);
set(2,1,state);
set(3,1,state);
set(4,1,state);
bufSwap();

On top of that I have devised an encoding scheme to enable the storage of animation sequences in hex format, as unsigned ints. The encoding works as follows: (please forgive the TESTED markers, they are a memory aid for me)

Animation step details: (*=not implemented yet)
 abcdefgh ijklmnop
 00000000 00000000
 
 a - function mode: 1=function mode, 0=display mode
 
 function mode:
 b-h: function selection
 i-p: function value (little endian)(10 bits, upto 1024)
 
 display mode:
 *b-e: auto delay value.  Automatically delay animation increment. Uses Arduinos built in delay. Delay is after update from this step.
 f: flush after update. (TESTED?)
 *g,h,i: depth. for 3d displays. 0 for 2d.
 j,k,l: column. (TESTED)
 m,n,o: row.  (TESTED)
 p: light state (TESTED)
 
 available functions:
 00001 0x1 01 flush/swap display buffer. (TESTED)
 00010 0x2 02 no op/delay by value. Uses built in delay function. Up to 255 miliseconds. (TESTED)
 00011 0x3 03 no op/delay in seconds by value.  Uses built in delay function.  Up to 255 seconds. (TESTED)
 00100 0x4 04 set repeating delay to value.  Uses built in delay function.  Function steps ARE NOT delayed. Up to 255 miliseconds. (TESTED)
 00101 0x5 05 set repeating delay in seconds to value. 
 00110 0x6 06 Set auto flush. 0=never auto flush, otherwise flush every VALUE updates to the display. Up to 255.
 00111 0x7 07 set shutdown register to value.
 01000 0x8 08 set test register to value. (TESTED)
 01001 0x9 09 set intensity register to value. 0-255. (TESTED)
 01010 0xa 10 set all display registers to value. (TESTED)
 01011 0xb 11 set decode mode register to value.
 01100 0xc 12 set scan limit register to value. Minimum value of 2 (three rows). (TESTED)

You may be thinking.... "gosh the maxim already ran on a series of hex numbers...why did you rewrite it?"

My goal is to be able to:

  • Store animation sequences in memory in a compact way, maybe even EEPROM. This would work nicely because then a program could be written to accept new animations from the serial port and store them into some non-volatile memory somewhere.
  • Update display quite fast, minimizing flicker. The eventual goal is a 8x8x8 matrix for display and recruiting for my Computer Science program -- a flickering display would be more impressive. This is why I implemented the buffering mechanism which will allow for as few communications to the MAX chips as possible. Thinking ahead now I might just go around the shift register functionality and use a multiplexer to program the individual chips as fast as possible.

Have you thought of I2C or SPI eeproms? I've not looked at using them but they could be an option.

My goal is to be able to:

  • Store animation sequences in memory in a compact way, maybe even EEPROM. This would work nicely because then a program could be written to accept new animations from the serial port and store them into some non-volatile memory somewhere.
  • Update display quite fast, minimizing flicker. The eventual goal is a 8x8x8 matrix for display and recruiting for my Computer Science program -- a flickering display would be more impressive. This is why I implemented the buffering mechanism which will allow for as few communications to the MAX chips as possible. Thinking ahead now I might just go around the shift register functionality and use a multiplexer to program the individual chips as fast as possible.
    [/quote]