Why Hardware Objects?

The question has been asked: why are you wasting your time on this? Why does it matter? It really is a trivial idea. Apply object-oriented design to hardware. Surely it is more important to come up with the next whiz-bang gadget to titillate the switched-on 21st century audience. And you're working on new ways to control appliances???

The reason came to me a few years back, when I saw a video of how circuits are "recycled" in China and India. So-called e-waste. It made me sick. E-waste is a crime against poor, uneducated people, usually in third world countries. A crime being perpetrated by individuals and corporations, with the consent of governments, in developed nations where smug modern folks absolutely need to have every new gadget that comes on the market.

I am feeling just a wee bit cranky here.

Just the other night, I showed one of these videos (there are lots on youtube) to a couple of friends. I watched their faces as they watched the video. What I saw was the same disgust that I experienced.

So it struck me…that this is the entry point. It is not enough to explain to people all the advantages of hardware objects. The attitude seems to be either…"don't we already have that?" Or…"If it isn't cheaper, who cares?" When you are dying of heavy metal poisoning, you will care!

littlebits

LittleBits is a collection of electronic modules that can be interconnected via a common interface to create simple devices. The interface connector employs magnets, making it easy to quickly connect modules, without the problem of having the connector wrong-way-round. The system was largely created by Ayah Bdeir, a New York artist. There seems to be quite a lot of enthusiasm amongst makers: the system won "Editor's Choice" at a Maker Faire recently.

I don't know a lot about the littlebits. What I know comes from the web site www.littlebits.cc. I have chosen littlebits as a subject to illustrate a point or two.

As far as I can tell, the littlebits modules interface using analog voltages, the value of the voltage being proportional to some physical property. For instance, a voltage proportional to the position of a knob. Also, apparently some littlebits modules send pulses, presumably pulse width modulation (PWM). As PWM is the digital equivalent of analog, it is generally compatible with various output devices that would otherwise receive analog. So might as well consider littlebits to be an analog system.

So take an input device…a knob, for instance…which generates a voltage between 0 and 5 volts. Then take an output device…a light for instance…which receives 0 to 5 volts and sets brightness relative to the input voltage. Connect one to the other. Now when you turn the knob, the brightness of the light changes. Simple. Basic analog electronics.

But if the connection scheme is the same for various modules, you can substitute, say, a temperature sensor for the knob. Now the brightness of the light will be proportional to temperature. Simple. In computing, we call that "device independence". The ability to substitute one device for another equivalent device.

Analog is easily converted to binary (ie a 1 or 0), and so you could for instance have the temperature sensor controlling an electronic switch (ie a relay). So when the temperature goes above a certain specified level, the sensor's output voltage goes above a certain level, and the switch turns on. This is roughly how a thermostat works, if the switch in question controls a heat-generating device. The difference with a thermostat is the the switch needs to turn off as the temperature goes above a certain level, and turn on as it goes below a certain level.

A thermostat is a useful device, but how far can you go with analog modules like these? The limit, in my mind, is based upon the different types of data we use in computing systems. I reckon (and computer scientists may disagree!) there are four primary types of data:

1. nothingness ("null" to programmers)

2. binary: yes/no, true/false, etc, basically a decision

3. numeric values, proportional to a property of an object

4. symbols: usually characters, but also the use of numbers to represent other things

To my reckoning, an analog system can represent 3 of these 4:

1. Nothingness would be the absence of a connection to another module

2. With 0-2.5 volts = false and 2.5-5 volts = true, we can derive binary from analog

3. An analog voltage is a direct equivalent of a numeric value.

But it seems there is no way to reliably represent symbols with analog.

Next thought. In my work, I represent an analog value with a number. Typically the range of 0 to 5 volts is represented as a percentage of full scale. So 0.0v is "0", 2.5 volts is "50", and 5 volts is "100" (and everything in between).

If you connect a microcontroller to a knob, the analog voltage can be converted to a stream of numbers. These numbers can be transmitted on a communications port. Looking at the output of the port (say with a terminal program on your computer) you might see 1 1 1 1 1 2 2 2 3 3 3 (etc) as the knob is turned clockwise.

