That's the kind of thing I was referring to earlier.
Panels report left & up, for instance, on who is to their right or below, based on those panels pullling an input pin low.
The micros on the panels then negotiate where they are, all streams go to all panels, the micros pick off the data intended for their LEDs.

Wouldn't it be better to have the master send each uController its specific data, as opposed to flooding the whole matrix?  If I can identify each uController by address (hence the i2C possibility), I can also send each one specific instructions and I don't have to flood the whole thing.  This also allows me to send instructions to just one panel, and the rest can simply repeat their last instruction received.  This would cut down on the data being transmitted across the whole thing, no?

I know there are ways to add a star topology to I2C, there are ICs specifically for that.  I just have to figure out if they would work in this scenario without adding too much overhead, or wasted resources, while also keeping everything identical for manufacturing purposes.

I just realized something ... the I2C bus is, for lack of a better explanation, a single long string of up to 128 devices, one after the other.  As opposed to say something resembling a tree with branches configuration.  This poses a problem with expansion.  Say I have a 3x3 configuration, and the existing I2C bus runs in a zig-zag pattern from top-right to bottom-left (where the master would be.)  How would you add more panels?  You can only do that at the top, you can't add more to the left or right.  I wonder if there are connectors that when you plug something in them, they automatically disconnect another path, kinda like what headphone plugs will do - they cut the signal going to the speakers and it goes to the headphones instead.  That might be one way to do that.  Have the signal always traveling up and down.  If there's something plugged in on either side, that changes the direction of the signal.

Hrm, more cranium busting ...

Yep.  I designed the PCB myself (11mm x 14mm), chip, resistors and cap on one side, and the RGB LED on the other side.  Reflow solder the chip and other components, and hand soldered the LED.  The PCBs were paneled into 4x3 larger pieces which made it a lot easier to hold in a vice as I soldered the LEDs, then I used a Dremel cutting tool to cut them apart.  Solder the 4-contact ribbons on, controller at the end and you get what you saw in the video.  I get the WS280* direct from manufacturer so they're much cheaper, even with shipping.  But then, I also get then 1,000 to 2,500 at a time, if not more - if you're interested, I'll send you a few after my next shipment in January.  I'm getting the 2803s in DIP version for now because I want to do some breadboard testing for something else down the road.

Attached is an image of the PCBs in the various stages, and what one of them looks like up close (just the IC side) ...  This was meant to be for a parade, so I made several strings (10 LEDs each), connected two strings to a controller (my design) which also has an RF module on it.  During the show, all the strings display the same sequence of lights, so you get a large group of people together and they all are blinking the same patterns, or be completely random.  After the parade, I took the whole pieces, as is, and hung them in the window.  So there are 8 controllers in the window, 16 strings total.  The first controller acts as the master and tells the rest what sequence they ought to be playing.

Sure I could've redone it and built one single controller to drive all the strings in the window.  But why re-invent the wheel when it's already there (albeit in single form.)

Oh, the WS2801s will update 500uS after seeing the clock stop.
So I guess share the data line and have seperate clocks.

Well yeah, pull it low for 500ns and it resets and latches the data.  I'll test both scenarios, see what happens.

Leonardo is already supported on 1.0.
Not seeing anything for 324/644/1284 in the variants file, but the format to use to create another one is straightforward to follow.

I am staying as far as possible from 1.0 as I can.  There way too many problems with it.  I'm thinking I may forgo using the IDE all together and move to AVR Studio ... but I haven't quite decided yet, mainly because I have never worked with AVR Studio and need to figure it out still ...

I don't have one to test, however looking at the data sheet, it doesn't say that INT/SQW should be grounded.  It says either leave it hanging if you're not using it, or put a pull-up to VCC on it.

Clock can be shared to all, need way to decode addressif doing that, or individual lines as you say.

Yeah, it makes more sense to have separate DATA lines (15 total), and they all share the same CLK line.  That way the uController just sends the data down the correct line, and pulses the clock.  I think I would continuously have to update all 15 lines though.  For example, take three rows of 15 LEDs each.  Let's say I light all of them up blue.  Then I change only the bottom row to red.  The top two rows will see the clock pulse but there's no data.  Not sure what it will do, turn them off or leave them as is, or something else.  Guess I'll need to try it.

ATMega324/644/1284 have 32 IO
ATMega32U4 have 26 IO I think, plus USB

Myah ... need to dig up the cores, figure out the pin mapping, etc., etc.  But, doable.

WS2801s, one per LED, daisy chained.

My next project will be using its larger brother, the WS2803 - 18 channels versus 3 on the 2801.

Ok, I'm putting the small panels to rest for a moment so not to get too burned out on them.  Switching to the uController's interconnectivity for a moment.  A programmer friend of mine suggested using TWI for that (as opposed to serial comms).  TWI is built in and can handle up to 128 devices on the bus.  Any larger and I can implement a multi-master setup and expand even more.

