Now that our train wreck has been cleared … 29 hours later … I can focus again. (Our entire building PBX system fried itself yesterday morning and being the IT person you can guess who’s cell phone was red hot for the past 29 hours)
Recently someone approached me and asked to help them with a LumiNet-style project. If you’re not familiar with LumiNet, you might want to start here: luminet.cc
Essentially it’s a network of Attiny84s that can “infect” each other with their running code. Each node has an RGB pixel on it. Basically you program one node (stand alone), plug it into the network of nodes and it will propagate its code onto the others. All of their studies, documents, files, and cores are available for download.
Looking at their design, it’s designed to drive a single RGB LED and they’re using the three SPI pins to do this (one pin per channel.) This made me wonder whether it’s possible to reconfigure the code to instead use the same SPI pins to drive an LED string. On the surface I can’t immediately tell whether it’s a show stopper, other than perhaps, because this is a custom core designed specifically for this purpose, it may not have all the Arduino specific definitions, or other calls that FastSPI might need (and I’m just grasping here.)
This would help those who have controllers in areas not easily accessible (like myself) as you can simply reprogram one and let it infect the rest of the nodes.
Comments anyone?
might be more interesting if the communication was wireless. it looks a lot like its over engineered.
their main solution seems to be for clothing, and the “infect” patterns whilst quite nice, are simple.
you could create the same thing with addressable rgbs (which they are using) connecting cables, less attinys and better code.
Yes … if you’re going for a small scale item like clothing. 
But if the nodes are far apart, it’s easier, and cheaper, to run a data cable from one to the other. Sure wireless is ideal, but that’s could also end up being an unnecessary cost and overhead.
I really need to get moving on the AVR studio build of this stuff - there shouldn’t be anything that FastSPI_LED needs from the arduino libraries. My intention is to make the software pin access fallback code be dependent on arduino definitions being available, so if they aren’t, that’s ok.
There may be other ways to do this. You know me, I like algorithmic generation of patterns (vs. static). I’ve thought about implanting a ‘language’ for programming leds, or formulas to run leds - and have that be easily adjustable/propagate around. I suspect that project will need to wait for a “dan takes a month off from work” type of thing, alas.
My initial hope here is that I can lift their “infect” code and apply it to a 328p core. If I can just get the code to propagate from one node to the next, I’m happy. I can deal with communication in other ways. I like having stand along nodes anyway, in case one (or more, or even the master) fails, they can continue to run on their own. So I’m not so much interested in having each node tell its neighbor what to do at any given time … maybe some time in the future, but just not now.
If I was better at coding, I would start with the “game of life” code.
I should clean up my cellular automata code, or at least write up a basic version of it - instead of writing code for each “rule” or variation - it picks a rule from 0-MAX_RULE (where max rule depends on the number of previous neighbors that will be counted) and then runs from that - very compact code, billions of pattern options/combinations