Eric asked me what I think of the Tessel! Well, sort of. Anyway I find myself delighted to have semi-informed thoughts about hobbyist microcontroller-y solutions. It’s a pleasant byproduct of all the time I’ve spent on silly electronics projects over the last decade, and makes me feel better about my own perpetually-dawning software senescence.

But so: the Tessel. Will it succeed? Is it worthwhile? You can read about it here but the important details are that it’s got wifi and a bunch of GPIOs and its development environment is built around Javascript — so much so that it can allegedly run many many node.js packages!

That’s all potentially interesting, but its odds of success can’t be understood outside of the environment it enters. So let’s talk about the two gorillas in the hobbyist space: Arduino and Raspberry Pi.

Raspberry Pi is a really cheap Linux computer with 256 MB of RAM. Like, $25 cheap. No onboard wifi — it’ll cost you another $10 to add ethernet (and double the RAM), or about the same for a USB wifi adapter. But it’s a pretty capable little system! There are some GPIOs, but not that many, and they’re not that robust, and there’s only one hardware PWM output, which is annoying if you know what that means. It’s also not open source. Still, it’s a genuine Linux system, which makes it able to harness an immensely powerful library of software. And its makers seem to have a sweetheart deal with Broadcom that enables their price point.

Arduino is a friendly microcontroller environment, and I should probably explain what that means. A microcontroller (uC) is a little computer — so little that it suffers really serious limitations. For instance, it’ll usually have less than 1MB of memory, and it’ll run thousands of times slower than your laptop CPU, and it’ll only be able to manipulate integers and have no video output or keyboard input. Pretty sad! On the other hand, it only costs a couple of bucks. And this list of capabilities isn’t too dissimilar to, say, the videogame systems you had growing up (if you’re as venerable as me, anyway).

The cheapness of uCs mean they can be singleminded. Your computer is doing a ton of things all the time. Its most fundamental pieces of software decide how to split up processor time between those things, like a library of fantastically complicated clockwork systems that need to be cranked forward, one at a time, by one very spritely curator. The curator has pretty good instincts about how to manage her charges, but sometimes she remembers it’s time to rebuild your search index or sync your system clock or check for Chrome updates or whatever, which means everything else might not get her attention right when you expected it would.

This is mostly fine, but it doesn’t work very well when you need extremely precise timing. Everything is so fast that it’s mostly still pretty precise (and you can pursue some ridiculous hacks to make it more precise still). But when you’re dealing with the real world, or finicky electrical systems, the need for very precise timing comes up more often than you’d think.

Microcontrollers are pretty good for this kind of thing. They can just sit there running one program because they’re so cheap. The curator’s attention is undivided; her behavior is predictable.

Arduino isn’t actually a chip, it’s a development and deployment environment wrapped around a particular family of chips made by Atmel. It makes it a hell of a lot easier to write code for those chips. Even that comes at a cost. My dumb Christmas lights require communication in 10 microsecond pulses (rather pokey as these things go). But if you look at the “Timing” section of this post you’ll see that to fake a 10-ish microsecond delay on Arduino you need to tell it to delayMicroseconds(3) or delayMicroseconds(4) depending on the Atmel chip. The Arduino environment introduces overhead — it’s a bit finicky. Still! The Arduino is much better about this stuff than the Raspberry Pi.

(In the real world, sophisticated processors deal with applications that require precise timing requirements by speaking to microcontroller-like chips that handle their responsibilities precisely, but which can also speak to the main processor in a relatively timing-insensitive manner. Your sound card — or, more likely, the part of your processor that used to be a distinct component called a sound card — is a good example. Some of my current projects use a Raspberry Pi to speak to an Arduino to speak to an LED controller chip, which is less silly than it probably sounds.)

So! Enough preamble. Where does the Tessel lie on this continuum?

I think it’s almost certainly going to be more Pi-like than Arduino-like. The fact that it’s Javascript-focused is notable (though it’s also worth noting that the BeagleBone — a Raspberry Pi precursor — also pushes a JS-first approach). It’s a testament to the shockingly widespread impact of the V8 engine on our technical culture — one of the many genuinely unselfish things that Google has given to the world.  We’ll have to remember this when they’re forcibly uploading our brains a few years from now.

Could the Tessel run a Javascript environment in some incredibly constrained manner that allows for precise, uC-like timing? Eh. Maybe? It seems pretty unlikely to me, particularly given all the general-purpose node.js packages that it claims to support. If you want a high level of precision, you need to know about and account for everything the system is doing. That means you can’t work at a particularly high level of abstraction, as the Arduino example above hopefully demonstrates. You probably need to write assembly or C, not an interpreted language like JS that passes through a black box of voodoo optimizations. This is particularly true for an environment like node.js that emphasizes asynchronous approaches with somewhat unpredictable timing (says the guy who’s never written any node.js code). And even if that sort of thing were easy to do in node, all those package authors would not have done it, since the Tessel didn’t exist when they did their work.

It seems most likely that the Tessel will be a stripped down *nix environment (the Tessel’s processor is a cheaper installment from the same ARM family that powers the BeagleBone). But it’ll only have 32 MB of RAM! You can run a tiny OS in that — I’ve done it plenty. But it’s going to suck in various ways. And I’m not really convinced it’s going to be cheaper than the much more capable $25 Raspberry Pi.

The Arduino, meanwhile, is waiting at your neighborhood Radioshack for $30, and Chinese clones can be easily had for $7 or less.

The Tessel, I think, aims to land between Arduino and the Pi. And that’s not crazy. Making this stuff more accessible is really worthwhile! Building a lovely little network-capable platform with handy modular sensors and helper libraries is worthwhile! Getting an Arduino online is terrible and expensive, and the Raspberry Pi’s universe of shields is still a bit underwhelming. There is good work yet to be done.

But both of those projects are hugely popular. You shouldn’t underestimate how important those network effects are. I spent a ton of time on BeagleBone, then gave up. Other than price, it is a much better platform than Raspberry Pi: it’s fully open, has more GPIOs and a better processor. But people got so excited about the Pi, thanks in large part to the enormous publicity it attracted. Seemingly overnight I could pick from a million awesome tutorials penned by brilliant people eager to figure stuff out for me. Same goes for Arduino.

Could Tessel carve out a new niche? Sure. I think it’d have to offer something new, though, and I’m not sure it does. The Tessel looks nice, but it’s probably not going to be cheap enough or offer enough additional utility over established platforms to become a huge success. You can run node.js on a Pi, after all.