The suggestion was to use the builtin TWI function on the uControllers (SDA/SCL) and I can still use SPI on the strings (though I'd have to figure out how to address them individually as there will be 15 rows on a large panel.)  Or I can just bit-bang them on arbitrary pins (which would be slower), which brings me to my next question:

If I go the bit-bang route, can all 15 strings share the same clock OR data line?  In other words, if they are all on the same DATA line, but each have their own CLK line, or if they all have their own DATA line, but individual CLK lines, would that work?  Reason I ask is because, if they each need their own DATA and CLK line, that means 30 pins just for the strings.  A 328P won't handle that.  Whereas, if they can share either CLK or DATA lines, that's only 16 pins.  I think I can manage that.  It does mean I have room for almost nothing left:

SDA/SCL for TWI, XTAL1/XTAL2 for the crystal and everything else goes to the strings except RX/TX.  Or, I use RX/TX as well, and free up something on the SPI port, maybe MOSI/CLK ...

I had planned on adding an RTC on the circuit as well, like the DS1307, which would also have to go on the TWI bus.  Or move away from that, go to SPI bus (like a DS1306)  Though if I move to the SPI bus, if I also have a string occupying two of those lines, it could pose problems ...

Or, forgo all of that and "upgrade" to a larger IC.

Need to open up that video ... it is private at this time.

Whoops.  It's open now.

Actually, I miscalculated.  the 3x3 grid is the small 80mm x 80mm module.  I'm stacking them 5x5 to make one large 400mm x 400mm panel.  That starts to get unwieldy ...  If one of those 3x3 modules is already hitting the 1A mark, that's 25 of them to form a large panel, for 25A each.  I'm going to need one PSU per large panel.

So I may be forced to use the standard 20mA 5050RGB ones.  So that's 60mA per.  On a full (large) panel, that's 225 LEDs = 13500mA = 1.35A.  Add the 225 WS2801s [1], plus one uController.  Let's say 2A per (large) panel.  At the most, that's 15 panels on the 5V, 30A PSU.

[1] I'm trying to figure out if I can cut that down by using three WS2803 as opposed to 9 WS2801s.  Cost-wise it comes out the same as the 2803s are about 3 times more expensive as the 2801s.  It is constant current (up to 30mA) unlike the WS2801.  But for standard 5050RGB, that's just fine.  Because the WS2803 has 18 channels (as opposed to 3 on the WS2801), I would be wasting 9 channels.  Each 80mm x 80mm has 9 LEDs arranged in three rows of 3 each, so 3 RGB LEDs = 9 channels.  Unless I daisy chain 2 panels per 3 ICs, but then I move away from having identical panels again.  Damned thing dissipates 2600mA max ...  Oy vey.

Yep, I've been using the SOIC ones for a while now.  They don't get hot at all, even with the LED at full blast, constantly switching, nothing. I'm thinking it might when you start hitting its 6Vin max.  I've been running them between 3.5V and 5V for different projects.  I will more than likely stick to 5V with them.

But yeah, pad underneath never hurts.

If I use the same Cree LEDs I have been using, I may end up with several power supples anyway. Those things pull 108mA combined at 100% duty cycle.  The only reason I like them is because they are black, unlike all of the 5050 ones I've seen so far.  So 9 of those on a panel, full white, that's 972mA already. The WS2801 dissipates 1.5mA under normal operation (whatever 'normal' means).  So I could already be looking at an Amp per panel already ...

5V, 30A, I can be conservative and run a 5x5 setup and have 5A still left.  One PSU per 25 panels isn't bad at all.

Almost 4 AM and I can't sleep.  What's my brain doing? Coming up with more stuff that could be potential problems.

So, right now I'm working on 80mm x 80mm boards, each one with 9 LEDs (9 ICs, 18 resistors, 9 caps, plus 2 additional resistors for termination on the DATA lines).  Oh, and edge connectors ...  This would translate to a completed "panel" of 400mm x 400mm (or 15.75" x 15.75") with a 15x15 LED grid pattern.  Good nuf for me.

Ok, since I am planning this for growth, this also means I have no (real) control over how many completed (15x15) panels are connected to each other, which means at some point a single string could very well end up pulling more Amps than the power supply can provide, and there will be a bunch of them.  So I'm wondering what to do about that.  Should I be thinking of adding transistors, or a darlington array and run each LED through that?   How will it hold up?  Any caveats with that?  Any particular array I should be considering here?

The IC also gives me the option of running everything from a higher voltage than what they will accept, just need to build a slightly different circuit around them.  The example circuit is made for 24V even.  If that helps this cause at all ...

Get a bunch of RGB LEDs and roll your own?  Like what I did here: https://www.youtube.com/watch?v=-3ex1k8f_Nk

Tiny24 might be a way to go with those RF modules ... Use the SPI for the RF modules and pins for RGB LED(s) ... resistors, button batteries, might be able to get it done within $10-$12 ...