Computing stuff tied to the physical world

TFoC – The Fabric of Computing

So what is it with computing with limited resources? How can kids with enough time on their hands, a dose of ingenuity, and access to very limited (in today’s terms) computers create all sorts of software which fits and runs in 2000 to 8000 bytes of memory?

While everything we build today with something like the Arduino IDE takes at least that much before we even start adding our own code? Want floating point? Sure, add 5 KB. Want a serial port? Sure, another 2 KB. Not long after, everyone starts to complain that an ATmega328 with 32 KB flash memory and 2 KB RAM is too limited for “practical use”.

And now we have this “Medium Density” STM32F103 µC, with 128 KB flash, 20 KB RAM, and it’s still constraining us in what we can express and implement with it.

And that’s just the beginning: to build an ATmega sketch, you need the Arduino IDE v1.6.5, which needs over 370 megabyte of disk space and several megabytes of RAM to launch. Through this, we create a dependency, where the code we run needs a specific setup on our laptops to create and debug, while the code we upload to the µC needs dozens of kilobytes, and can’t even be inspected (let alone tweaked) without the big Arduino IDE setup nearby!

What happened to the engineering challenges of putting a man on the moon?

Many programming languages over the years have accomplished amazing feats in terms of “bang for the buck” – implementations which were able to accomplish a task with far less complexity than one would expect.

To name a few older ones: BASIC (1964), APL (1964), FORTH (1970), Scheme (1975), Icon (1977), Turbo Pascal (1983), Delphi (1995), but also Factor (2003). Many of these offered a very responsive “immediate execution” mode (or at least made it appear that way).

Then there are all the now widely-used scripting languages, which do have a fairly massive implementation compared to the above, but which let you implement your stuff using very few lines of code: Lua (1993), Perl (1987), Python (1991), Ruby (1995), and Tcl/Tk (1988).

And lastly, there is JavaScript (1995). Two decades old, yet very likely the language used on most computers in the world. It’s in all browsers, it’s having a substantial impact on servers via Node.js (2009), and now there is also a small implementation, i.e. Espruino (2013).

So what is it with all these “programming languages” and their implementation? How can some of them be so small, yet so expressive and so effective? And what do we really need, when it comes to ultra low-power microcontrollers, each playing a different role as nodes in a Wireless Sensor Network, for example? How about home monitoring and automation?

Screen Shot 2015 12 02 at 14 34 29

Let’s collect all these questions under the topic The Fabric of Computing. What can we learn from the past? Did those crazy limited “computers” with a few kilobytes of memory make sense then? How about today’s low-end “nodes” – could we apply these ideas again? Can we find new low-end solutions, without having to fall back to low-end concepts?

Do we really need to program in C/C++ for a few sensor readouts plus some simple rules?

There are no obvious and quick answers. If there were, this topic wouldn’t even come up. One trend is already clear: the emergence of larger energy-efficient µCs, with hundreds of kilobytes of flash memory, able to store the code for sophisticated “network stacks”, i.e. libraries which take care of everything, from TCP/IP to WiFI, or BlueTooth, or LoRaWAN.

But what if all you need is an RF node to report temperatures or to sense an open door?

The idea is to make “TFoC” a recurring topic in upcoming articles. These questions deserve to be investigated. Since complex solutions lead to complex behaviour, let’s aim for simple!