• Moving Faster with io.js

    Friday, March 6, 2015

    3/6/15– Jon McKay

    After building a custom JavaScript engine for embedded devices, we’ve made the decision to transition to io.js for our newest hardware offering: Tessel 2.

    Tessel 1 & Tessel 2

    We had been developing Tessel, a JavaScript powered, Node.js compatible microcontroller, for almost two years. In order to run JavaScript on a Cortex-M3 device, we had built a custom minimal runtime that “transpiles” JavaScript code to Lua and runs that Lua code on a Lua VM. While we are proud of the progress we’ve made with the runtime and extremely grateful for all of the developers who have contributed code, a shift to running io.js on V8 better suits the immediate needs of the community.

    Overall, I strongly believe that this change will make for a much more consistent and robust development experience on the Tessel platform. This shift was motivated by a confluence of factors including power consumption, JS/Node compatibility, and budding story for npm modules with binary dependencies.

    Power Consumption

    When it comes to running JavaScript and Node, the implementation pathway is to either use an existing runtime like V8 (often on top of Linux) or build a custom runtime. Originally, we decided to build our own runtime so that we could put JavaScript on an ARM Cortex M3, thus opening up the opportunity for lower power consumption and “realtime” IO (as compared to using an OS scheduler).

    For a variety of reasons, but primarily the power consumption of the CC3k WiFi chip and the 32MB of SDRAM, optimizing power consumption on Tessel has proved to be futile. For comparison, the Raspberry Pi B+ (running a Linux distro) uses slightly more than 1 Watt of power and Tessel uses ~.85W at 5V. Certainly, taking proactive measures such as aggressive on/off management of the WiFi chip, batching network requests, and only running JavaScript on intervals can reduce this consumption, but not by enough to get weeks or months of battery life. In short, if you’re trying to build a truly low-power application, WiFi is not the right protocol to use and you don’t want to be using JavaScript on the device. If you are using WiFi with a high level language, you’re going to need more power, so you might as well have all of the extensibility and reliability of Linux + V8 instead of a fledgling RTOS.

    JavaScript and Node.js Compatibility

    Perhaps the most pressing reason for using V8 is the promise of JavaScript and Node.js/io.js compatibility. We believed that over time we could cover all of the corner cases of JavaScript with our own runtime, but perhaps we should have taken a cue from the “Wat talk” that it was going to be an uphill battle. While the semantics between JavaScript and Lua are very similar, they are also just slightly different in many ways (For example, the comparisons between null vs undefined vs falsy), and capturing all of those idiosyncrasies has proved frustrating for both the users and developers of the Runtime.

    In addition, the Node.js landscape has shifted. We’ve seen the io.js team fork the Node.js project and start developing new features. We have been fortunate to have an external contributor add relevant Node libraries as submodules, but others must be implemented by hand in Lua. The maintenance and overhead of making sure new Node.js/io.js libraries are consistent with our runtime is yet another uphill battle. For that reason, we’ll be running vanilla io.js on a lightweight distribution of Linux (openWRT). io.js allows us to remain backwards compatible for folks looking to use Node.js, but lets us stay on the leading edge of development.

    I still do believe it’s possible to make a nearly compatible runtime, but it’s going to take much more work than we expected and that resource investment would be an unwise business decision.

    Binary Dependencies

    One consequence of rolling our own runtime is that modules with binary dependencies (the most requested of which has been ws for faster websocket support) are not be able to run on Tessel 1. These modules depend on C/C++ libraries which get compiled on the platform that installed them prior to being able to run them. In order to get these modules to run on Tessel 1, we would need to be able to link them against V8 APIs cross-compiled for ARM Cortex-M3, which would take a ton of development effort. Moving forward, we have a pathway for using these highly requested modules in development. If we use V8, we can stash popular binaries pre-built for Tessel 2’s MIPS architecture and send those over when requested by a project’s package.json.

    The Plan For Colony

    Colony is the name of Tessel 1’s original runtime. Going forward, Technical Machine will continue making small bug fixes in Colony but will not adding any new features. That being said, some of the Technical Machine team, including myself and Tim, are interested in maintaining and improving Colony at a personal level. We’ve thrown around the idea of getting the runtime on standalone, barebone WiFi chip, using only the onboard flash. We’re not retiring the runtime completely, but rather, putting it on the backburner for now.

    So how is this different from Pi/BeagleBone/Insert Linux-based Dev Board Here?

    Several people have asked us how we expect to differentiate ourselves from other Linux-based development boards. The Tessel platform is unique in that we believe we can deliver the best developer experience by abstracting away the underlying OS technology and ensuring there is a clear path to production. We still believe that developers just want to push code, build their product, and deploy it - the underlying technology is only relevant if it gets in the way of functionality. In that vein, we continue to have a Heroku-like deployment process of tessel run on Tessel 2.

    In short, the Tessel platform is still the fastest way to prototype an idea and, with Tessel 2, the fastest way to bring it to market.

    Tessel 2

    #Tessel 2 #Node #Linux #OpenWRT #Tessel #Javascript #Microcontroller #Microprocessor #Jon McKay #Technical Machine #io.js

February 2017

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013