If you connect another microcontroller to a light, these numbers can be received by the microcontroller's communication port and used to set brightness to the equivalent percentage of full scale. So the microcontroller receives the input 1 1 1 1 1 2 2 2 3 3 (etc) and the light gets brighter. Turning the knob controls the brightness of the light, just like with analog. Amazing.

This is similar to how lighting in theatres is often controlled. That is, with a communication protocol called DMX512, which is essentially just a stream of numbers. The stream is generated by a lighting control desk and connected to intelligent lights that know how to capture these numbers and set their own brightness accordingly.

These ideas are all straightforward, but they lead me to several conclusions that have a bearing on the design of hardware objects:

1. The concept of connecting one analog property to another is workable for some applications (illustrated by littlebits).

2. Analog is very intuitive (note how the kids take to littlebits).

3. Therefore input-property-to-output-property connectivity has a place in the world of hardware objects.

4. It is possible for a digital system to do the work of an analog system, but it is not possible for an analog system to do the work of a digital system.

5. Analog does not work for the representation of text characters. So no keyboard, no text displays, and so on. Nor does it work for symbols that represent the state of a machine. So no intelligent behaviour. And so on.

When you add the use of symbols, you need to add software to specify them. But in doing so you lose the intuitiveness and immediacy of analog. Food for thought.

Concurrency on the Arduino

Matt Jadud at the University of Kent brought my attention to their platform for concurrency on the Arduino. Matt points out that while the system implements concurrency, it is not hard real-time (ie it is like most of the operating systems we use today). It might be fast, it will probably work, but it is not the precise clockwork that is a hard real-time system.

The U of K work is fascinating, and though perhaps not directly related to hardware object technology, there are some noteworthy similarities and differences. To learn more, have a look at their website, www.concurrency.cc. My observations to follow...

You're back...now, my observations? It was interesting to see the occam language in use in 2010. I looked at it in the '80's, when we were evaluating the Transputer chip for a parallel processing system for graphic rendering. I recall all of our team members were very impressed, but we went with standard 32 bit processors, for the usual reasons: software compatibility and reliable chip sourcing. I find it interesting that such "outside" computing ideas keep surfacing, ideas that are profound but do not catch on due to market forces or the inertia of old ideas.

From watching the U of K video, I culled that occam implements communicating concurrent processes. The effect is like wiring electronic circuits, or piping in Unix. So naturally it lends itself to graphical representation as a block diagram with connecting lines showing the flow of data. I gather they plan on doing a drag-and-drop graphical programming environment. Cool stuff. Hope to go have a look next time I am in Kent! No kidding!

