Had a look around and couldn't find anyone doing this ?
Just for fun, I thought it could be an interesting project ? I have a bunch of arduino mini pros.
By crossing over the i2i on the first one in the stack - they should then be able to be stacked on top of each other with regular stack headers.
So you end up with a sandwich of say, 10 pro minis.
By incorporating some code for them to randomly or sequentially step through i2c addresses they should be able to establish communications with the master.
You could then write some example code to have the master farm out stuff for the other 9 slaves to do, and assemble the answer ?
It's hardly going to be a render farm, but though it'd be a fun programming challenge. Ideally you'd want the same code on every board, and for one to 'grab' master on startup, they all then configure themselves automagically, and the actual 'job' can be farmed out/controlled by the master over the i2c bus (running at 400).
perhaps could get something like a beowulf cluster running ?
I'm not sure what the point would be, but if you wanted to do this then EEPROM would seem an appropriate place to hold each board's identity. But it seems to me that the Arduino's main advantage (over more powerful devices) is its cheapness and compactness. You lose both of those advantages when you assemble a large number together - and still end up with a lot less processing power, memory, I/O bandwidth than other inexpensive microprocessor based solutions.
Just for, experimentation and experience of parallel processing really.
I'd want to design the boards to be self organising, so EEPROM after they'd done that I suppose, but I'd want to be able to load the same code on every board I think (as part of the experiment).
the whole stack would cost $30 and be about the size of a matchbox, so I think it would still fulfill the cheap and compact criteria.
Of course there are other reasons which might make this useful - for example having different code on each - one handling VGA, one handling say a high frequency sensor monitoring, one reading stuff off SD card, one just for processing JPGs, etc.
Practical - no - get a raspPI, but fun to do I'd have thought.
You do not "cross over" I2C data and clock between master and slave, nor is there any reason to use alternate pairs of lines.
There is absolutely no point in paralleling any of the other I/O lines, so you do not want to "stack" them at all. Beowulf clusters do not have busses as such, they have mains power distribution and Ethernet switches reticulating.
And as has been said, you do not need dynamic allocation - unless you anticipate failure.
Sorry I was talking of physical stacking - not connecting every single pin.
And yes, of course you are right - i2c is straight through. my bad.
In order to have the same code on each you would need dynamic allocation (at least on first start). Obviously a far easier way would be to configure this in eeprom initially, but where is the fun in that ? Also, it would allow the same code to run with the devices NOT stacked physically, but connected via another i2c interface shield (433mhz, etc)
I mentioned Beowulf as an concept rather than the implementation (which wouldn't work on arduino for any number of reasons)
I put a couple of 328s together on a board, with enough header pins to make connecting them together in various ways easy.
Layout several side by side, I2C to I2C, master to a bunch of slaves or similar. http://www.crossroadsfencing.com/BobuinoRev17/
Picking this up from of old, the classic structure for parallel processing is to use the master processor to handle the main program routing, black-boxing the major processes involved. Each black-boxed unit is farmed out to a slave, and while that's processing, the master is interacting with other slaves and working ahead, loading the next task module.
One essential job for the Master unit is the management of a command stack, look up windows processing if you don't know what that is. It's run as a buffer to allow for the essentially asynchronous timing of the slaves.
A major element of the SuperCommand in the command stack (the priority task instantly pushed to the head of the stack) is the TaskComplete signal from a slave. Output will usually be held on the slave, as uploading it to the master is a distinct task, but that then needs handshaking to the slave to release the memory once uploaded and verified.
Another major task for the Master is human interfacing, if only to report when complete. you could almost treat that as another slave unit, though, outputting questions and results and awaiting input.
Actually, I am on the verge of using two processors. One to handle display. It doubles the available I/O. If I want more speed or memory, there are better options.
