USB communication between Tessel and Node on your PC

7/29/2014– Kevin Mehall

This post is an introduction to using USB to communicate between Tessel and Node. Find updates and more examples here.

In addition to loading code, you can also use the USB connection to Tessel to pass data between your Tessel and Node.js on your PC. Combine your Tessel’s easy access to hardware and your computer’s processing power to do things neither device can do alone.

Messages are JavaScript objects. It uses structured clone, which beyond JSON, supports cyclic structures and Buffer, RegExp, and Date objects.

We’ve built an example for you to expand on:

git clone
cd docs/tutorial/usb_messages
npm install

The directory structure looks like:

  /host.js         -- script that runs on the computer
  /node_modules    -- npm modules for the computer
    /tessel        -- the Tessel host-side USB module
  /device          -- this entire directory will be deployed to Tessel
    /node_modules  -- all the libs that run ON Tessel go here (camera, ambient, IR, etc.)
    /device.js     -- the main script that runs on Tessel
                   -- other JS files for Tessel go here

Both Tessel and Node run JS, but you don’t want all your host-side code on the Tessel. The host and device each have their own node_modules for npm packages. Only devices/ is sent to the Tessel, because it has its own package.json.

The tessel command line tool functionality is also exposed as a library. host.js uses that library to take the place of tessel run, and not only deploys your code to the Tessel, but also communicates with it.

The Tessel code, device/index.js, simply demonstrates sending and receiving messages.

To try this example, run node host.js. It sends the device-side code on the Tessel as it starts.

Here’s the code that runs on the PC: host.js

// When we `require('tessel')` here, this is the library out of `node_modules`
// for USB communication. It's not the same as the `tessel` module built into
// the Tessel firmware that code on the Tessel uses for hardware access --
// that's only available to JS that executes on the Tessel itself.
var tessel = require('tessel');

var script =  require.resolve('./device/index.js');

