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.