• This Week in Tessel — May 6, 2015

    Thursday, May 7, 2015

    Hello Tesselators, we’re happy to present to you our first installment of This Week in Tessel. Here we will highlight the latest news, projects, and events, from code, to community, to hardware manufacturing.

    Developing Tessel 2

    Moving towards Manufacturing There is now an approximate timeline for manufacturing and shipping Tessel 2:

    1. Week of 5/25 — Fifteen prototype boards are sent back from the manufacturer (bringing the total number of Tessel 2’s up to 22!) These will undergo final testing before starting production.

    2. Week of 6/8 — Finalize test rigs and procedures.

    3. Week of 6/15 — Begin final production in China.

    4. Late July / Early August — Expected shipments and general sale of Tessel 2.

    Developments from the engineering side:

    Projects

    New hardware module Community member @nmoadev created a Tessel module for Adafruit’s backlit keypad as part of an Embedded Systems final project.

    New projects:

    Community Updates

    JavaScript and Hardware Tomomi Imura chronicles the dive from pure code to hardware, including Tessel, LittleBits, Arduino, Johnny-Five, and Raspberry Pi in Hardware Hacking for JavaScript Peeps: How I Got My Hands on Breadboards and Resistors

    More blog posts:

    Tessel Worldwide This week, #SMARTuniverCITY in Barcelona learned about gathering data from sensors on Tessel. Students from Singapore experimented with Tessel at an SAP HANA Codejam.


    Come back next Wednesday for more! — The Tessel Team

    Anything you would like mentioned in the next issue? Tweet @technicalhumans to let us know!

    #tessel #this week in tessel #hardware #manufacturing #design #javascript #node #io.js #code #updates

  • Run, Push, and Erase: Developing on Tessel 2

    Wednesday, March 18, 2015

    3/18/15– Kelsey Breseman

    This post should give you a glimpse into developing on Tessel’s CLI.

    The basic interaction of a Tessel is to create some code, then send it to the device to execute.

    Current Tessel users should be familiar with tessel run to run the code one time in RAM, tessel push, which pushes the code over to Tessel’s Flash memory to be executed whenever the Tessel boots up, and tessel erase, which erases any pushed code.

    Tessel 2 runs on a totally different architecture than does Tessel 1, so we’re recreating the command line interface to act in the exact same way, but with a different implementation.

    Of course, this setup will get easier over time as developments continue.

    Setting up Tessel 2

    Tessel 2 is based on the OpenWRT architecture (& the same WiFi/processor chip), so for applications that don’t involve much hardware, I can use an OpenWRT Node or for a no hardware required dev setup, this Vagrant box to act as a Tessel 2.

    Here’s my setup:

    OpenWRT Node setup

    OpenWRT Node wired to USB serial, and powered (via a small USB hub) by microUSB. Both of those plug into another USB hub, which plugs into my computer.

    Before you can do anything, you’ll have to install the serial cable (we use this one), and then dterm (it’s on brew) to talk to it over the command line. For easy development, you can then set up an alias to set up serial comms with Tessel 2:

    alias v2="dterm /dev/tty.usbserial 115200"
    

    Assuming that’s all working properly, you can now run your aliased command v2 and hit enter to boot up. Congrats! You’re now root on your Tessel 2/OpenWRT. You should be able to save files and run them with scp -r path/to/code-folder root@ip:/path/to/dest (/tmp is good).

    Setting up CLI

    Great, now you can get Tessel 2’s CLI up and running. On your computer (not on Tessel 2), clone the V2 CLI repo and follow the instructions in the readme. Again, this is going to change and eventually be npm installable, but this works for now.

    Be sure to fill out the config.env file – a quick ifconfig on Tessel 2 should get you its IP address.

    All right! Now you should be able to run the CLI from your computer’s terminal. What fun! If you’ve gotten this far, you’re both qualified and welcome to begin contributing to the Tessel 2 CLI– check out the issues/features to make here!

    How Tessel 2 Calls Run

    The rest of this post is a walkthrough of how Tessel’s Run, Push, and Erase commands work, just to get you into the code.

    Jon actually wrote the run command, but I can walk you through it.

    The functions reside in the lib folder of the repo, and are called from bin/prime.js. So any new command will need a new file in lib and a new function call in prime.js.

    The run and push commands are both in lib/deploy.js, because they both deploy code. Note that this is an exception to the naming scheme; most functions should have their own file in lib and be called function.js.

    When someone types tessel run file.js in the command line, prime.js calls sftpDeploy and passes it the filename to deploy.

    Your computer then SSH’s into Tessel 2…

    function sftpDeploy(opts, push) {
     tessel.logs.info('Connecting to remote Tessel...');
      // Create a new SSH client connection object
      ssh.createConnection(function(err, conn) {
    

    …stops existing processes and deletes old code…

    conn.exec('/etc/init.d/tessel-app stop; rm -rf /tmp/remote_code’, function(err, stdin) {
    

    …makes a tarball of all the files relevant to your code…

    // Gather details about the file structure of the script being sent
    var ret = tessel.analyzeScript(process.cwd() + "/" + opts.entryPoint, {verbose: opts.verbose});
    // Tar up the code to improve transfer rates
    tessel.tarCode(ret.pushdir, {node: true}, function(err, bundle) {
    

    …and sends it over the WiFi, really just copying it into a temporary folder.

    conn.exec('mkdir /tmp/remote_code/; tar -x -C ' + filepath, function(err, rstdin) {
    

    Once finished, Tessel 2 runs your code by calling node app.

    The push command is only slightly different: if you specify to sftpDeploy that you are pushing code, it copies it into a different (non-temporary) folder (/app instead of /tmp/remote_code’), and also makes a file calledstart` within that folder, which Tessel 2 will execute whenever it boots up:

    conn.exec("echo '#!/bin/sh\ncd /app\nexec node .' > " + filepath + "/start && chmod +x '" + filepath + "/start'", function (err, newStream) {
    

    Tessel Erase

    If that sounded simple, it was. Tessel erase is even simpler: you call tessel erase from your command line and your computer SSH’s into Tessel 2 stops existing processes and calls rm -rf on the folder where pushed code is stored:

    function erase(opts) {
      var filepath = '/app';
    
      // Create a new SSH client connection object
      ssh.createConnection(function(err, conn) {
    
        conn.exec('/etc/init.d/tessel-app stop; rm -rf /app’, function(err, rstdin) { });
      });
    }
    

    Moving Forward

    This whole thing took only part of a day, including setting up the Tessel 2 and writing this blog post. Next, I’m tackling some of the Tessel 2 configuration to make setup simpler. We’re in a fun place right now, where you can pick a feature and build it out. Want to join?

    Tessel 2 CLI repo

    Kelsey

    #tessel 2 #tessel #tessel2 #technical #kelsey breseman #run #push #erase #tessel push #code #developer #development setup

  • Dominik Wind: Creating a Tangible Vision for a Sustainable, Open World

    Friday, March 13, 2015

    3/13/15– Kelsey Breseman

    I was introduced to Dominik Wind through a friend I made at MozFest, a several-floor consortium of chaotics working together to change the world through open source projects. When we think of open source, we tend to think of open source software, or some think of open source hardware in the embedded sense, but the movement is broader. Open source is about information flow– within companies, countries, and communities.

    Dominik is working on OpenState, which hopes to bring together several of these communities and create a tangible vision for an open and sustainable world. Right now, OpenState is putting together POC21, an ambitious five-week project that will take place leading up to the UN’s climate change conference, COP21 in Paris.

    Kelsey: What is OpenState?

    Dominik: OpenState is an organization that we founded in early 2012. Me and my friends, we were all working for NGOs, but we all had the feeling that it was not the most we could do. It was work that didn’t hurt, that paid the rent, but it didn’t feel satisfying anymore. We were looking for ways to create more impact within our lifetime.

    We really care about topics like resource depletion and climate change. We were working on that before, but we founded OpenState to fully focus on that. For us it’s all about developing sustainable ways of life, which includes production, manufacturing, and consumption habits.

    We think that social processes and group processes can be a very powerful tool for change. Most people only focus on technology, so we easily jump to technology as the one and only option for finding solutions. We wanted to focus more on the behavioral side of things– which still includes technology, but it’s also more than that.

    OpenState is a laboratory for exploring these processes: what do we need for a sustainable society besides the technology?

    Kelsey: What is an example of making changes through processes?

    Dominik: Everything that touches you emotionally opens you up to changing your opinions. What we do is bring together people who have diverse skillsets and also cultural backgrounds and try to create a world in our work. It’s an experimental space where you prototype whatever is the topic. So if it’s the future of work, for example, you simply behave like you would be in that different world.

    You behave like the future is already there: if I could make everything perfect, what would that perfect environment be?

    The same thing, we are trying now with OpenState in Paris regarding sustainability. What would a family, or a neighborhood, or a friendship group, how could we live more sustainably without giving up the standards of life that we have today?

    The interesting thing is that when you get people together in such an intense experience, they reinvent themselves. Nobody knows each other, so everybody tries to live up to his or her best version. You can restart in a way, and pretend to be whatever you want to be. And then the time is long enough to get into habits. You exercise of practice something as a habit for some weeks, and that really has an impact on you, that really changes your behavior.

    We often hear from participants in former camps that they changed their lives. It’s really a pretty powerful situation.

    Kelsey: So what’s the plan for for POC21?

    Dominik: This camp will be five weeks of living and working together in the beautiful Château de Millemont near Paris. It’s called POC (proof of concept) 21 because it will be around the climate negotiations of the UN in Paris in December, COP 21.

    Kelsey: What do you expect in terms of tangible results from POC21?

    Dominik: We are aiming to find solutions or technological approaches to satisfying basic needs: how to produce energy, food, water, communications, shelter, and mobility. Within those five areas, we will invite open source projects that are already working on that; we won’t start at zero.

    By the end, we hope to include all these parts into one holistic prototype of that potential sustainable future, so you really can have a festival in the end where people can come see what this “future living” could look like.

    You can step into that Wikihouse, for example, with that open energy monitoring system installed, where you understand, here I can see my energy consumption, here I can control my impact. Make it tangible for people.

    And then, they get the story of, it’s produced in a different way, it could be locally produced, it’s repairable, everything’s open source, the average craftsman wherever you live could open these things and get it fixed without you having to re-buy the next thing. Then the whole story comes in on why certain products might be more sustainable than others.

    But first it needs to be this experience: touch things and understand it’s real.

    Kelsey: What do you see as the primary tangible outcome?

    Dominik: Currently there are hundreds of potential solutions and different groups around the globe that are at different stages of their product development.

    We aim to offer an online platform and an on- and offline catalog where we showcase the solutions that are ready for broader audiences beyond the maker and hacker niches. We showcase the ones that are for average people– like if my parents want to buy a new washing machine, they should easily get access to the best open source washing machine.

    Most platforms online for this show all potential options, and normal people quickly lose orientation. They are simply overwhelmed with hundreds of projects, and all of the details.

    We also hope to kind of showcase things in a shop format. We will start in Berlin, and have an “open everything” shop. What you can get there works, but it’s fundamentally different. It’s still a lamp, or a desk, or whatever, but it’s produced differently, and it can be repaired, or you could rebuild it yourself if you have the skills.

    All of this, and then it will also be about the media outreach in the uprun to the COP21 conference, showing that it’s not all too late.

    We expect that the UN talks in Paris will be like always: you will have the politicians negotiating; outside, you have normal people, saying it needs to go faster, or differently, or whatever, in between police, you will have some demonstrations, maybe you will have some riots. At the end they will have the press conference, saying yeah, they have some very minimal improvement on something, and then everybody goes back to normal.

    We would like to have a new narration on that: there are people who have already started on creating a more sustainable way of doing things, it’s going around the globe, and it’s a movement you can join. Or at least you can start using different products that are designed and produced on a very different basis.

    OpenState

    Kelsey: What are some of the biggest blockers for people who want to use products from this movement?

    Dominik: Communication and IT stuff is probably the hardest, I think. The open source scene is really small, and the open source hardware scene is even smaller, and before that you have digital literacy, basically. Like my mom, if something doesn’t work automatically with her computer, she has no idea what it could be. It’s just not working.

    For all the other things, average people can rely on crafts and craftsmen. Open Desk, for example, offers an online platform where you can upload designs for chairs and desks and tables. People can buy designs and they get shipped, or you can download the designs for free, and produce it yourself. The entrance barrier is lower for most people, to pick up their drill and saw, it’s simply easier for most people than microcontrollers.

    Kelsey: What sort of labs and materials will you have at POC21?

    Dominik: We have partnered with all kinds of hacker and maker spaces in Paris, and with fablabs.io, the global network for FabLabs. We’ll have some machinery right onsite, at the castle, and we will also get maker spaces in Paris involved to produce certain things.

    I think the only thing that we are creating from scratch is the media outreach. We have to find the right stories, and the right timing regarding COP21.

    Everything regarding prototyping and tech development and coding and stuff like that, will be a blend of groups, tools, and spaces that are already there and are up and running.

    Kelsey: At POC21, you’re hoping to have a mix of people from a variety of different backgrounds, right?

    Dominik: Yes: engineers and coders, but also people from many other backgrounds. When we develop tech today, the mindset is strictly focused on coders, engineers, and maybe you have some business people involved. But I think our tools are forming our reality. The things we use create certain habits, and these habits become a part of us.

    Development of technology changes our behaviors and our perception of the world. This development of technology has had a huge cultural impact on everyone. It’s not just a market thing, as we mostly treat it at the moment. There are also spiritual questions, and social questions, and questions of how we actually want to live as a society. These all should be integrated into good product design. It’s really a powerful tool for cultural change.

    Ed. note: you can see a video about the vision of POC21 here

    #openstate #open source #oss #oshw #dominik wind #opencamp #POC21 #COP21 #sustainability

  • Tessel 2 Hardware Overview

    Tuesday, March 10, 2015

    3/10/15– Eric Kolker

    Hey Tesselators, Eric here. Since we announced Tessel 2 last week, we have gotten a lot of questions about the new hardware.

    Tessel 2 boards

    Shiny new boards back from the manufacturer!

    Tessel 2 at a glance

    We packed a whole lot of hardware in there:

    • A 580MHz WiFi router system on chip (Mediatek MT7620n) running linux (OpenWRT)
    • 64 MB of DDR2 RAM
    • 32 MB of flash storage
    • 2 High-speed USB 2.0 ports
    • a micro USB port
    • A 10/100 Ethernet port (RJ-45 jack)
    • A 48MHz ARM Cortex M0 microcontroller (Atmel SAMD21)
    • Two module ports that are much more capable than their predecessors
    • a button and a bunch of LEDs, because what’s a Tessel without blinky?

    The board’s bill of materials and physical characteristics are only part of the picture. We spent a long time thinking about how we wanted to architect Tessel to push it beyond “another dev board” and clear into “this platform is exactly what I needed!” territory.

    A few features under the hood (in addition to the ones current Tessel users know and love, including the expansive plug-and-play module ecosystem and high-level language support for low-level hardware features) include:

    • Router-grade 802.11b/g/n WiFi, including access point mode (Tessel can be a router)
    • 16 GPIO broken out as a pair of multi-purpose module ports
    • Individual control over and protection for all outward-facing power buses (USB and module ports)
    • A form factor designed for abstraction and flexibility in the hardware, software, and mechanical worlds as you scale from prototype to production

    Abstraction boundaries

    One of the things which makes software so powerful is a heavy emphasis on frameworks and abstraction. Although there is no shortage of “standards” (official or otherwise) in the hardware space, one thing nobody has done particularly well yet is cleanly and clearly share abstraction boundaries between the hardware and software layers. We’re looking to change that.

    The high-level system diagram for Tessel 2...and most other single-board computers, too.

    The high-level system diagram for Tessel 2…and most other single-board computers, too.

    The diagram above is a high-level system diagram for Tessel 2. Let’s dive into where we drew the lines internally.

    The board employs a processor/coprocessor architecture. The Mediatek runs your user code, hosts USB devices, handles the network connections (be they wired, wireless, or cellular over USB), and communicates with the SAMD21.

    The SAM acts as a coprocessor and handles real-time, low-level IO through the module ports, USB comms through the Micro USB port, and programming the device as a whole.

    The two chips are connected by a SPI bridge that also includes the onboard flash (the readme for Tessel 2’s firmware repo goes into more detail here).

    The whole system is powered from the single Micro USB (device) port, and its specific functional blocks look more like this: Functional blocks of Tessel 2

    Functional blocks of Tessel 2

    This arrangement, which also very closely mirrors where the related parts are located on the hardware itself, allows us to draw the boundaries at the both the mechanical and conceptual level as follows:

    Functional groups in Tessel 2’s architecture

    Functional groups in Tessel 2’s architecture

    Or, on the board itself: Functional groups on Tessel 2’s prototype hardware

    Functional groups on Tessel 2’s prototype hardware

    Consciously drawing these same boundaries when creating both the software and the hardware lets us make developing on the Tessel platform simple and consistent throughout an entire product cycle, which is a huge win. I’ll talk more about this in another post, but suffice it to say that most of the optimization and integration story relies on the fact that we kept these boundaries at the top of the list when making design decisions about how to build Tessel 2.

    New and improved module ports

    The two module ports on the new Tessel look and behave the same as the ones on the original board, but they’re actually a lot more versatile. In fact, don’t lock yourself into thinking that they’re “just module ports”; think of them as mini GPIO banks. Each pin on the two 10-pin headers is unique and can be reconfigured to do almost anything from speaking alternate comms protocols to clock generation. For example, if you decide you don’t want SPI, feel free to give yourself another I2C or UART with minimal changes to the SAMD21’s firmware. Touching only JS, you can forgo the fancy comms in favor of just plain GPIO, which gives you access to as many as 16 of them.

    Plus, a nifty new power architecture gives you individual control over the 3.3V rails on each port, so you can turn modules off when they’re not in use to save power. This essentially converts the 3.3V rails on the ports into two high-current (at least 250 mA) output pins that just so happen to power modules most of the time. …Or, put another way, this is our pass at solving hot-plugging for low-level hardware.

    Last but not least, all eight pins on Port B are also inputs to a 12-bit, 350ksps ADC, with adjustable gain that can operate in differential mode, if that floats your boat. Not too shabby.

    Close

    We’re pretty excited about the new hardware and what in enables, and hope you are too. It’s been in the works for a few months now, and at this point it’s time for us to start cranking out docs and answering questions, so don’t hesitate to reach out on the forums or over email.

    On the subject of docs, here is what we’ve released so far, including a preliminary schematic (full KiCAD project files are on their way soon). For now, head to our website to see more.

    Until next time,
    ~e


    This post has been translated:

    #Tessel #Tessel 2 #eric kolker #technical machine #hardware #features #electrical engineering

  • 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

August 2018

January 2018

July 2017

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