As I've noted, software defined peripherals has been done before, by at least Scenix/Ubicomm (bankrupt), Parallax Propellar, and the XMOS chips. If you wanted to stretch a bit, you could include TI's PRU (featured in the BeagleBone) and the Cyprus PSoC's (programmable analog peripherals).
Another comment: parallel programming is still hard, whether it's cooperating virtual Arduinos or cooperating PLC tasks (side story: I recently realized we had some deadlocks in some structured text PLC code involving a couple of separate cooperating programs. It escaped dedication because it doesn't show up under normal circumstances...)
I've never determined where the product name Arduino comes from, other than it's an Italian given name or surname. However, it seems to me it could be derived from the Italian word arduo which means "difficult" or "arduous". However, -ino is a diminutive suffix so arduino would mean "only a little difficult".
Following this reasoning, arduissimo would mean "really, really difficult". Not a great marketing concept for an FPGA product IMO :-)
@TonyTip "software defined peripherals has been done before"
Well, I never said that I invented virtual peripherals, for sure I didn't. But the point is, that the technology I'm using (System Hyper Pipelining) has many advantages, especially for the system architecture. One out of many potential features is, that it is very, very suitable for virtual peripherals. Only because virtual peripherals are known since the beginning, does that mean I should not optimize the flow for it so user can utilize it.
But since hyper pipelining is a known technique , whose to say someone like XMOS isn't using it in their chips ? It certainly looks so from their low cost.
So i wonder , whose you're target customer, and what benefits over xmos do you offer him ? one that justify the drawbacks of this against xmos(more expensive, less mature tools, no virtual periperial libraries, much less value in learning this system for experience ) ?
I'm not sure if SHP is a very, very known technique – otherwise it would be used more often, I guess. I will unroll the full technology concept of SHP in one of my next blogs on this site. So stay tuned.
So this project is more or less driven by some research fun and the enjoyment you have when analyzing the concept and when you are playing with it in real life. We will see where this all leads to and how it differs from other concepts (like the one you are referring to for instance).
If you like to go with some other concepts, go with it.
If you like to play with a new system architecture and providing suggestions how to improve it (just like some nerds do right now as I pen down these words) then feel welcome and help us by funding this project.
The initial version is based on the Atmega 2560 (so the full AVR-8 instruction set).
But there are others in the pipe: (MSP430, ARM3,) OpenRISC 1200 and a self designed Cortex M3, but I would like to release the AVR-8 first. You know, this project is not set up to compete with some other guys, it is more about to demonstrate how you can make off-the-shelf CPUs (e.g. opencores.org) more efficient using SHP, that's it. But I guess you know that since our good old APP times.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.