How does this compare to hardware objects? If one were to run a multitasking environment like this on an Arduino, you have one processor running many processes. With hardware objects, you have many processors each running one process (by the way, according to my definition, each hardware object has it's own processor).

Pros and cons? With a single processor, you have the problem of fitting the capabilities and cost to the problem at hand. A good fit might use 70 to 80 percent of the chip resources available. But typically, resources will either be under-utilized, or (much worse!) you will run out of resources just when you are on the verge of getting the system working.

With hardware objects, the door is open for the gadget to grow. OK nit-pickers, not absolutely true. But generally speaking, a multiprocessor system will more easily scale to fit the problem at hand. Want to add a text display? Just plug one in. With the single processor system, you'd be adding the text display code to your project, then hoping it would fit into the memory available, and hoping that the time required to process would not break your application.

With a multitasking system, as more processes are added, the processes already running will likely have to slow down, changing the behaviour. This won't happen with hardware objects, as the process owns the processor, so the exact behaviour of each object is known no matter how many objects are in the system.

One last thing, lest I start sounding like an overly-biased evangelist. While a hardware object system is not limited by processor resources, it _is_ limited by communication speed between processors. This is becoming frightfully clear to me. It is the crux of the matter, really. I'm working on it.

Notes on Arduino

I've been experimenting with the Arduino. If you don't already know about it, it is easy to find.

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.

Simplicity vs Capability

Generally speaking, the greater the capability to be built into a hardware object, the more complex the interface will need to be. Yet simplicity-of-use is a very desirable feature. Capability and simplicity are two forces that need to be balanced in design. Complexity is related to quantity. Fewer items = simpler.

To squeeze the greatest amount of capability out of the fewest items, choose items that matrix. Consider cars, for example. We could have 6 models and 6 colours. If each model is available in each colour, we have 36 different things (6 models x 6 colours) which can be known by knowing only 12 things (6 colours + 6 models). If we also offer a manual or automatic transmission for each model, we have 72 variants (6x6x2), defined by 14 items (6+6+2). And so it goes. As long as the items matrix, we get more possibilities for fewer items.

The items in the example are properties of the object Car: .model, .colour, and .transmission. These are independent variables. The simplest, most powerful object interface will result from a collection of properties that are independent variables.

This idea works as long as there are no exceptions. If one particular model is not available in one colour, the simplicity is lost. As a rule, exceptions are bad news.

More Generalities

So where to start when designing hardware objects? My approach has been to look around at what has been made so far, starting with the simplest and most common devices. For instance, lighting control. There is the ubiquitous light switch, can't get much simpler than that. In terms of objects and their properties:

Light.on = 1; // turns the light on

Light.on = 0; // turns it off

The next most common lighting controller is the dimmer. It might be implemented like this:

Light.brightness = 50; // set light brightness to 50%

Light.brightness = 0; // set light brightness to 0% (turn it off)

(and so on)

Clearly the "brightness" property can be used to implement the "on" property. Say you want to be able to set the brightness with a slider, and then switch the light on (to that brightness) or off, using a switch.

You could write some code:

int curSwitch = 0; // variable storing switch state, connect to switchChange() event

int curSlider = 100; // variable storing slider position, connect to sliderChange() event

void setBrightness()

{

Light.brightness = (curSwitch == 1) ? curSlider : 0;

}

void switchChange(int state)

{

curSwitch = state;

setBrightness();

}

void sliderChange(int percent)

{

curBrightness = percent;

setBrightness();

}

There is no problem per se, but the hardware object could easily be doing more of the work. By implementing the .on and .brightness properties separately, this same effect can be created by simply setting properties in response to change events.

void switchChange(int state)

{

Light.on = state;

}

void sliderChange(int percent)

{

Light.brightness = percent;

}

My point: when designing hardware objects the goal is not to eliminate redundancy to create a minimal object. The goal is to design an interface that implements common behaviours, offloading these from external processes.

Hello

I've been working on hardware object technology since 2003. It is a simple concept, really just putting two and two together. Reusable objects work in the software world, so why not extend the concept into hardware?

While there may be various ideas of how to define "hardware object", I see it as the marriage of an object-oriented device driver to a microcontroller-controlled circuit board, implementing a specific atomic function. A standard interface is required, that is, there must be a means by which collections of these hardware objects can be interconnected using a common protocol and common hardware interface.

It's a software object that brought along it's own hardware!

An example of a hardware object would be a LED light with an embedded microcontroller. Communication to the microcontroller might be through a serial communications interface. One could send a command to the light to say "set the brightness to 50%"...and the light would respond accordingly. There would be no need to know the internals of the light hardware or firmware design, just as one does not need to know the implementation of a software object to be able to use it.

The product name I gave to the hardware object system I am designing is "microappliance". This is a registered trademark. The rationale behind this name is that we have seen an evolution, from microprocessor to microcontroller, and the microappliance is the next step. A microappliance is a microcontroller circuit endowed with firmware implementing a object-oriented protocol and hardware interface, to implement a particular atomic function.

A simple example: a dimmer, and a light. The dimmer has a slider control. A microcontroller monitors the slider position and outputs "set value" messages on a serial interface. The microcontroller embedded in the light receives these messages, and adjusts the light accordingly.

It's a simple idea, and clearly not entirely original. It is rather obvious. I contend that his is the future of electronic hardware.

The goal of this blog is to track this technology as it moves forward into becoming a reality in the marketplace. Please let me know if you have news to contribute!