var opts = {
  // Stop existing script, if any
  stop: true,
  // Serial number (`undefined` picks the first one)
  serial: process.env.TESSEL_SERIAL,

var args = [];
// `tessel.findTessel` finds a Tessel attached to this computer and connects.
tessel.findTessel(opts, function(err, device) {
    if (err) throw err;

    // Once we've found a Tessel, we tell it to run our script. This works just
    // like `tessel run` and bundles the `device/` directory. It bundles only
    // `device/` and not the host code because `device/` has its own
    // `package.json`., args, {}, function () {
          // Connect the stdout and stderr of the process running on Tessel to
          // the console, so that our `console.log` messages show.
          var count = 0;

          // `device.send(msg)` sends an object to Tessel. It supports JSON
          // compatible objects as messages, with the addition that `Buffer`s,
          // `Date`s and cyclic data structures are also handled properly.
            device.send({count:count++, data: {obj: 'demo'}})
          }, 4000);

          // `device.on('message', function (msg) { ... })` receives an event
          // when an object is received from Tessel.
          device.on('message', function (m) {
            console.log('[PC] Message from Tessel:', m);
          // Exit cleanly on Ctrl+C.
          process.on('SIGINT', function() {
            // Try to stop the process on the Tessel

            setTimeout(function () {
              // But if that fails, just exit
    'Script aborted');
            }, 200);
          // When the script on Tessel exits, shut down
          // USB communications and exit
          device.once('script-stop', function (code) {
            device.close(function () {

The code that runs on Tessel is very simple: device/index.js

// The `tessel` module built-in to the Tessel firmware for access to hardware
var tessel = require('tessel');

//When a message is received from the computer, this event triggers.
process.on('message', function(msg) {
  console.log("[Tessel] Message from PC:", msg);

var counter = 0;

// Every 5 seconds...
setInterval(function() {
  // Send a message to the computer
  process.send({count: counter++});
}, 5000);

// Keep the event loop alive 

When a message is received from the computer, the process.on('message', function(msg) { event triggers.

To send a message to the computer, call process.send(msg)

Code examples in this document are placed in the public domain.

See the code on Github here.

Digital Fireworks with Tessel

7/18/2014– Jon McKay

Image source: Matthew Bergman

Background Context

Several months ago, Eran Hammer messaged me about helping him with a project he was working on for NodeConf. My only experience with Eran Hammer up to that point was watching his over-the-top presentation at Realtime Conf. I’ve since forgotten a majority of the presentation, but I do distinctly remember a dime bag containing blue rock candy, dozens of remotely controlled mortar and pestles, and several hundred pounds of dirt and edible plants in a warehouse. In short, it was weird and intriguing and made me feel vaguely like I had abused moderately-strong hallucinogens.

Naturally, I was excited about helping with the next project, especially since I could develop it on Tessel.

Eran was set on creating an LED fireworks display to be “set off” on July 4th. The idea was scaled down from an overhead, 15 foot wide, 10 foot long LED grid (estimated cost of $75000) to “simply” 1260 Neopixel LEDs laid out in the shape of an exploding firework.

You can see a video of an early test or the actual display here.

Now that we’ve finished, you can actually build a similar system yourself by installing the fireworks Node module for your computer and the neopixels Node module for Tessel.

Technical Setup

Eran was in charge of writing the JavaScript library to generate firework animations, and my task was to actually route those animations through Tessel and into one giant strip of Neopixels.

Neopixel is Adafruit’s brand for addressable LED strips using a specific chip called the WS2812. They are extremely popular due to their simple programming interface and mesmerizing light displays.

The difficult part of using Neopixels is that they are very timing constrained (so much so, in fact, that parts of the library for Arduino are written in Assembly to ensure a fast enough data throughput. Heavy timing-dependence doesn’t bode well for a JavaScript application, so I knew this project was going to be a bit of a challenge.

We decided that most of the actually timing-based “pin-wiggling” would have to be done in the firmware layer (written in C) and we would use Tessel’s JavaScript layer to simply pass the fireworks animation from the USB hub to the firmware.

In all, Eran’s laptop ran a Node server responsible for initiating the Tessel script and generating animations, sending those animation as a binary packet to Tessel, and Tessel was responsible for routing the buffer to the Neopixel driver.

Each RGB LED receives 3 bytes of data (one byte for each color) and then uses a shift register to pop those bytes off before sending the rest of the animation buffer on to the next pixel. Each transmitted bit is essentially a PWM signal with a period of 1.25 microseconds. A “0” is represented by a duty cycle of 32% and a “1” is represented by a duty cycle 85% (with a ~10% error margin). At the end of an animation, the signal should be held low for at least 50 microseconds.

Source: Adafruit

Eran and I were initially worried that we wouldn’t be able to get a good frame rate with a single strand of 1260 pixels. A reasonable frame rate for animations is 30 frames per second. To determine the expected frame rate with Neopixels, we’d need to do a little math:

1260 pixels * (24 bits/pixel * 1.25 microseconds/bit) + 50 microseconds = 22100 microseconds, or .0221 seconds per animation frame. In theory, that’s about 47 frames per second, but real life is always a bit slower and we weren’t sure by exactly how much.


Fortunately, our LPC1830 microcontroller features a State Configurable Timer (SCT) which provides programmers with an extremely flexible interface for pin manipulation. Essentially, it allows you to define different timing states associated with different pin inputs and outputs.

In the case of a single strand of neopixels, I could have used 4 different states. A simplified example of how it could work would be:

  • A timer for the entire period. This timer sets the output pin high at the beginning of a bit transmission which makes the PWM active.

  • A timer for the “0” duty cycle completion (at 32% as mentioned above). When this event fires, it will actually check the value of the current bit being transferred. If it’s a 0, then there is no conflict and the pin state will be pulled low. If it’s a 1, there is a conflict, and the pin will not be changed.

  • A timer for the “1” pwm completion (at 85%) will pull the pin low regardless of the value of the bit being transmitted. This is because it’s a 0, it was already pulled low and doesn’t matter, and if it’s a 1, it needs to be pulled down immediately.

  • A timer that only fires at the end of at the end of a 8 bits. This timer will call an interrupt routine to set up the next byte to be transferred.

But in reality, I couldn’t set up the next byte after the previous one finished, because that would cause a delay between when the previous byte was sent out and the amount of time it would take to process the logic of setting up the next one. That delay in the signal would totally ruin the animation being sent to Neopixels and the colors would be all wrong (in the best case).

In fact, what I needed was a double buffer. A double buffer would allow me to set up the next byte while the current byte is being transmitted. I implemented that functionality by adding another SCT state. I set the state of a GPIO pin either high or low depending on which buffer the SCT should be using to generate a signal, and set the next byte in the other in interrupt routines after the previous byte was sent.

Further Work

I ended up finishing the single strand implementation in a few hours, but wanted to take the system to the extreme. Tessel has three PWM pins connected to its GPIO port, and I wanted to enable all three of them to output animation data in parallel, effectively tripling the possible frame rate.

One frustrating weekend, I attempted to add a four more events for the two other pins (each requires two events for the double buffer). Unfortunately, there just wasn’t enough time in the interrupt routine to service three different buffers at a time.

1.25us/(1/180Mhz) = 225 clock cycles to update three buffers

I found that I could update two pwm channels fairly well, but three channels took too long to update. I think my implementation could have been cleaner if I didn’t use so many structs within structs (thanks OOP).

I ran out of time before I could try implementing the more complicated, but ever so elegant and efficient: DMA transfer. DMA effectively allows for the movement of data over physical pipes without requiring any overhead from the processor. You just tell the microcontroller the destination and source of data transfer and it all happens automagically. I wish DMA was taught in more undergraduate computer architecture classes; it’s a really cool technology.

Using DMA would allow us to use all three PWM channels without the overhead of the interrupt routine that takes all too long to update the next byte because the hardware would handle it automatically.

If you’re interested in contributing, this would be a super fun way to get started! As someone still getting familiar with writing firmware myself, I learned a ton about how timing, double buffers, DMA, and PWM work on a much deeper level and was able to visually see my achievement with an awesome light show.

An Interview with unRob: First Tessel Projects

7/17/2014– Kelsey Breseman

unRob, or Roberto Hidalgo, accepted my Skype call from his home/office/headquarters in Mexico. He leaned back on his office chair, put on his round glasses, and lit a cigarette. He was full of words, ideas, and inspirations – turning the camera so I could see electrical diagrams he’d convinced a friend to draw for him on the whiteboard wall, or pulling out a simple case he’d put together for a Tessel project. A couple of times, he called offscreen in Spanish to his business partner/friend/roommate for clarifications on an English phrase or a little fact.

I asked Roberto for an interview because he has impressed all of us at Technical Machine with the many simple but brilliant projects he’s already built with a Tessel and limited electrical expertise. If you haven’t seen his projects, you should check out his YouTube channel.

Kelsey: What’s your background in engineering?

Rob: My father was an electrical engineer. The first node of internet in Mexico, he plugged it in. So I grew up with that kind of stuff when I was really young. And I liked computers.

I got into a program on genomics, but I didn’t go, so I decided to do graphic design. But then I didn’t like school, so I dropped out, and here I am.

Kelsey: I saw that you have a cool domain name as the Surrealist Party– what is it that you do?

Rob: We do software. We’ve done all kinds of stuff. We have clients that are newspaper organizations and shit and we do their frontend and their backend. For web we do Node and Ruby. Most of our backend is MongoDB and stuff like that.

It’s just my partner and me, just the two of us. We’ve been doing this for four years.

The only time we used hardware, we developed a little box that you connect HDMI, you push a button, and it automatically transmits to the internet as live video streaming. That was pretty much the only experience I’ve had in hardware so far.

Kelsey: How did you make that?

Rob: It was just, like, we used an Arduino, and it had a couple of functions. One was to start up the system, because we had an embedded computer, and then we had to control the flow– to transmit, and to get feedback to the operator about the transmission quality and stuff like that.

We ended up doing most of that as a Node.JS server, with johnny-five, and then just communicating through the Arduino.

It was fucking complicated. You have to do stuff in C, and then the drivers don’t work. I actually contributed a couple of patches to the serial node thing to make it work.

Researching that project is how I came to know about Tessel, actually. I thought, it would be easier if I could just skip C and all of the layers behind it. So here we are.

Kelsey: Did you have something in mind to make when you ordered a Tessel?

Rob: Yeah. The first thing I made was– here’s the thing. The elevator in my building goes straight to my house. The keys for this fucking elevator are like eighty bucks. So I thought, maybe I could hack a wireless telephone at the base to make the elevator go. This is me not knowing shit about electronics.

So I just opened the elevator up, and I thought it could work. I could trigger a USB to serial port thing, I could trigger the locate button, then have the handset send the signal to the elevator button and call the elevator up.

The problem with this is that I can’t let my landlord see this. If he comes one day and there’s just wires coming out of the elevator button…

I thought it would be great if I could skip the base, skip the radio protocol, and just use WiFi. So I started researching that.

I wanted an embedded computer that could run a web server and talk through Wifi, and be able to be powered by a small battery. Tessel was just the perfect fit.

Kelsey: So this elevator– it doesn’t go to anyone else’s apartments?

Rob: It can, if you short the right pins, I can get the elevator to go to my neighbors’ houses. But we usually just call it for ourselves.

We developed a telephone to IP, so I made a node module that handles calls. The lady that helps us clean the place, she doesn’t have a smartphone, and we don’t give her keys because they’re so expensive. That was one of the use cases. She just calls this number, lets it ring a couple of times, and then the elevator comes.

I use it sometimes when I’m drunk and I can’t find the keys.

It’s a lot of fun.

The day I got it, my partner was in Brazil for the World Cup. I had a ridiculous amount of work that I needed to do, but I just said fuck it, Tessel is here, and spent six straight hours doing research trying to fix the elevator button I’d burned out, and then I made the Tessel call the elevator.

In that six hours, I was really excited, that’s when I posted the video [Ed. note: this video].

If I knew shit about electronics, I could probably do it in half an hour. Six hours is okay. It was like 5am on a Friday night.

Kelsey: So what else are you planning to make?

Rob: A friend of mine, an electrical engineer, has been teaching me to do bridges. What I’m trying to do now is build a theremin. I did something kind of like that with graphite [Ed. note: this].

My roommate, my partner, he’s very annoyed with me for making these noises.

I actually want to embed a Tessel into a guitar pedal. My guitar broke three weeks ago. I was very sad. So I bought another guitar, an electro-acoustic. I thought maybe I could do a pedal with it, and modify the effects through Tessel and through my phone.

It’s easier to just push a button with your phone than to lean down and mess with knobs.

That’s what I want to do with the Tessel for now.

There’s lots of stuff I’ve been thinking about doing, but I want to know more about how the actual components work.

I’ve enlisted most of my friends to have an electronics playdate. They’re coming in a couple of weeks to teach me stuff. Maybe something good will come out of it.

Kelsey: It’s cool that you’re poking into the electrical side of things.

Rob: Since I was little I always took stuff apart. One time I took apart the washing machine, because I wanted to know how it worked. I got electrocuted, and after that time I was scared about electricity and stuff.

It’s very frustrating. That’s the thing I like about knowing what the software thing does. If you use C and you have to take into account all the memory manipulations, and weird loops, and re-use somebody else’s code, then it’s scary and it’s frustrating, and you don’t do it.

With an entry-level language such as JavaScript, it’s easy. You can screw up, and probably you will burn the thing out. But it’s not very expensive, and with all of the revisions you guys did to the power, probably it won’t.

That’s something interesting.

It makes hardware accessible for people like me who are stupid about electrical stuff.

I know my way around software, and I know how to make things talk to each other, but the actual physical part of it is mind-boggling for me.

The thing that I enjoyed the most was Wifi, built in. It’s ridiculous: the expense of an Arduino, plus a Wifi shield, you have to know stuff. My Wifi network is secure enough for this kind of purpose.

If I used straight radio, anyone within a 300 meter radius could open my elevator. This thing, they just need to know my Wifi network, and my password, and how to talk to it. It’s much more useful in certain cases.

For prototyping, this is the best thing I’ve ever encountered.

My electrical engineer friends, they tell me, I could do that probably in a couple of months. I tell them, yeah, you could do that in a couple of months, with a team of probably fifty people. You could do that for a much bigger expense than– what’s a Tessel? Ninety-nine dollars?

If you don’t want to spend a lot of time thinking about the implementation, but just hacking the idea, this is a great tool.

You guys made a really great thing. It has made me– you have no idea– very happy.

The satisfaction of doing software, and having things move from one side of the screen to the other is immense, for people who like those kinds of things to happen, like myself. But when you translate that to the physical world, it’s just like, you revert back to when you’re six years old and you figure out that you can plug a light bulb straight into the socket, and it will work, and it will do stuff.

Probably it will contribute to changing the culture: we’re not just programming for programming’s sake, but we’re creating stuff, making, building stuff, that’s something interesting. And it’s a lot of fun.

Tessel is in your hands.

7/10/2014– Updates

It’s been about a month since we started shipping, and things have been overwhelming. Let me try to catch you up:


We have a contribution guide! We’re still working on filling it out, but please PR/add GH issues for anything you want to see there.

Here are a few tools we’ve seen so far:

Hopefully the contribution guide makes this sort of project easier– and if you’re looking for a way to help out, we’ve started a task list in the contribution guide repo.


We’re also starting to see some cool projects. Probably the showiest is Eran Hammer’s LED fireworks display from Nodeconf, Rob Hidalgo is definitely the most prolific– see his YouTube channel– and the youngest person’s project we’ve seen so far is a temperature gauge by Dunmail Hodkinson’s daughter. We’ve also started collecting more on our company Pinterest.

In order to properly showcase your projects, we’re working on a projects portal. It’s tailored to helping people share what they’ve made on Tessel in a replicable way– link to GitHub code, pictures and videos, text for instructions, metadata re modules, etc. Expect to see it live in the next week or two– and in the meantime, please take pictures of what you make!

Orders and Support

All of the pre-orders have been shipped, and we’re continuously sending out new orders. We’re working on improving the fulfillment process; it’s been shaky, and we apologize sincerely. Kelsey is in the process of writing a blog post about that process and our plans for better support.

That said, it’s possible we’ve missed a few support requests while figuring out our system. If you have been waiting on a response from us for more than a day, please email again to and we’ll make sure to get back to you right away.

Meanwhile, we’ve seen really wonderful engagement on the forums. Thanks for surfacing issues, fixing each other’s problems, and bringing up your ideas. Keep it up!


Meanwhile, we’ve written a bit to the blog, mostly introducing our three summer interns (Paige, Evan, and Nathan):

All right, other than bug fixes, Nodeconf, and tracking parcels, that about sums up what we’ve been working on! Look forward to some cool R&D soon.

All the best, Kelsey, Jon, Kevin, Paige, Eric, Nathan, Jia, Tim, and Evan

Tessel Run Internship

7/8/2014 - Nathan Lintz

Hi TM Blog Readers,

I’m Nathan Lintz - aspiring DJ, JavaScript ninja, and Technical Machine intern. In my spare time I like to create playlists on Spotify and read Pitchfork to stay up to date on whatever music craze is sweeping the indie charts.

Coffee Time

For the past two summers, I worked as a front end web engineer at Intuit, where I developed a passion for making beautiful user interfaces. As a UI designer, I was frustrated by the limited interaction possibilities afforded by software platforms. What draws me to hardware is the ability to create new user interactions that are impossible on purely software platforms.

With software alone, we are limited to a small set of gestures such as swipe, hover, and pinch. I am interested in leveraging the hardware capabilities of the Tessel to build new forms of user interaction which were previously impossible on a software platform. For example, using the climate module, a program can detect changes in the user’s environment. A clever interface might use this data to blend the UI with the user’s surroundings. An application could use hot colors if it detects the user is outdoors on a sunny day or it might use cool colors if the user is indoors.

Since starting my internship, I’ve been working on some side projects which connect real world devices to software applications. Last week, I wrote an app which sent accelerometer data from the Tessel to my laptop’s mouse using a custom Objective C library that I wrote. I plan to abstract this Objective C library into a framework for controlling any Mac functionality from any Tessel module.

In the coming weeks, I want to build even more devices that can communicate directly with my Mac’s hardware. Some ideas I have are controlling Spotify via text messages or adjusting my screen’s brightness based on the ambient light in the room. If you’re interested in helping me out with these projects, send me a message and I’ll send you the library. You can also follow me on Github (nlintz) to see my up and coming Tessel creations.

New Intern #2 - Introducing Evan

6/30/2014 - Evan Simpson

Last month I left my internship at the world’s largest single-site employer with over 70,000 employees to come join Technical Machine’s team of 6. Well, maybe that’s a little bit misleading. You see they weren’t employees, they were cast members, and they all referred to a single mouse as their boss.

Hey there, I’m Evan, one of the three new interns at Technical Machine, and if you haven’t figured it out yet, I left my job at Walt Disney World in Florida to be here. I made the switch for the same reason many other people choose smaller companies - to have a larger impact. After just a few short weeks here I can say without a doubt that I’ve already accomplished more at Technical Machine than at any other company I’ve worked for. Not only have I been responsible for making improvements to firmware and modules like BLE and RFID, but I’ve also had the opportunity to share what I’ve learned on our forums, and help community members resolve some of the issues they’ve run in to.

Me standing in a parking lot

My biggest goal for the summer is to help make the Tessel and its modules as easy to use as possible. I’ll be spending plenty of time improving the BLE library and contributing to full node compatibility in our runtime. Having a predominantly software background means I still have a lot to learn about hardware, but the team has been very supportive and has helped me learn a lot already.

That’s enough about work - let’s hear some more about me. I move around the country quite often, so I typically spend my weekends exploring whatever new area I’m living in. Bonus points for me whenever I stumble across that restaurant that doesn’t look like anything special but actually has the most amazing food. You know the one - the one only the locals know about. Aside from restaurants, I also enjoy checking out museums and finding a nice trail for running or hiking. When I’m not working full time, I’m actually still a student at Olin College of Engineering, working towards a degree with the words “Engineering” and “Computer” somewhere in the name. I’ve still got one year left come September, and the closer it gets the more excited I am to graduate.

Watch for more posts from me in the future, probably about BLE, and feel free to reach out anytime on Twitter @evanmsimpson, our forums, or email at evan at I’m really excited to be working at Technical Machine where I can surround myself with knowledgeable people, and hopefully learn a lot this summer.


Intern Introduction: Paige

6/12/2014– Paige Cote

Hi there!

I’m Paige, and I hail from the great northern land of Maine. I’m currently working towards a degree in Electrical and Computer engineering at Olin College, with a bunch of bio-engineering classes thrown in for a good measure.

In my free time, I do engineering education research at Olin, read cookbooks, and go to an excessive number of concerts (three, including a music festival, in the last week and a half!)

I decided to join Technical Machine because I really wanted the experience of working for an early stage startup where I could have significant impact on the product. So far, following my inclination to work for a start-up has been an extremely positive decision; it would be an understatement to say that I’m never bored.

This summer, I get to code quite a bit, but I am not exclusively focused on coding. As the summer goes on, I hope to use my newfound Tessel skills to make the experience of using Tessel even better for our users. This means I am doing everything from finding bugs in the codebase to helping define the style guide for all the documentation that an open source project requires. Plus, I get to come up with all sorts of awesome projects for the Tessel, and then get paid to make and document them. Pretty cool, right?

My work this summer is guided by the goal of understanding all the ways Tessel can fit into and improve the the world of connected devices. I’m having a blast so far, and I can’t wait to see where my experimenting takes me.

Expect updates on my projects and what else I’ve been up to in the near future! Until then, you can always say hello on twitter @paigereads, or by email at paige at


JS on MCUs – Only Getting Better From Here

6/6/2014– Jon McKay

As the boxes start rolling out of our fulfillment house, the “pre-order” button switches to a “buy now” button, and I shave my “no-shave shiptember” “beard”, it’s slowly dawning on me what an accomplishment our team has made.

We’re certainly not done polishing, but I’m enormously impressed that the our team of six (plus 3 new interns!) was able to combine the useful qualities of a microcontroller, the internet, JavaScript, and Node.js onto a single device -each of which has already made a significant impact on the direction of technology.

We owe a huge portion of our progress to the entire open source sphere, both hardware and software. We were fortunate enough to use code and hardware designs from the folks at Adafruit, Joyent, and the creators of hundreds of discrete NPM repos. So, thank you and feel free to make use of or contribute to our recently open-sourced code.

The release of Tessel is only the start. We have a roadmap of features and improvements that we plan to release over the coming weeks when we’re not busy fixing bugs:

WiFi Reliability & Wireless Code Pushing: At release, Tessel can be programmed over USB. In the next few weeks, we hope to introduce wireless code pushing so that users can push code to Tessel over the internet. We have already built out the backend server and security infrastructure; we just need to improve the reliability of our WiFi connections and finish writing the client code that runs on Tessel.

Execution Speed: As you might expect, running an interpreted language on a microcontroller is pretty slow compared to a compiled language. The good news is that Tessel’s runtime is just about as slow and bulky as it ever will be. Programming microcontrollers with JavaScript is only going to get faster, lighter, and more reliable. We’ve got some tricks up our sleeves, primarily switching to a LuaJIT architecture, to drastically improve the speed of execution. It’s one of our top priorities as we prove out the viability of higher level languages on microcontrollers.

Node Compatibility: The most common and applicable Node libraries will all be available on Tessel (Streams, HTTP, EventEmitter, etc.). However, some less applicable libraries are not yet available. We will add support for vm, child_process, readline, repl, tty, debugger, and zlib over time after shipping. We don’t plan to support the cluster (you’ve only one core) and domains library. You can follow our progress on our compatibility page and if you’re interested in helping out develop our open source software, shoot us an email ( We’d love the help.

As a young company that has yet to hit it’s first birthday, feedback from the community is the most important factor in the direction of our company. If you see something you like, something you want changed, or something you want removed, please, please, please get in touch. We’re available on our Forums, Twitter, Email, or in person:

1101 Cowper St
Berkeley, CA 94702
United States of America


Hardware is *different*

6/5/2014– Eric Kolker

You hear the phrase “hardware is hard” a lot these days, usually when someone is new to hardware, and often in the context of what it takes to build it. Without forcing words into peoples’ mouths, the speaker is generally trying to convey the sense that building hardware feels more difficult than building other things because there’s so much to keep track of and think about.

As someone who designs hardware but is joining the world of software, I have some problems with this shorthand dismissal and what it implies. I’m also making a conscious point of saying this just as the first Tessels are hitting your mailboxes and as some of you are getting your first taste of hardware.

“Hardware is hard”

No, it isn’t. Really. If anything, software is just incredibly easy. However, because many people who started off in software are now interested in hardware (hopefully you!), it behooves us all to try to understand what they’ve gotten themselves into and how it’s different from what they’re used to.

Allow me to back up, explain, and then offer some advice before we all leap headfirst into the world of hardware.


Where I come from, this is what robots look like

My background is in electrical engineering. In previous lives, I built and programmed robots small and large – everything from LEGO MindStorms to Boston Dynamics’ LS3, which, at the time, was arguably the most advanced quadruped robot in the world. I’ve designed large portions of a small satellite, an ultra-high bandwidth, medical-grade wireless data link for CT scanners, and my own integrated circuit. I’m used to, and indeed completely comfortable with, creating entire systems which work correctly the first time, due in large part to careful architecting, simulation, and a firm grasp of innards of every would-be black box and pitfall in the system. I’m accustomed to spending enough time planning that the implementation goes off largely without a hitch, which is typically the expectation for electrical engineers.

All that goes to say that hardware engineers must be considerably more careful about the work they do than web developers because the costs of a second chance are so much higher. Case in point: I have never met an EE who would even entertain the notion of "FISI" because doing so is unforgivably irresponsible and expensive on so many levels.

Don’t get me wrong, there are certainly programmers who are more risk-averse than I and whose systems cannot afford to fail. My point is just that many web developers have luxuries which allow them to be a little more cavalier than hardware engineers can typically afford to be. In the end, these luxuries allow for the buildup of bad habits for dealing with hardware.

What’s actually different?

Hardware and software happen at different speeds and require different skill sets. In a nutshell, hardware requires more caution, attention to detail, patience, and knowledge of a broader range of topics than software because most of the time, the building blocks are, admittedly, harder to assemble. The black boxes in hardware are less ideal than those you encounter in software because they exist physically in the real world (as opposed to merely as instances of ideas), and are therefore more sensitive to their neighbors.

Unless you’re talking abot inside an IC, 10 picofarads is a miniscule amount of capacitance

A few choice examples come to mind:

  • Things cost more money and time. Supply chains, fabrication time, shipping, and calibration all have very different definitions and consequences for hardware. Missteps as a result of any of these can destroy companies alltogether.
  • More fundamentally and ironically, because computers start off as electrical systems, each of their operations happen on electrical timescales (the timescales of chemical reactions and light), while electrical systems begin their lives as mechanical systems, which necessarily move much more slowly.
  • In hardware, debugging is not as easy as console.log. Instead, it often requires additional equipment that can cost thousands of dollars and takes time to set up, adjust, and calibrate. Fractions of a millimeter and millionths of a second matter, often tremendously; sometimes electrical systems are so sensitive that measuring the system will change the way that it behaves.
  • On top of all that, a thorough grasp of the system’s physics is often tremendously important, if not essential, to understanding its subtleties (read: pitfalls, failure modes, etc.). This may sound weird, but the simple fact that modern computers are treated as discrete and digital devices with well-defined interfaces is simultaneously one of their most valuable traits and largest liabilities. Because software typically assumes that we can draw hard lines that place things firmly in one of two states, we rarely account for the fact that physical systems are actually analog and asynchronous. These assumptions are therefore implicitly built upon approximations rather than absolutes. …And without getting too meta, the crux of the issue is that problems typically arise due to the approximations we make at the intersections between digital and analog.

Eye diagrams are neat, but if you need to capture one it’s already too late...

So what?

We’ve done our best with Tessel to make sure that you don’t need to do or worry too much about any of the really nasty hardware bits, but you’ll still need to come the last 10%. Understand that the consequences are more real than they are with software if you don’t read the documentation and/or do something careless with the product.

Think about what you want to build, understand your system’s requirements, and set specifications that are both physically possible and sensible. Do research into what goes into anything you build, and ask lots of questions on the forums. I promise we’ll do our best to answer them.

Last but not least, come to terms with the cost of developing embedded systems in JS: performance. Fundamentally, you’re working with an interpreted language (JS) that has been transpiled to another (Lua), which is being interpreted by something other than V8, which is running on a 180 MHz processor. Tessel is certainly no iPhone, but we’re confident that it’s more powerful and more versatile than similar products which run JS because it’s node-compatible and doesn’t need a lifeline to the PC. You’ll be fine so long as you don’t try to stream video, run intensive algorithms, load 14 different node modules, or demand that your loops run at 100Hz.

Call to action

…So what I ask of you is actually pretty simple. Appreciate that Tessel has been about a year in the making and that in order to use it properly you may need to learn a little bit about what goes on under the hood. Together we can make hardware prototyping easier, but doing so will require that we do more than admire electrical systems when they walk by (guilty parties typically include “LED all the things!” and “OMG quadcopters!”). Read our documentation before you run into trouble, then look up anything that continues to misbehave.

Once your projects take you to the edge of what our modules can do, I hope you’ll take the plunge and try your hand at building hardware, and in doing so start to see why the people on my side of the table have the habits we do.

Most importantly, I hope you learn a lot and have a lot of fun, so get out there and start building!