I guess what I'm wondering about is if anyone's put additional effort into "application layer" programming - i.e. abstracting the functions of the "slave" CPU so you can do the equivalent of basic functions (read/write) from the "master" CPU's code. In other words, beyond what's in the example sketches.

ahh well don't put yourself down think of your idea as a an inexpensive alternative to the arduino mega!! and its more complicated which means more fun!! i still have your pcb, all soldered together and sir i have plans for it, so i hope you don't intend on letting this die!

All Arduino progress is good progress and the Mega was a welcomed addition, a sight for sore eyes even if the price is a little out there.

Personally I've got just about everything I could ever want or hope for from the WiFi shield from Asynclabs (adlib not intended). So in addition to work and family, I've spent my rare spare moments exploring the shield and planning a number of web based physical computing applications.

As for the dCore, the most exciting application is the ability to string together an unlimited number of 168's. That presents new and inexpensive opportunities in fields such as robotics, I could quite easily visualize a robot having a number of 168's dedicated to specific tasks, like, one for claw actions and sensing, another for movement, and perhaps separate 168's each for the different types of environment sensors - we all know how much processing power some of them need which leaves very little space for a brain to make sense of everything.

So there's certainly things that still need to be done, but it all unfortunately comes down to how much hobby time one has, and mine has been squeezed by other priorities, including breaking a leg skiing which is still healing a year later lol.

In the meantime if others find ways of applying the work then thats excellent, 168's are cheap and depending on how many you can string together over i2c, the sky is the limit - or maybe it isn't? enough 168's could do a fairly decent job controlling a rocket into space which is another field I'd love to tinker with = )

The Mega was released as anticipated so I didn't see any point in continuing the development of the dCore.

It proved a couple of theories during its time, like the shared oscillator works flawlessly, and that there was an inexpensive means of adding a second UART to a 168.

If you develop any further enhancements then I'm sure there'll be those in the community who'll find a use for them.

I'll admit my goals probably overlap with at best a narrow portion of the Arduino community, but the "dual core" concept is attractive to me vs. a Mega for a few reasons: it's cheaper than buying a Mega, and it's "easier" to embed in a custom PCB: soldering two through-hole 328 chips is easier than a TINY 100-pin SMT package. Plus, it lends itself to breaking up functionality into meaningful "chunks" as someone else mentioned.

At any rate, it looks like I'm going to proceed with a "dual core" implementation, with communication via I2C. I'm trying to decide what functions to put on which chip, hence I was wondering if people have code showing I2C communication beyond just "hello world" type stuff. If or when I get to the point where I have something worth sharing, I'll definitely post up in case others are interested.

From what I can gather, it is simply a "plug-n-play" implementation of a microcontroller that allows for easy implementation of a multiple-processor system, in many different configurations (not necessarily all co-planar).

As for what you could do with such a system?

Basically anything where you need multiple nodes where each node can perform calculations independently (or nearly so) of the state of other nodes, then combine the results; ie - your classic parallel processing use case.

Examples of problems that lend themselves well to such systems:

Neural NetworksRay TracingParticle SimulationCryptoanalysis

These are only a few examples; the real question is (especially in the case of the Arduino - not so much for the X Machina, since it uses, IIRC, a better microcontroller than what the Arduino uses) is whether such a collection of low-powered nodes can out-perform other, more standard systems (like a PC) at the same task. There is also the question of programming such a system (not an easy task - otherwise everyone would have a small Connection Machine under their desk).

Even so, a smaller number of nodes (a small cluster of smt ATMegas on a shield or perhaps a separate board) could be useful for many other applications; I've had in mind for a long while an idea for a board that, using 3-4 I2C coupled ATMega328s, a GLCD, a speaker, etc - could be turned into a handheld gaming platform, or a low-speed oscilloscope, or even a low speed, multi-input digital signal analyzer.

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

Thanks for the information. I'm probably of a similar mind to ill_switch and am happy to add additional 168's / 328's if one isn't enough, and your hand held gaming platform sounds like the kind of fun project people here would enjoy.

@ill_switch

Before the Mega, and perhaps the dCore, one of the most frequently posted topics was the issue of the 168 and how to connect more than one serial device. That gave rise to a lot of work on the software serial library, which has undergone several impressive revisions over the years.

However, at the time I investigated the SS library, it didn't have any of the buffer features it now has so capturing data from a serial device, like an RFID reader, mean't the main program loop would freeze until data was received from the device.

To solve that problem, I connected 2 Lilypads over i2c. One connected to an RFID module, the other connected to a bluetooth module. The objective was to scan an RFID tag, send the TAG data over i2c to the second Lilypad, the second Lilypad then transmitted the TAG data to a PC, and the PC then sent an acknowledgment back to the second Lilypad which blinked a LED to inform the user the TAG data had been received by the PC.

To do that job it wasn't necessary to use anything more than the TWI library examples. It was a quick fix to an otherwise stubborn problem, but the result was the worlds most inexpensive handheld RFID reader, and at that time, devices with the same capability were selling for between 900 - 3500.

So there's a lot that can be accomplished using just the TWI library examples but it all depends on what you are hoping to do. I would speculate that most communication needs between 2 or more 168/328's can be met using the TWI library examples, because the way i2c slave/masters work, there isn't a great deal of scope for changing or improving the way 2 or more units communicate and those capabilities have been well covered in the examples provided.

There are some limitations, so let me know what you've got in mind and I might be able to tell you if it's possible.

Thanks for the information. I'm probably of a similar mind to ill_switch and am happy to add additional 168's / 328's if one isn't enough, and your hand held gaming platform sounds like the kind of fun project people here would enjoy.

Yeah - I have always wanted to build a parallel processing machine, but outside of certain tasks, I just don't know what I would do with it otherwise; and for those tasks, they aren't high enough on my projects-to-do list for me to say "go for it" and build such a beast (though it would definitely be much smaller than the monster I dreamed up and posted earlier!).

As far as the hand-held unit goes, I sincerely hope someone picks up the idea and runs with it; it is yet another project I won't get to any time soon, and I only have one use for it for my current project where I could justify building it. It isn't the money (the thing would be cheap to prototype); its the time and need. I was kinda figuring on building it at a later point as a "debugging terminal" for the robot that I am very slowly building (work and life get in the way!) - I could also potentially build it as the low-speed digital signal tracer as well; but whatever form I did it, I would want it to be "open ended", so that if you wanted to use it to build "whatever" you could.

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

It's a common problem for us Arduino fans never having enough time to dabble in the pastimes we are passionate about.

If I could turn the clock back to when I had less of life's realities to deal with, then there are many things I would like to spend copious amounts of time inventing using Arduino as the framework.

So sometimes I look forward to the age of retirement, my beauty will be gone and I'll probably need a full time nurse to wipe the dribble from my chin, but my creativity will be at its peak and I'll have all the time in the world. Unfortunately thats still some 40 years away but we all need something to look forward to right?