• This Week in Tessel: the busy summer issue!

    Thursday, August 25, 2016

    Hello, Tesselators!


    Tessel Community Survey

    We’re researching the next direction for Tessel Project hardware, and we have six questions for you.

    Help us out by telling us what the future of connected things should look like on this survey!


    The Tessel Team (the Steering Committee and some of the Team Members) are meeting in person the first time at Tesselcamp next week.

    The event will be a low-key three-day session in New York City for core community members to discuss vision, focus on key issues, and spend time together as a team.

    The final day of Tesselcamp (Saturday, September 3) is a community day, in which members of the public are welcomed to use the hardware and expertise of the core Project members and get up to speed contributing to the Project. If you’re in the area, please come!

    For those not in the area, we encourage you to spin your own “welcome to open source” themed events. Want to host one in your local community? Get in touch; we would be happy to help.

    Nodebots Day Recap

    We mentioned International Nodebots Day in the last newsletter, with a special mention of the Johnny-Five Inventor’s Kit as the kit of choice for a few of the event locations, like NYC and Miami. The Tessel 2 was also used to power Sumobots at Houston’s event, with a great recap by Justin Gosses.

    Check out @nodebots on Twitter to see pictures and video from other events around the world!

    More Tessel: Links Roundup

    Things to try

    Things to watch and read

    That’s all for this week! Feel free to submit to the next newsletter. In the meantime, see you online.

    With love,
    Everyone at the Tessel Project

    This Week in Tessel is where we highlight the latest news, projects, and events, from code, to community, to hardware manufacturing.

    #update #twit #this week in tessel #updates

  • Meet a Tesselator - Kelsey Breseman

    Tuesday, August 16, 2016


    A somewhat tired Kelsey Breseman backpacking in Iceland

    A somewhat tired Kelsey backpacking in Iceland

    How did you get involved with the Tessel Project?

    I wasn’t involved much in microcontrollers, or even programming, before Tessel. I’d worked with both a bit in college, but it wasn’t a guiding passion for me.

    The summer after I graduated, I was living with several friends, including the team of three that was founding Technical Machine to build Tessel.

    I had a work-from-home contracting job at the time. Our apartment had no air conditioning, and Boston was really, really hot that summer. So I started showing up at Technical Machine’s office space, and grew interested in the proposition: how do you get people who have no idea what they are doing to try hardware – and not fail? How do you take the world of the Internet – obviously useful, but traditionally accessed via screens (pretty limiting and draining, in my opinion) – and better hook it up to the real world and to physical space?

    Within about a month of the company’s founding, I was showing up to work every day, writing about the project, getting more into programming, and getting involved.

    I can’t claim credit for the idea of JavaScript on a microcontroller, or the implementation (novel at the time) of Wifi on a microcontroller. But I am really proud of the influence I was able to have over the user experience. As a relative beginner in both JavaScript and hardware, I was always asking: how do we make this or that clear to people? How will this feature be understood by someone who has never picked up a wire before?

    As the project developed, I adopted an “I fight for the user” mindset and guided product development as Director of Community.

    Kelsey Breseman speaking at OSCON 2016: “How to build a product when nobody’s getting paid

    When we transitioned to open governance as the Tessel Project, I put together a lot of our new structure and rules and became one of the four founding Steering Committee members. Together, we (now five of us) run the project.

    What do you like best about being involved with Tessel?

    It has been exciting to watch this project and community grow.

    I travel around the world giving workshops on Tessel, and I love that moment, every time, when a person’s face lights up.

    “Oh my gosh!” they say. “It did something! I made it do something!”

    Most of the people I teach Tessel to are people who have never had a success with hardware before. Sometimes, I’m also teaching them to code– that’s a lot of fun.

    Kelsey Breseman live coding on Tessel 2 at NodeConf Oslo 2016

    The other piece that I love is building connections between people– inspiring them to work on things together.

    Community is powerful. If I were to take on the whole of the Tessel project by myself, it would die pretty quickly. But if I can inspire a few people to work with me on it, we can get a lot done.

    One of the biggest challenges is figuring out how to keep a distributed team inspired and engaged. Our team members mostly haven’t met each other!

    It’s an ongoing social experiment for me to create tools and practices that make people want to keep coming back.

    Kelsey Breseman and Flaki (István Szmozsánszky) discussing Tessel at RuhrJS

    I absolutely love when I go off in the woods for a few days, come back to the internet, and discover that someone I’ve never met or heard of has started working on one of our repos. Or, when community members ask support questions, and other community members respond without anyone from the official Team being involved. That feels like community success.

    Outside of Tessel, what are you working on right now?

    I’ve been thinking a lot about climate change recently: reading books and articles on the subject, trying to wrap my head around all the issues at play and the opportunities they create. I’m blogging about my thoughts and taking copious notes, both as a way to help me think.

    The plan is to start a company in this space, though I’m not sure yet of the exact proposition. Climate change is going to require a lot of people to work hard on interesting new problems. I would like to be involved in connecting smart people to interesting, meaningful problems.

    Do you have any advice for people who want to get involved with the Tessel Project?

    Jump in with both feet. We’ll catch you.

    People are sometimes nervous to start contributing to the Tessel Project. By its very nature, it gets people from one field interested in another field they don’t know much about (web, hardware, and vice versa).

    My advice: contribute even if you feel completely unqualified. We have a number of open starter issues.

    This is how you learn. It’s hard. You feel stupid. You put yourself out there on the internet. But we’re here, and we want to help you.

    Sometimes, what you need is a good project to learn on. Tessel was that project for me, and I hope it can be for you, too.


    Kelsey Breseman

    #kelsey breseman #meet a tesselator #tessel project

  • Interfacing with the Language Plugin API for Tessel 2

    Tuesday, August 9, 2016

    This month we merged one of the most significant pull requests for the Tessel project: adding Rust deployment support. For the past three years we’ve focused exclusively on deploying JavaScript on microcontrollers. This is our first step investing in a new language, a new ecosystem, and a new community. However, the purpose of this post is not to dive into the benefits of Rust, but rather to showcase the ease of adding new language support to the Tessel CLI.

    Despite the significance of this addition to the CLI codebase, the amount of code we modified was relatively small. We simply added two main files (along with minor modifications to a handful of other tests): one with the implementation and one with unit tests. The simplicity of the feature addition is a testament @rwaldron’s hard work building the CLI’s language plugin system. In this post, I want to demonstrate how straightforward it is to add support for a new language to the CLI using this plugin system.

    You can deploy an arbitrary code bundle to Tessel 2 (in any language) with the same six general functions:

    1. Determine project location in the file system
    2. Run any compilation/pre-processing steps (optional)
    3. Bundle the executable code into a tarball
    4. Run any pre-execution steps (optional)
    5. Execute the code/binary
    6. Run any post-execution steps (optional)

    These functions are more concisely named checkConfiguration, preBundle, tarBundle, preRun, shell/binary, and postRun (respectively). Here is an explanation of each of those interfaces.

    1. checkConfiguration

    checkConfiguration accepts the directory that was deployed with t2 run ... and returns the path to the entry point of the project. With Rust, we do this by parsing the Cargo.toml and with JavaScript we parse the project’s package.json. It is expected to return an object with a basename and optional program property (for the name of the project).

    // checkConfiguration to confirm project deployment files
    exportables.checkConfiguration = (pushdir, basename, program) => {
      // Should return the file information for the program
      return {

    2. preBundle

    preBundle is an optional step for any processes that need to be run prior to packaging the directory that will be sent to the Tessel 2. For example, when deploying JavaScript, this function is integral to the binary compilation stage (where we inject our pre-compiled binaries in place of existing project binary dependencies). For Rust deployment, this step is less critital but we use it to set some optional parameters (which we could do in the next function as well).

    // Optional function to process options prior to bundling project
    exportables.preBundle = function(options) {
      // Should return a Promise which gets resolved when the code is ready to be tarred
      return Promise.resolve();

    3. tarBundle

    tarBundle is a required step which should resolve a Promise with a Buffer that represents the tarballed code or binary. The CLI will automatically untar the bundle after it is deployed on the Tessel 2.

    In the case of Rust, this was the biggest addition. In order to compile Rust code for Tessel, we needed to set up a special cross-compiler that could compile a binary that runs on Tessel’s MIPS architecture. The easiest solution was to have the CLI send out the project to a preconfigured remote cross-compilation server. The server then compiles and returns the binary to the CLI.

    // This must implement a Promise that resolves with a Buffer
    // that represents a DIRECTORY containing the desired bundle.
    exportables.tarBundle = function(options) {
      // Should return a Promise which eventually gets resolved with the bundle
      return Promise.resolve(bundle);

    4. preRun

    preRun is an optional step that’s useful if you need to call any shell functions on Tessel itself before the project is initialized. For example, with Rust, we set the permissions of the binary to ensure it’s executable. It’s unused for JavaScript.

    // Optionally make changes within Tessel's Linux environment before starting the program
    exportables.preRun = function(tessel, options) {
      // Should return a Promise which eventually gets resolved
      return Promise.resolve();

    5. shell/binary

    t2 run

    binary is a string that represents the engine that runs the program. It is used as the first argument in a shell command to start the program when a project is run. For JavaScript, this string is node and for Rust it’s ..

    t2 push

    shell is a function that could have been named begin because it’s responsible for actually getting the program going when you push the project. The reason it’s called shell instead is because the function needs to return a string representing the contents of a shell script that starts the program.

    exportables.binary = 'YOUR_EXECUTION_METHOD';
    exportables.shell = (options) => {
      return tags.stripIndent `
        exec YOUR_EXECUTION_METHOD /app/remote-script/${opts.resolvedEntryPoint}

    6. postRun

    postRun is another optional step that’s useful if there is code you need to run on Tessel after the program has started (but not necessarily before the program has ended). It’s largely unused thus far so far but was added for future-proofness.

    // Optionally make changes on Tessel after starting the program
    exportables.postRun = function(tessel, options) {
      // Should return a Promise which eventually gets resolved
      return Promise.resolve();


    That’s just about all there is to adding language support to the CLI. There are several more steps that need to be taken to build full hardware support for a language on Tessel. You can follow Rust’s progress in that process here.

    If you have questions about the unit tests or the implementation of new languages in general, feel free to reach out in the #engineering channel of Tessel Slack. Let us know if there are any extra plugin functions you think the CLI needs to accomodate or if you need help building a plugin for the language you’d like to build hardware with.

    • Jon

    #tessel rust programming language plugins deployment compilation

  • This Week in Tessel: the awesome community issue!

    Friday, July 29, 2016

    Hello, Tesselators!


    Vision and Forward Motion: Development Updates

    Kelsey Breseman of the Tessel Project Steering Committee has just published a post with the Project’s long-term vision: Where are we going with Tessel? Rust, Reach, and Fractal

    International Nodebots Day

    NodeBots Day is world wide event where people learn how to control the physical world with JavaScript. Each event has experts on hand to help attendees build their projects and start them on the path to building awesome devices. Overall, it’s about getting together, collaborating and hacking. And lots of JavaScript. This year some events will using the new Johnny-Five Inventor’s Kit (J5IK), which includes the Tessel 2!

    International Nodebots Day: July 30

    More Tessel: Links Roundup

    Things to try

    Things to watch and read

    That’s all for this week! Feel free to submit to the next newsletter. In the meantime, see you online.

    With love,
    Everyone at the Tessel Project

    This Week in Tessel is where we highlight the latest news, projects, and events, from code, to community, to hardware manufacturing.

    #update #updates #this week in tessel #twit

  • Where are we going with Tessel? Rust, Reach, and Fractal

    Friday, July 15, 2016

    The Tessel Project’s mission is to create a fully open source hardware & software platform that makes it easy and intuitive to develop Internet-connected devices.

    With Tessel 1, we tackled the “easy and intuitive” part of that mission statement. This is the main strength of the Tessel platform. Thus far, we’ve best fulfilled these two of our core philosophies:

    Developer experience is paramount. Tessel should be the fastest way to build an idea, regardless of your background (or lack thereof) in electrical engineering or computer programming. Branding, documentation, and engineering design decisions should always take this into account.

    Device design should focus on user experience rather than on implementation. Tessel uses high level languages and modular plug & play hardware (see philosophy here) so that device creators can fully prototype and test device functionality before worrying about optimization and implementation specifics.

    We kept these values with Tessel 2, and began efforts to help developers scale. This pushes toward another core belief:

    Tessel should be practical to use. Tessel as a platform cannot have a big impact unless it is cost effective, reliable, and available for purchase. It needs to be possible to purchase Tessel hardware at affordable prices, from quantity one up to production-level quantities (10,000+).

    (Emphasis added.)

    Where we are: the vision of Tessel 2

    When we designed Tessel 2, we envisioned it as the basis of full-scale products. At the core of its design was the key idea:

    People should be able to scale the tools they use for prototyping all the way into production.

    This is a radical idea.

    If you’re a Node developer, this prototyping –> production path feels familiar. Design is an iterative process; you understand technology and needs better as you build. Modularity lets you swap out packaged components according to your needs. Both Node.JS and Tessel subscribe to modularity. Node has proven out that this approach can scale to production.

    In hardware, this is nearly unheard of. It is common to build a first prototype to show technical viability, then throw it out. For production, you start again from scratch to design a PCB that works with parts you can get at the x1000 scale.

    With Tessel 2, we say: you shouldn’t have to. This concept drove the following design decisions:

    • We chose components so that you can use the same ones in production. Every part used for Tessel 2 will continue to be manufactured and supported for a few years. Each can be sourced in low (100x) quantities.
    • Tessel 2 was designed in KiCad. This is perhaps the only free, open, fully-featured electrical engineering design tool available. Beyond publishing our design files, we want to make sure you can change and build on what we’ve created.
    • Tessel 2 is physically laid out so that you can easily remove features. A block diagram of Tessel’s hardware corresponds to its physical layout, so if you don’t need e.g. the ethernet port, you can remove it from the design (and save yourself the cost of the header) in your final product.

    Tessel 2 block diagram

    This takes open source hardware (OSHW) beyond just licensing. We want you to take our designs and use the parts of them you need in your own products. With your help, we can push the boundaries of OSHW. OSHW should be a platform for serious product development, not only a sharing marketplace for makers.

    Openness promotes innovation. Tessel is fully open source, hardware and software, so that developers can create and build on these efforts, as projects and as products, without worry of legal hassle. This project seeks to expand and promote openness as a movement in both software and hardware, and be a leader in community developed hardware.

    At the crossroads

    Now that we’ve shipped Tessel 2, there are several things we could do:

    1. Keep adding features in software, like support for more languages or features
    2. Build more modules to expand the platform
    3. Work on a “Tessel 3” that is an evolution of the board
    4. Work on a “Tessel X” that uses some of the same tooling but suits a different niche
    5. Something else, which approaches the mission in a different way

    This is where the Steering Committee comes in: we determine the project’s vision and create plans for future development. This is our first major vision decision since we moved to an open governance model.

    Here are the factors that drive this decision:

    • Mission and core principles

    • Logistical implications of our decisions

    • Needs of our community

    Critically, we need to pick projects that are well-scoped and highly focused. This lets us make measurable progress with the time and person-power we have available.

    All of these projects are arguably worthwhile. Which is best?

    Fulfilling the vision

    Coming back to the core, we want to build the OSHW movement through our platform. Tessel 2’s vision is well suited to this problem: the product lets people from varying backgrounds create products quickly and easily.

    We’ve come some of the way towards making Tessel 2 the base for a product you can take to market. But we’re not all the way there yet. Here are some of the issues we see:

    1. It’s not easy for most of the Tessel community to take the tools we’ve created so far and go to market. What do you do after you have a prototype– efficiency changes? Printing your own boards? Even if you knew what to do after building a prototype on Tessel 2, you might not know how to do it.

    2. Connected device products tend to exist in a networked configuration. This usually involves several low-cost, low-power devices. A standard for usability in this vein is the ability to run on a battery for months to years. This makes Tessel 2 not well suited to a lot of product applications.

    3. You can optimize to a point, but at the end of the day you are running JavaScript. This might not be as efficient or as reliable as you want your product to be. Additionally, you might have needs that are not supported in the language.

    A path forward: Rust, Reach, and Fractal

    We think we can work on these problems such that their solutions build upon each other. Here’s the idea:

    1. Work on improved Rust support. The Rust language executes code much faster and more robustly than JavaScript. It should serve well in production. The code is pretty legible, and it’s a welcoming community with good documentation. We’ve already begun tooling for this on the tessel-rust repo. Work on Rust doesn’t mean reduced support for or interest in JavaScript. We think they have the potential to play well together. Both will have first-class support.

    2. Build on this for our Tessel Reach project: cheap, low-power boards. Think of a Reach board as a wireless extension cable from a Tessel 2 to a module– this is how it should feel to use one. You can see a bit more detail on this issue.

    3. Use the JavaScript –> Rust compilation work to begin building the Fractal project. Fractal is software tooling to help you optimize your prototype into production. Explicit hardware requirements and memory-efficient software can let us begin to suggest hardware optimization. This would move toward comprehensible messaging. Examples might be: “Compile to Rust and reduce your file size of X to Y.” “You aren’t using Module Port B, remove it?” and “You’re only using Y memory- you may want to consider this cheaper chip (link)”.

    What do you think?

    This is the beginning of a plan. It’s an outline of a roadmap of a vision, and it’s going to be a lot of work.

    For me, it’s an inspiration. I want to work in the context of a grand plan. And it’s my hope that this grand plan excites and inspires you, too.

    When it comes down to it, that’s the crux. What do you think? Is this something you’re excited about building, and do these tools feel like they would be useful to you? Per our final core philosophy:

    Community matters. This project should be a welcoming, inclusive, and respectful place. It’s important to communicate, to question, and to come together.

    Please reach out on this issue, share your knowledge and use cases, and let us know what you think. We need to hear if you’re excited, if you’re unexcited, or if there’s something in particular you want to do. Because in the end, the Tessel Project is built out of the community, and we can’t do it without you.

    See you soon.

    Kelsey Breseman, on behalf of the Tessel Project Steering Committee

    #tessel project #vision #rust #reach #fractal #kelsey breseman #steering committee #open governance #open source #OSHW #mission #core philosophies

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