Hey all. Me and a couple electrical engineering friends at a university were thinking over some ideas for a senior project the past few days, and we are wondering what kind of interest would there be for an arduino based board that allowed people to experiment with low level parallel processing? I have noticed that there really isn't much out there as far as intro kits to that kind of thing go. Sound like a decent idea or not even worth the trouble? Thanks for the input!
Those that are interested probably have the skill set already.
I have a dual '328P board kit available.
Designed a a dual 1284P, but never made boards for it.
Quad '2560 might be interesting, writing effective software would be challenging (for me anyway).
http://www.crossroadsfencing.com/
Please don't cross post.
Yeah we could handle the coding aspect with some of the people we got I believe. My bad on the cross post, I was trying to get responses from different areas of the forum. I think it would be a pretty fun little project....I'll look into the idea of a quad (or more) 2560
Most Arduino users seem to have enough trouble with one processor and the Blink Without Delay example sketch.
Have you any suggestions about what sort of projects would use / need a multiprocessor board?
How would it be programmed?
...R
There's no built-in language construct for parallel processing, which means it would be up to the programmer to build task offloading into their sketches. How that should be done depends entirely on the application.
E.g., an application might have one IC doing sensor management and another board doing computational stuff. They might communicate via i2c.
OTOH, for something akin to a general-purpose computer, you would want them to be able to shuffle processes back and forth as needed. Probably with a parallel data bus between them for speed, since i2c might take longer to transfer the relevant data than to just process it locally.
In other words, there's no one-size-fits-all load-sharing scheme, which would be the lion's share of the programming, and a significant part of the PCB design. You save very, very little effort by designing a system generic enough to service either application, since it would have to be customized to the point of being nearly a complete redesign to be useful. On the other hand, a specific implementation would only fit a very small number of people trying to use it in exactly the prescribed way.
In short, those who are interested... well, may or may not have the skill set, but if they were capable of doing anything meaningful with it, they would likely have the skills to design it themselves. Arduino dev boards aren't difficult to design afterall...
Sorry if this comes across harsh. I don't mean it to be, but there's a certain reality to this problem. As is the case with many great ideas, if it were easy or desirable, it would probably be done already. 
I'd go with SPI for interfacing. At 8 MHz, blows 400 KHz I2C away.
OP, take a look at programming graphical processors, which usually have hundreds to thousands units doing parallel computing.
For two CPUs some FIFOs or dual-ported RAM would be fun to play with.
I'm currently working on a system that can have a master and 15 co-processors, loosely coupled with either SPI, UART or I2C.
Don't ask my why you would need 15, it just seemed like a nice round number 
Rob
When I dream up a project requiring more grunt than a 16MHz 8 bit ATmega, I know which way I would go. A faster single processor is going to be much much easier to deal with than multiple slower processors. So it would be a Teensy 3.1 or similar, or even janost's Catweazle.
I would only choose multiprocessor for educational purposes. Something like the Teensy should outperform half a dozen ATmegas.
Paul
I agree with @PaulRB (Reply #10).
Multiple processors should only be introduced if there is a need to do more than one thing at the same time, not just to improve speed.
I have been waiting for the OP to make some suggestions about things that the proposed multi processor device could do. He seems to have gone to ground.
...R
Multiple processors should only be introduced if there is a need to do more than one thing at the same time, not just to improve speed.
Yes that's true, especially given the range of fast CPUs these days, multi-CPUs is a pet hobby horse of mine and even I struggle to justify it and for simple speed increase I can't at all.
In areas like offloading time-consuming IO (like the Lynxmotion SSC-32 Servo Controller) or maybe handling a complex serial protocol (technically the W5100 or FT232 are co-processors) I think there's a place for them.
Rob
Opinion:
What makes the Arduino particularly unsuited to multi-processing in the traditional way is that onboard peripherals are not easily virtualized. Were it possible to divest the peripheral hardware from the cores with low-level coding, such that either uC core could access any hardware resource, then that would be a very interesting multi-uC design - provided the abstraction did not add too much latency and eat too many machine cycles. C/C++ code running above the abstraction must see Every peripheral and two cores and semiphores and locking would need implementing.
What may be more beneficial is the adaptation of one of the current RTOS's to run on top of multiple AVR chips. Thus may prove more interesting than just an intellectual pursuit.
Ray
For two CPUs some FIFOs or dual-ported RAM would be fun to play with.
FIFOs seem hard to get and are expensive.
I bought some a while back thinking I was going to make an SPI sniffer with them. They weren't cheap. And I never did end up doing anything with them.
On further reflection, I suppose if I had a project in mind that was just a little more than what an ATmega could handle, rather than rushing into a whole new architecture, I probably would consider multiple processors, but not to perform parallel processing on the same data stream. I would, as would many others here I'm sure, try to find one or more parts of the process that could be "farmed out" to perhaps an ATtiny, for example dealing with and partially processing the results from a particular sensor or communications channel, relieving the main controller of some burden. I2C, as already mentioned, would be an obvious choice for comms between the ATmega and ATtiny.
Yeah I remember talking about doing that.
Using FIFOs or DPRAM would just be a fun thing to play with, total overkill for a dual AVR board though, a bit like having the Nürburgring or Daytona to yourself and doing laps in a Prius.
Rob
Wow guys thanks for all the responses!! I really wasnt expecting all that. Sorry Ive been off for a while. Ive been preparing for finals. Anyways, this was mostly just an intellectual pursuit type of thing as I realize that the avrs aren't exactly well suited to doing parallel processing. So suffice to say, due to all the great input from you all, I am probably going to go for a better senior project. In the end though I may end up creating the multiprocessor board just for fun to see what it can do:) Like I said. Intellectual pursuit. Thanks all!