Big RGB Table Finally Needs Code

I have been working on an RGB led table for quite some time now, finally got a board designed that uses shift registers for the multiplexing, and of course the actual leds are wired and situated where they need to be. Two questions/requests:

  1. I am looking to wire the control board and table together in a way so it is the easiest to program, and

  2. I desperately need some help getting some code generated. I am a total beginner when it comes to shiftOut() and the SPI library. Some easy to understand code and baby-step-help would be greatly appreciated.

Below there should be a few pictures and a couple tables of how i was thinking of wiring it up.

Table Wiring.odt (14.2 KB)

Table Wiring.doc (26 KB)

Here are some more photos.

What shift register are you using? Anyway, I have an example here:

Basically you work out your pattern ... however you want to do that, and then do something like this:

  digitalWrite (LATCH, LOW);
  SPI.transfer (0xAB);
  SPI.transfer (0xCD);
  SPI.transfer (0xEF);
  SPI.transfer (0x42);
  digitalWrite (LATCH, HIGH);

Add more SPI.transfer() if you have more registers. Hopefully you wired them to daisy chain.

I am using a 74HC574, not a shift register in itself, but wired to act like one so it can deliver the mA required with out having to order new chips. Q1 to D2, Q2 to D3, Q3 to D4 and so on. Yes they are indeed daisy chained. And unfortunately i have no way of knowing what that code means, I will take a look at your example tomorrow, way too many hours in front of this computer. thanks for the quick reply! PS i was thinking for a test individually turning on each column, then waiting about half a second, then moving on to the next one, then repeat. once it gets to the end of the board switch to a different color. Start with red, then blue, then green, then the other 4 mixes of them. Food for thought.

That code will clock out the bit patterns. Assuming those register-things are 8 bits, you would need one SPI.transfer per chip.

Try sending 0x01 and then all 0x00 for the others and see which one lights up.

Sounds like a plan, do you have a suggestion for wiring?

It looks wired already judging by your photos. If not, check out the link I gave above.

Well yes and no, the board is wired, I’m asking what is the simplest way to connect the table to the control circuit. I attached some proposed ways in one of the last posts.

Wiring isn’t my strong suit. Your setup looks about 1000 times better than what I would have done.

Well hey thanks! I think Ill go with the 1st table and experiment. Get some Expedia ce under my belt and then try and tackle something really big, like Tetris. Thanks for all your help.

Do you have the thread for the design of the board? That will help with coming up with some code.

Found your hardware thread:,97488.15.html

Reply #19 had the coding suggestion for your hardware.

I like these kinds of parts from for connecting things up pins crimp on wires, or use their already terminated wires. wires go into crimp housing to keep them all organized, then plug into matching female headers soldered on the board.

Or use female crimps in housings and slide onto male 0.025" square header pins.

Very handy parts, I've used a lot of them.

Yeah i remember that code. But i guess i am not being that clear on what i mean. I am wondering what would be the best configuration of the connections. If you look at the document i attached a while back it has tables in it showing some wiring ideas. I am thinking of going with the second. 1st chip and half of second does red 1-12, then the next half of second and third does blue 1-12, and finally the fourth and first half of fifth does green 1-12. chips six-eight hand all the gounding of columns. Hope this makes sense...

sorry, i mean table number 1 in the attached documents.

I see. The configuration you are talking about really comes down to how you plan to put data into the arrays I described that will make up the color patterns. I personally think that splitting the data for each LED up across multiple locations would be awkward (i.e.slow) to make changes to as your code reacts to button pushes & stuff. Having 3 adjacent bits for an LED would seem, to me, to be easier to manage. However, lots of real programmers here are great with functions & stuff, so if you wanted to create an array of 5 words across by24 locations deep (or as needed, I forgot the width/depth you had) where the bits were arranged like this to represent the LEDs going across the table, then Im sure it could be managed.

LED0 0, 12, 24 LED1 1, 13, 25 LED2 2, 14, 26 LED3 3, 15, 27 LED4 4, 16, 28 LED5 5, 17, 29 LED6 6, 18, 30 LED7 7, 19, 31 LED8 8, 20, 32 LED9 9, 21, 33 LED10 10, 22, 34 LED11 11, 23, 35

ok, i think for ease of programming, since im so new and all, i will go with the first configuration. I tried modifieing some of your example code, since i have a 12x24 matrix (12 RGBs) so really 36x24

// code for an 36 x 24 array (12 RGB LEDs, 24 columns) as an example
// not all code parts shown, just the highlights
// set up an array for the cathode drives
byte cathodeslower[ ] = {0x01, 0x02, 0x04, 0x08, 0x10, 0x20,  0x40, 0x80, 0,0,0,0,0,0,0,0};  // walking 1 for lower 8 NPNs 
byte cathodesmid[ ] = {0,0,0,0, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20,  0x40, 0x80, 0,0,0,0}; //walking for mid 8 NPNs ???????? 
byte cathodeshigher[ ] = {0,0,0,0,0,0,0,0,0x01, 0x02, 0x04, 0x08, 0x10, 0x20,  0x40, 0x80};  // walking 1 for upper 8 NPNs
byte anodes1 [12]; // array to hold 1st 3rd of RGB info, like red?
byte anodes2 [12]; // array to hold 2nd 3rd of RGB info, like blue?
byte anodes3 [12]; // array to hold 3rd 3rd of RGB info, like green?
byte columncount;
byte oe = 12; 
unsigned long updateTime = 0;

void setup(){
pinMode (oe/, OUTPUT);
digitalWrite (oe/, HIGH);

void loop(){
// set up for blink without delay operation
if (millis() >=updateTime){
// yes, set up for next update
updateTime = updateTime +2; // update a column every 2 milliseconds, 16 columns at ~24 Hz rate
digitalWrite (oe, HIGH);  // turn off display
SPI.transfer (anodes1[columncount]); // update anodes
SPI.transfer (anodes2[columncount]); // update anodes
SPI.transfer (anodes3[columncount]); // update anodes
SPI.transfer (cathodeslower[columncount]); // turn on a cathode
SPI.transfer (cathodesupper[columncount]); // turn on a cathode
digitalWrite (oe, LOW); / turn display back on
columncount = columncount + 1; // update for next column
if (columncount == 24){columncount = 0;} // reset if reach the end
} //end display refresh

// now the fun part, for you!
// read buttons, or whatever processing you plan to do for patterns, etc., 
// and update anodes1, anodes2, anode3 as needed
} // end void loop

I really dont know about that cathodemid section, mostly guessing when i wrote that. But i did manage to do my research on hex, so at least that is understandable now. Still a little fuzzy on arrays.

Looking like a good start.
Maybe populate the anodes arrays as test starting condition and see if this works. Then start the array changing code.

Sounds good, too bad I won't be home until Sunday....

Do you think you could show me an example of how I could get it to slowly cycle through all the columns? Like turn on red for column 1 then wait a second then move on to column 2 repeat. When it gets to the end, that is, it's gone through all 24 columns, then repeat with blue, then green, then the other combinations?? Not sue where to start for that... Thank you!!

Do what you had and thrown in a delay afterwards?

Well you seem to have timing in it. The code looks like it might potentially work. The devil is in the detail in your case ... are you bit patterns right? Only you can say that.