The Arduino is a great platform for getting code running on a microcontroller, fast. What it lacks is an environment for dealing with multiple activities simultaneously. That is, as far as real-time concurrency is concerned, you are on your own. But getting many activities to occur concurrently is what makes embedded system programming difficult. So there is a contradiction here. For ease of use, real-time concurrency needs to be built into the system, so that the user does not have to think about it.
What has this got to do with hardware objects? Well, the use of hardware objects naturally brings concurrency into an environment. Each hardware object has it's own microcontroller, and so concurrency is a physical fact. Each microcontroller represents at least one concurrent process. If hardware objects can be made cost-effective and easy-to-use, they provide a possible solution to the problem of making an Arduino-based system that can grow.
There are variety of hardware objects available from web retailers such as sparkfun.com, suitable for use with the Arduino. Which brings us to the next problem. There is also a variety of physical interfaces and protocols used for such objects. I have been working on finding a common interface and protocol suitable for any hardware object: sensors, actuators, controllers, and so on. At the same time, keeping it simple enough that it is not overwhelming to the user.
I prefer serial interfaces as they require fewer connections and so reduce hardware cost and simplify wiring. I prefer text protocols, as these tend to be easier to generate and view in a human-readable form. Keyboards, printers, cell phones, etc all "prefer" plain old text. There is some additional cost in throughput (as it takes longer to transfer information as text), but most of the time this is not a show-stopper.
Watch for updates on my progress with Arduino interfacing in the coming weeks.
