Programming Arduino in Visual Studio Code

I have really been enjoying using Visual Studio Code lately.  I just finished using it for a Golang backend and in place of the Intel XDK editor for a Cordova frontend (the XDK is great for building and launching Cordova apps, but I'm not a big fan of its editor).

I wouldn't say that I'm going to use it for everything (emacs is still my top choice for C++, shell scripting, LaTeX, and quick-and-dirty org-mode tables), but Visual Studio Code is pretty darn nice.  Here are a few quick reasons why I like it:

• No wasted screen real estate.  No buttons for things that are in a menu.  No toolbars that you can screw up and never find again, like in Eclipse.  It's lean and lightweight.
• Awesome extensions.  Really.  I installed the Go extension by lukehoban, and it felt like I was working in the preferred IDE for Go.  I installed ESLint, TSLint, and CSSLint, and they just worked perfectly.
• Git integration.  I have never liked the git integration in any IDE I've ever used.  Visual Studio Code seems to understand the 80/20 rule... for easy git operations, it works great.  For hard things, it knows that I'm just going to use the command line.  I've actually used it as often as not in recent projects.  It just works.
• Sane keyboard shortcuts.  I don't use a mouse if I can avoid it.  I think it goes back to when I started using Windows 3.0 instead of DOS, and constantly found my mouse performing poorly, and needing me to disassemble the bottom and clean lint off of the ball and rollers.  I learned the Windows keyboard shortcuts.  And Microsoft rarely changed them (the office ribbon being a notable exception).  When I work in emacs, the muscle memory in my fingers knows exactly how to navigate.  The same is true for well-designed windows apps.  When a program breaks the rules (like IntelliJ not respecting that Shift-F10 is supposed to open a context menu), I get so annoyed that I'll rant in the middle of a blog post!
• Easy configuration.  Configuration files are JSON, and they have autocomplete features to help me do what I need to do.  It's not as powerful as emacs, but I haven't changed my .emacs file in years, because it seems like every time I want to change anything, I have to re-learn elisp and spend an hour digging around on the web.

So now that I've established myself as being on the Visual Studio Code bandwagon, let me show one reason why it's so great.  You can make extensions for just about any language or environment, and people do.  In my opinion, the Arduino IDE is just about the worst development tool ever (it rivals writing code in Notepad).  But in just a few easy steps, you can switch to Visual Studio Code, and never look back.

First, you'll want to install the Arduino extension (currently version 0.0.4) by moozzyk.  This gives syntax highlighting, and other simple stuff that you'd expect.

Second, you will need to set up a tasks.json file.  This will let you compile sketches, and deploy sketches to a plugged-in Arduino.  Below is my tasks.json.  It's specific to Windows (though easy to extend to OSX and Linux), and generic enough that you can put it in a .vscode folder in your main Arduino sketchbook folder, and then it will let you build and install any sketch in any subfolder:

// tasks.json for building and running Arduino sketches from
// Visual Studio Code
//
// Note: this configuration uses whatever serial port was most recently used
// by the Arduino IDE
{
    "version": "0.1.0",
    "windows": {
 "command": "c:\\galileo\\arduino_debug.exe"
    },
    "isShellCommand": true,
    "showOutput": "always",
    "suppressTaskName": true,
    "tasks": [
 {
     "taskName": "Compile",
     "args": [
  "--verify",
  "-v",
  "${file}"
     ],
     "isBuildCommand": true,
     "showOutput": "always",
     "problemMatcher": {
  "owner": "external",
  "fileLocation": [
      "relative",
      "${fileDirname}"
  ],
  "pattern": {
      "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
      "file": 1,
      "line": 2,
      "column": 3,
      "severity": 4,
      "message": 5
  }
     }
 },
 {
     "taskName": "Run",
     "args": [
  "--upload",
  "-v",
  "${file}"
     ],
     "isTestCommand": true,
     "showOutput": "always"
 }
    ]
}

With this file in place, you can use ctrl-shift-b to run the Compile task.  You can reach the Run task by using ctrl-shift-p and then typing "task test", which will choose "Tasks: Run Test Task".

So then, at this point, you only need the Arduino IDE for two things: changing the board type/serial port, and running a serial debugger.  Short of hard-coding information in your tasks.json file whenever the board info changes, I don't know of an easy workaround for the first problem.  But for the second, it turns out that PuTTY is a fine alternative to the Arduino serial monitor.  I've been using it for a decade, and never noticed that with one click, you can switch from ssh to serial connections:

That's it!  Just click on the "Serial" radio, enter your COM port, and you have everything you need.

For the sake of completeness, here's the sketch I used.  Intel graciously donated some Galileo V2 boards and Grove IoT kits, and my son used them to display temperature readings on an LCD:

// Sketch for Galileo Gen 2 with Grove kit, for displaying temperature in
// Farenheit on LCD
//
// Temperature Sensor is connected to A0
// LCD Screen is connected to I2C #2

#include <Wire.h>
#include "rgb_lcd.h"

rgb_lcd lcd;

// background color for the LCD
const int colorR = 0;
const int colorG = 255;
const int colorB = 0;

// Pin for the temperature sensor
const int pinTemp = A0;

// Define the B-value of the thermistor in the Grove kit, so we can convert
// to Celsius
const int B = 3975;

void setup() {
    // set up the LCD's number of columns and rows, then its color
    lcd.begin(16, 2);
    lcd.setRGB(colorR, colorG, colorB);
}

void loop() {
    // Position cursor at 0,0
    lcd.setCursor(0, 0);

    // Read raw value of temperature sensor
    int val = analogRead(pinTemp);

    // Convert to Farenheit
    float resistance = (float)(1023-val)*10000/val;
    float temperature = 1/(log(resistance/10000)/B+1/298.15)-273.15;
    temperature = temperature * 9.0 / 5.0 + 32;

    // Print temperature to LCD
    lcd.print(temperature);

    // Repeat every second
    delay(1000);

}

Have you tried Visual Studio Code yet?  Should I post more of my experiences?  Leave a comment to share your thoughts.

Launching a Go App on Heroku

Lehigh is part of the KEEN network, an organization that promotes more entrepreneurial-minded learning in engineering curriculum.  This summer, as a KEEN project, Corey Caplan and I are designing some fun new courseware for our Software Engineering course.

Our intention is to do everything in Java within the course.  But when I need to figure out something about web backends in a hurry, I'd rather use Go.  Today was one of those times.

Without going into too much detail, I have a web app that I wanted to stop running via localhost, and start running on Heroku.  (If you're thinking this means that our Software Engineering students are going to start learning how to deploy their apps on Heroku's PaaS, you're right!).  Below is something of a recipe for how I got it to work.

Confession: this turned out to be a lot harder than I expected, and it was probably my fault.

Caveat: the recipe below is possibly a good bit more complex than it needs to be... but it works, and seems to be repeatable.

Background: I had an app that looked like this:

• /src/admin/*.go -- a simple admin program
• /src/appserver/*.go -- the code for the server
• /web/... -- the entire web frontend, designed as a single-page webapp
• /env -- a script to set the environment variable when running the app locally
• /setgopath.sh -- a script to set the GOPATH to the root of this project

There were a few more things in the folder, like a .gitignore, but they aren't important to this discussion.

Note, too, that I like to have a different GOPATH for each GO project, instead of checking them all into the same place.  I organize my work in folders: teaching, research, etc.  Using Visual Studio Code, I can just open a bash prompt, source my setgopath.sh script, type "code &", and I've got an IDE, a shell, and everything else I need.

Dependencies: Here's the first reason why this app was interesting: it uses Google's OAuth provider for authentication, and it connects to a MongoDB instance.  There are four dependencies that I usually had to 'go get':

• go get golang.org/x/oauth2
• go get golang.org/x/oauth2/google
• go get gopkg.in/mgo.v2
• go get gopkg.in/mgo.v2/bson

And my code is in a bitbucket repository.  Let's say it's bitbucket.org/me/myapp.  When I started, I had a checkout of myapp on the desktop.  So there was a folder ~/Desktop/myapp, in which was a .git/ folder and all the stuff mentioned above.

Restructuring:  This was probably overkill, but it worked.  I started by creating a new folder on the desktop called myapp_heroku.  In it, I made a src/bitbucket/me folder, and I moved myapp/ from the Desktop to that place.  I also changed my setgopath.sh script, so that Desktop/myapp_heroku is the new GOPATH.

Note: now when I'm working on this project, I traverse all the way into the src/bitbucket.org/me/myapp folder, and I work there, but when I do a 'go install' or a 'go get', things are placed a few levels up in the directory tree.

After restructuring, I removed some cruft from the build folder.  Previously, there were bin/ and pkg/ folders in myapp... I got rid of them.  I also removed any source folders that were fetched via 'go get', because dependent files go elsewhere now.

Using godep:  Our goal in this step is to get all the code we depend on, in a manner that will ensure that Heroku grabs the same code when it builds updated versions of the app.

This is where things became un-intuitive.  Go, of course, doesn't have any built-in mechanism for managing dependencies.  Godep essentially just vendors everything into the source tree, which I don't particularly like, but it suffices.

Naturally, we need to get godep first, and add it to our path:

• go get github.com/tools/godep
• export PATH=$PATH:$GOPATH/bin

With that in order, we should restructure our repository ever so slightly:

• git mv src cmd
• git mv src/appserver src/myapp

I don't know why these steps were necessary.  But stuff really didn't work until I made both of those changes.  The Heroku docs obliquely state the first requirement, without any explanation, and the second requirement (which is that the main program you want to run should have the same name as your repository) was just a fact of how the tutorials I read all were done.  None of those tutorials had multiple executables in their projects.

(Update: I might not have needed to rename src/appserver.)

We can use godep to fetch the packages on which we depend:

• godep get golang.org/x/oauth2
• godep get golang.org/x/oauth2/google
• godep get google.golang.org/appengine
• godep get gopkg.in/mgo.v2
• godep get gopkg.in/mgo.v2/bson

Oddly, when fetching oauth2, we get an error that appengine isn't available.  For me, doing a recursive get (godep get golang.org/x/oauth2/...) didn't work.  So I manually got one more package.

Now we can take the 'vendoring' step:

• godep save ./...

And voila!  There's a folder called 'vendor', with all of the code we depend upon, and there's also a Godep folder.  Too bad it won't work.

The problem is that we're going to push our code to a Heroku "dyno" (think "container") and it's going to build the code.  But the mgo.v2 library's optional sasl support will be built when we push to Heroku.  That support depends on libsasl-dev being available on the host machine at build time.  The image for the Heroku dyno I'm using doesn't have libsasl-dev.  So if we were to push this repository to Heroku, it wouldn't build, and the code would be rejected.

The fix is easy: just delete the sasl folder from the vendored mgo.v2:

• rm -rf vendor/gopkg.in/mgo.v2/internal/sasl/

Ugly, but it works.  And indeed, we're close to having everything work at this point.  To test that our vendoring is good, try to locally build the project:

• godep go install -v bitbucket.org/me/myapp/cmd/myapp

The code should build... and it should use the vendored versions of the libraries.

Heroku Stuff: Heroku has a few more requirements that we need to satisfy.  First, we need a file called Procfile.  Its contents will just be "web: myapp".  Second, we need an app.json file.  Its contents are a bit more complex, though still straightforward:

{
  "name": "myapp",
  "description": "MyApp App Server",
  "keywords": [
    "go",
    "MyApp"
  ],
  "image": "heroku/go:1.6",
  "mount_dir": "src/bitbucket.org/me/myapp",
  "website": "https://bitbucket.org/me/myapp",
  "repository": "https://bitbucket.org/me/myapp"
}

Now we can actually create the heroku app.  I was working in Git Bash for Windows, which isn't supported by the Heroku toolbelt.  So I had to switch to the command prompt, and log in:

• cd \Users\Me\Desktop\myapp_heroku\bitbucket.org\me\myapp
• heroku login
• heroku app:create myapp

At this point 'heroku local' should work.  To push to Heroku, we first 'git add' the vendor folder and all of our other recent additions, and then 'git commit'.  Then we can 'git push heroku master'.  This takes longer than a usual git push, because it doesn't finish until Heroku is done building and verifying our program.

Are We Done Yet?  Not really.  If you 'heroku run bash', you can see that bin/admin is present in the dyno, as is bin/myapp.  That's a good sign.  But our app isn't running yet.  One issue I had was that I needed to manually start the app:

• heroku ps:scale web=1

The other issue is that we didn't yet set up the environment variables on Heroku.  We need to 'heroku config:set DBCONNECTSTRING=...' in order to let our app know how to find our cloud-hosted MongoDB instance, we need to set some OAUTH secrets, and we need to set environment variables for whatever else the app is expecting.  But that depends on the app, not on Heroku, so I'm not going to discuss it here.

Wrap-Up:  It took longer than I expected to get this to work.  Since I'll probably have to do it again, I thought it would be worth writing up the steps I took.  If this is helpful to you, too, please leave a comment and let me know.

The transaction_wrap feature in GCC

When using transactional memory, a common challenge is that functions in standard libraries cannot be called from transactions.  Sometimes, the incompatibility is unavoidable (for example, because the library does something that cannot be rolled back).  But in other cases, the implementation is not transaction safe, when other (less performant) implementations could be.

The "transaction_wrap" attribute allows you to specify that function w() should be called in place of o() whenever o() is called from within a transaction.  The syntax is not too cumbersome, but there are a few gotchas.  Here's an example to show how it all works:

// This is a quick demonstration of how to use transaction_wrap in GCC

#include <iostream>
using namespace std;

// We have a function called orig(), which we assume is implemented in a
// manner that is not transaction-safe.
int orig(int);

// This line says that there is a function called wrapper(), which is
// transaction-safe, which has the same signature as orig().  When a
// transaction calls orig(), we would like wrapper() to be called instead.
int wrapper(int) __attribute__((transaction_safe, transaction_wrap (orig)));

// Here is our original function.  It does two things:
//
// 1 - saves its operand to a volatile variable iii.  This is not
//     transaction-safe!
// 2 - adds one to its operand and returns the sum
volatile int iii;
int orig(int x) {
    iii = x;
    return x + 1;
}

// Here is our wrapper function.  It adds two to its operand and returns the
// sum.  Note that we have explicitly implemented this in a manner that
// differs from orig(), so that we can easily see which is called
int wrapper(int x) {
    return x + 2;
}

// Our driver function calls orig(1) from three contexts: nontransactional,
// atomic transaction, and relaxed transaction, and prints the result of each
// call
//
// Be warned: the behavior is not what you expect, because it depends on the
// TM algorithm that is used.  For serial-irrevocable (serialirr), the result
// is (2,2,2).  For serial, ml_wt, and gl_wt, the result is (2, 3, 3).  For
// htm, the result is (2,3,2).
int main() {
    int x = orig(1);
    cout << "orig(1) (raw) == " << x << endl;
    __transaction_atomic { x = orig(1); }
    cout << "orig(1) (atomic) == " << x << endl;
    __transaction_relaxed { x = orig(1); }
    cout << "orig(1) (relaxed) == " << x << endl;
    return 0;
}

Compile the code like this:

g++ -fgnu-tm -std=c++11 -O3 test.cc -o test

And as suggested in the comments, the output will depend on the ITM_DEFAULT_METHOD you choose:

ITM_DEFAULT_METHOD=serialirr ./test
orig(1) (raw) == 2
orig(1) (atomic) == 2
orig(1) (relaxed) == 2
ITM_DEFAULT_METHOD=serial ./test
orig(1) (raw) == 2
orig(1) (atomic) == 3
orig(1) (relaxed) == 3
ITM_DEFAULT_METHOD=ml_wt ./test
orig(1) (raw) == 2
orig(1) (atomic) == 3
orig(1) (relaxed) == 3
ITM_DEFAULT_METHOD=gl_wt ./test
orig(1) (raw) == 2
orig(1) (atomic) == 3
orig(1) (relaxed) == 3
ITM_DEFAULT_METHOD=htm ./test
orig(1) (raw) == 2
orig(1) (atomic) == 3
orig(1) (relaxed) == 2