• What Comes Next: Fractal

    Monday, October 27, 2014

    10/27/2014– Kevin Mehall

    Jon’s last post hinted at what we’re working on next, a project we’re calling Fractal. I wanted to explain in a little more detail what we’re planning for the Fractal software stack.

    Our users love Tessel for the ease of getting started. This is especially apparent at hackathons and other meetups we’ve held for people to try Tessel. A first-time user can go from zero to something quite impressive in only a few hours. Many customers have been asking about their next steps once they build a prototype – Tessel can’t just be a device for winning hackathons. A good platform needs to scale as your project turns into a product and help you win in the marketplace too.

    Fractal is a system design tool for microcontroller firmware and hardware. For Tessel prototypes, Fractal will improve IO performance and provide better debug tools. Once your prototype works, and you want smaller, cheaper, and lower-power boards in quantity, Fractal will help you optimize your system design. It’ll help you choose the right parts and put together reference schematics and circuit board layouts as a starting point for your own hardware.

    Beyond JavaScript

    We’ve already had to include some dedicated C code in our firmware for specific applications with timing requirements that JavaScript can’t meet. The Audio module requires code in the firmware to feed the audio chip data exactly when it needs it, without waiting for the JS event loop. We’ve recently added code for driving Neopixel LEDs with the (really powerful, but nontrivial-to-configure) timer hardware built into the NXP micrcocontroller on Tessel. While this works for the handful of applications so far, it doesn’t scale; these things should be libraries, not built into the main Tessel firmware. With Fractal, we’re working on a way to ship compiled code modules that integrate tightly into the firmware, while remaining easy to use.

    Fractal adds Components, bundles of code for a discrete piece of your firmware, like an I2C controller, accelerometer driver, or JS VM containing your domain logic. Components have statically-defined, asynchronous, language-agnostic interfaces, and the Fractal compiler will be able to automatically generate cross-language bindings, so you don’t have to write them manually. This makes it easier to use the right language for each piece and phase of your project, be it prototyping or realtime control.

    The right language isn’t always JS or C. I’m enjoying Rust, and think it makes an ideal language for programming microcontrollers. Rust is a new language from Mozilla that combines high-level expressiveness and safety with low-level performance, size, and closeness to hardware. It’s a new entry into the systems programming space that has been dominated by C for decades.

    I’m also working on Signalspec, a domain-specific language for modeling IO protocols using regex-like definitions. Signalspec is a dedicated description language to abstractly define and then implement the state machines used to communicate with sensors and other chips. It saves you from writing asynchronous state machines by hand, a messy, error-prone process in existing imperative languages.

    Because of the cross-language Component interfaces that abstract the underlying hardware, porting between languages and between hardware platforms isn’t a full-system rewrite. Start by prototyping your domain logic in JS on Tessel, then port it to Rust and fit it on a $2 Cortex M0 part. Fractal will make such a port not only feasible, but easy and elegant.

    Tessel brings a few aspects of Node / JS to embedded development that will become a broader part of Fractal and improve the platform for all languages:

    Packages

    Components involve a change in how code gets deployed to your Tessel. Right now, you normally download the firmware from us pre-compiled, and then tessel run or tessel push deploys a bundle of your JavaScript, which the firmware runs from a virtual filesystem. Under Fractal, your project specifies which Components get compiled in, and it will build a custom firmware image containing everything from the low-level drivers to the Colony JS runtime and your JS code, with each deploy. This means many errors are detected at compile time instead of runtime.

    The ease of installing Tessel module drivers is important piece of the Tessel user experience, and will guide the design of the Component distribution story. npm will obviously remain the way to install pure-JS packages from the Node ecosystem within a JS component.

    Events

    There’s one convention in JS that is actually more like how hardware works than most other languages: events. Hardware interrupts wake up the CPU and run an interrupt handler function on hardware events like button presses, SPI completions, and UART received bytes. Sounds kind of like a JS async callback, right?

    An OS kernel can be thought of as an interrupts-to-threads adapter. To achieve asynchronous events within this threaded model, Node uses libuv, which can be thought of as a threads-to-events adaptor. On Tessel, rather than going from interrupts to threads and back again, hardware interrupts enqueue events directly onto the JS event queue.

    Fractal components add more structure to this asynchronous call / callback model, and use it throughout every layer of the system. Explicitly defining the beginning and end of IO actions as events saves power by spending more time in sleep mode, and saves RAM by avoiding the use of multiple stacks for threads.


    We’re just getting started developing Fractal. For more details, check out our preliminary documentation and let us know what you think. Sound like something you want to work on? We’ll be developing Fractal in the open on GitHub, and we’re hiring.

    #kevin mehall #fractal #Tessel #technical machine

  • Talk slides: "APIs to Electrons"

    Friday, October 17, 2014

    10/17/2014– Eric Kolker

    Hey Tesselators, Eric here.

    FIT

    Conference season has (unofficially) begun!

    Jon and I just got back from speaking at an event in Guatemala called Foro de Innovación Tecnológica (Forum on Technological Innovation), or “FIT” for short. We ran a four-hour hack event for the attendees, each gave a talk, and generally had a blast, which is pretty much par for the course.

    From API to Electrons

    My talk was called “From API to Electrons” and walks through what happens when you set a sound trigger on the Ambient module. As you might expect, it looks at what happens at every level of the system, from JS all the way down to simulating the analog electronics on the Ambient module…and back.

    I had a lot of fun writing the talk and hope to give it again (in English this time) in the not too distant future. If you’re in the San Francisco Bay Area, give our meetup a look and keep your eyes peeled. If not, or if you just can’t wait, I put the slides online here and all the resources for the presentation (code, LT SPICE simulation, SVGs, etc.) here.

    #eric kolker #apis to electrons #guatemala #talks #tech talk #conferences

  • Tessel + Keen.io

    Thursday, October 16, 2014

    10/16/2014 – Jia Huang

    Keen.io is a cloud analytics platform that’s extremely easy to use. It gives an endpoint to hit and logs all data sent to that endpoint as part of an event stream.

    We’re excited to finally get it working with Tessel. In the early Tessel firmware/runtime releases we had bugs on our runtime (specifically about zlib decoding/encoding) that prevented their library from working properly.

    Those bugs have since been fixed and working with Keen has been a breeze!

    In order to use Tessel with Keen first create an account.

    Then go on to the projects page and find the project ID & API keys

    Keen has an NPM library that takes in these keys. In order to configure Keen:

    var Keen = require('keen.io');
    var keen = Keen.configure({
        projectId: "####", // swap these out with your own keys
        writeKey: "####",
        readKey: "####"
    });
    

    As a test script I’ve sent over some data from the Accelerometer up to Keen. This script sets up the Accelerometer on port A of Tessel and sends data up to Keen every second:

    var Keen = require('keen.io');
    var tessel = require('tessel');
    // attach the accelerometer to port A
    var accel = require('accel-mma84').use(tessel.port['A']);
    var count = 0;
    
    console.log("setting up keen...");
    var keen = Keen.configure({
        projectId: "####", // swap these out with your own keys
        writeKey: "####",
        readKey: "####"
    });
    
    var dataArray = [];
    accel.on('ready', function () {
      console.log("Accelerometer is ready!");
      // as we get data push it into an array
      accel.on('data', function (xyz) {
        dataArray.push(xyz);
      });
    });
    
    // every second send up all the accelerometer data
    setTimeout(function sendData(){
      keen.addEvent("accel", {data: dataArray}, function(err){
        if (err) throw err;
    
        console.log("Added event #"+count, "data: ", dataArray);
        count++;
        dataArray = [];
        setTimeout(sendData, 1000);
      });
    }, 1000);
    
    

    Before running this make sure Tessel is connected to the internet:

    tessel wifi -n <your_network_ssid> -p <your_network_pw> -s <wpa2|wep>

    The security (-s) flag defaults to wpa2.

    If the network is unsecure, the password and security flags can be omitted:

    tessel wifi -n <your_network_ssid>

    Tessel should go through the wifi connection process and the yellow LED should be lit after it successfully connects to the internet.

    After connecting Tessel to wifi, just do a tessel run index.js to run the test script

    And we can see the data as it gets pushed to Keen along with a timestamp.

    The full code is here: https://github.com/jiahuang/tessel-keen

    Let us know what you do with Tessel + Keen!

    See Keen’s blog on our integration here

    #jia huang #tessel #keen #keenio #technical machine #integration #cloud #analytics

  • Onboarding with the SAMR21 MCU on OSX & Ubuntu

    Wednesday, October 15, 2014

    10/15/2014 – Jia Huang

    I started playing with an Atmel SAMR21 dev kit this weekend.

    Atmel recently released the SAMR21 series. It combines everything good about the SAMD21 series (USB controller, low power cortex M0+ architecture) and the AT86RF233 (802.15.4 wireless radio). 802.15.4 is the standard for low power IoT devices using Zigbee and 6loWPAN (IPV6 for IoT, primarily used for mesh networks).

    So instead of having to use two chips (one for the logic and one for the wireless communications), both silicon wafers are put on one package:

    Besides the main SAMR21 chip, the dev board has on it:

    • Another chip that acts as the embedded debug chip. This allows us to load code and use gdb to debug hardware without having to buy an expensive JTAG debugger. Instead we can just plug the board into a USB port and start hacking.
    • Two antennas. One is a chip antenna, and the other is an external antenna. During development we can switch between the two for different applications.
    • The usual assortment of LEDs & buttons that comes with every dev board.

    If you just want to get the code running, here’s the final github repo with build & deploy instructions on OSX & Ubuntu: https://github.com/jiahuang/samr21-xplained-pro.

    Getting the example code

    As usual, the default example code that the chip manufacturer gives is a bit convoluted. As of Oct 2014, the only example on the SAMR21 Xplained Pro page is this project for doing FCC tests, though Atmel has a few more examples from the actual ATSAMR21G18A page.

    The FCC test example goes through some radio emissions so that the Federal Communications Commission (FCC) can certify that the radio isn’t emitting in frequencies it’s not supposed to. The FCC test example that Atmel gives isn’t a good choice for a starting program since I can’t easily tell if it’s working or not.

    But I went ahead and used the FCC test program anyway because I thought that it might have some pin-specific configs for the Xplained board. Those pin configs would help me identify and get started with the LEDs & buttons, at the very least.

    Making it do something I can see

    My first goal was to get something working on the board. That way I could verify that I had a working programming & debugging environment for more complicated examples. Often I find that simple things like Makefiles aren’t configured properly in example code.

    Blinky lights are the “Hello world” of hardware, so I modified the example FCC tester code to blink the LED on and off instead.

    In order to blink the LED, I had to find the program’s entry point. I had hoped for a main.c file, but the folder structure for Atmel’s test program is:

    fcc_test_r21/
      LwMesh_1_2_1/ 
        apps/
           Peer2Peer/ # main application
             astudio/ # AVR studio files
             linker/ #linker files used during compilation
             make/ #makefiles for the different boards
             config.h
             fcc_test_dut.c 
         doc/ #pdf files for explaining Atmel’s Light Weight Mesh protocol
         hal/ #the Hardware Abstraction layer. Useful because this application is for multiple boards
         phy/ #the physical layer. This is code specific to the radio.
         service/ # unused
         sys/ #system files, stuff like timers, clock config, and timers.
         tools/ # Also unused. 
    

    I ended up grepping for a main(void) function, found that it’s in the counterintuitively named fcc_test_dut.c file, and put in some blinky code:

    
    void delay_s(uint32_t time) {
        for (int i = 0; i  100*time; i++) {
            // this delay is in us 
            HAL_TimerDelay(10000);
        }
     }
    
     int main(void)
     {
      SYS_Init();
      HAL_UartInit(38400);
      HAL_LedInit();
      while (1)
      {
        HAL_LedOn(0);
        delay_s(1);
        HAL_LedOff(0);
        delay_s(1);
      }
    }
    

    Building the program

    Atmel has nicely included all the makefiles for their various boards so that I can build using GCC.

    >> ls LwMesh_1_2_1/apps/Peer2Peer/make
    Debug
    Makefile_Rcb128rfa1_ATmega128rfa1
    Makefile_Rcb231_ATmega1281_Rf231
    Makefile_Rcb256rfr2_ATmega256rfr2
    Makefile_XplainedPro_ATSAMD20_Rf233
    Makefile_XplainedPro_ATSAMR21
    Makefile_XplainedPro_ATmega256rfr2
    Makefile_Xplained_ATxmega128b1_Rf212
    Makefile_Xplained_ATxmega128b1_Rf231
    Makefile_ZigBit_ATmega1281_Rf230
    

    The makefile requires the gcc-arm compiler.

    This is the same compiler we use for Tessel, and during Tessel’s development we made a brew tap to install it on our machines. We can use the same brew tap to install the tools needed for compiling the SAMR21 code.

    brew tap tessel/tools
    brew install gcc-arm
    

    On Ubuntu, get gcc-arm from Terry Guo’s PPA:

    sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded;
    sudo apt-get update;
    sudo apt-get install gcc-arm-none-eabi;
    

    With these tools, I could now build the makefile: make -f Makefile_XplainedPro_ATSAMR21

    Remember the counterintuitively named fcc_test_dut.c file? Turns out at one point the program files were properly named the application name (as Peer2Peer.c) before being changed to fcc_test_dut.c because the makefile still looks for it:.

    > make -f Makefile_XplainedPro_ATSAMR21
    ...
    arm-none-eabi-gcc: error: ../Peer2Peer.c: No such file or directory
    arm-none-eabi-gcc: fatal error: no input files
    

    The makefile also uses a gmkdir command that should just be a mkdir.

    I ended up modifying the makefile to fix these and the build succeded.

    > make -f Makefile_XplainedPro_ATSAMR21
    size:
       text    data     bss     dec     hex filename
       4776       0    1888    6664    1a08 Debug/Peer2Peer.elf
       4776       0    1888    6664    1a08 (TOTALS)
    

    Configuring OpenOCD

    OpenOCD is an open source chip debugger. It allows me to do “on-chip” debugging, stuff like looking at registers, setting breakpoints, loading code, etc.

    As of the current release (v0.8.0) OpenOCD does not have configurations for the SAMR21 chip, but it’s already in their master branch. In order to get it, rebuild from master. When it releases, v0.9.0 should have these configs by default.

    On OSX:

    brew install openocd --HEAD
    

    On Ubuntu:

    git clone https://github.com/ntfreak/openocd.git;
    cd openocd;
    ./bootstrap;
    ./configure;
    make;
    sudo make install;
    

    Now running openocd --version should show something like:

    > openocd --version
    Open On-Chip Debugger 0.9.0-dev-snapshot (2014-10-05-17:42)
    

    OpenOCD uses .cfg files to set up configs for the type of board that it’s programming/debugging. The config file specifies things like how the chip is programmed, the interface used to do the programming, and the specifications of the MCU.

    In the make folder I added a tools/samR21.cfg file to tell OpenOCD what to do:

    #samR21.cfg
    source [find interface/cmsis-dap.cfg]
    
    # chip name
    set CHIPNAME at91samr21g18
    
    source [find target/at91samdXX.cfg]
    
    $CHIPNAME.cpu configure -event gdb-attach {
       echo "halting"
       halt
    }
    

    This tells OpenOCD to use cmsis-dap as its programming interface, and that the chip being programmed is a samr21. Once gdb attaches, I halt the microcontroller to prevent any code from being run. Having a halt as a first step is useful for debugging later if I want to set up breakpoints at the start.

    Loading up the program

    By then I had:

    • the built binary (Peer2Peer.elf)
    • the OpenOCD config file (samR21.cfg)

    Now I could run GDB on the dev kit with OpenOCD:

    arm-none-eabi-gdb Debug/Peer2Peer.elf -ex 'target remote | openocd -c "gdb_port pipe;" -f tools/samR21.cfg'

    Once GDB attached, I ran the load command to load up the elf into flash.

    The load command loads up the .elf file I specified earlier in the arm-none-eabi-gdb command.

    After this is loaded, the board is put in a halted state again so I could attach breakpoints if I wanted. In order to run the code, I had to issue the “continue” command (c for short).

    And it blinks!

    The modified example code is up on github.

    Next up, putting two of these things together and getting them talking over 6loWPAN!

    #jia huang #tessel #samr21 #zigbee #iot #6lowpan #microcontroller

  • A Peek at Technical Machine's Plans

    Tuesday, October 14, 2014

    10/14/2014– Updates

    We’ve been talking to a lot of customers recently and brainstorming what our next most important projects are. As of today, much of this is now in R&D, and we want to keep you apprised.

    Taking prototypes into production is very difficult, almost occult. We’re reinventing this process with a new project called Fractal. Our vision is a tool to create software-defined hardware– helping automate the prototyping process, reducing work duplication, and allowing for transparency through the whole design process. You can read more about our progress so far here. We’ll be publishing more on this soon, and reach out to us if you want to learn more.

    Variations on next-generation Tessel research and development are in the works. Currently, we’re investigating a few smaller development targets: 6LoWpan, Wifi, BLE, and 3G connectivity. Expect to see more detailed product announcements within the next several months.

    Also in the pipeline are new Tessel modules! Here are some we’ve been working on, based on user suggestions:

    • A proto-module: a solderable module to make it easy to add your own capabilities to Tessel. This will be accompanied by some documentation about how to make your own module.
    • A soil moisture sensing module.
    • A biosensing module.

    What would you like to see next? Suggest modules here!

    Beyond research and development, here’s how we’ve been spending our time:

    • Events, workshops, and hackathons
    • Re-released the GPS module into the store
    • Talking with potential international distributors
    • Runtime improvements
    • Hiring (interested?)
    • Compiler improvements
    • Soliciting user feedback
    • Working on our pitch deck
    • Support, as always
    • Wifi improvements
    • Got a 6LoWPAN chip running (R&D)
    • Got closer to merging in LuaJIT

    We have a blog post up with various conferences and events that have a connection to Tessel– if you’re doing a Tessel-related talk or event, contact kelsey@technical.io and she’ll add you!

    All the best,
    Jon, Tim, Kelsey, Jia, Kevin, Ken, and Eric

    #update #updates #research #r&d #fractal #tessel #modules #suggestions #6lowpan #wifi #ble #bluetooth #biosensing #proto-module #diy #soil moisture

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