Processing and Processing-JS on the BeagleBoard under Angstrom

After reading the blog post about the serial port challenges in Processing and the method for fixing them, I decided to download the IDE and try it myself.  It seems to work reasonably well.  I haven't quite managed to learn enough about the Arduino to understand how they use Processing or how limited their implementation of it is, but I was able to install and run the Arduino tool on my BeagleBoard after applying Koen's serial port library fix.  I hope to use the tool to download applications onto my Trainer-xM, but I haven't yet been able to compile the examples natively because I haven't yet built avr-gcc.

This is highly related to my current personal project, which is working with Processing-JS.  I've been talking a lot about a BeagleBoard Linux Education project, but haven't really kicked the project off after working with others on the scope.  Mark Yoder's ECE497 class is where the most visible advancement seems to be taking place right now, though I've heard of several other educators also creating courses with the BeagleBoard, including the Stanford New Musical Controllers workshop.

For me, I like the ideas of avoiding compilation, working in the most popular development environment today (the browser) and being able to remote my interface anywhere in the world over the web.  I also believe the zero-install nature of web applications and the familiarity of working within a browser make it the perfect environment for newbies.  To that end, I've made a little fork off of my Linux education project to focus on JavaScript-based development.  I now have both Cloud9 and Processing.js installing as submodules.  Under Angstrom, I'm able to easily run Chromium as one of my browser options and see the output from Processing.js, such as the picture here.  Now to see which environment gets me talking to my Trainer-xM board first.

Also, sorry about the delayed BeagleCast this week--resulting in some of the topics not being timely.  I've had a challenge getting a call scheduled with Khasim to discuss Rowboat.

Node.JS-based Cloud9 JavaScript IDE running on a BeagleBoard

Yesterday, I decided I was going to get Cloud9 running on my BeagleBoard. I didn't document every step, but below are a few helpful hints. I'm working with a recent Angstrom Distribution build with Node.JS v0.2.6.

At first, I tried using Node.JS v0.2.1 and I found that the 'connect' module wasn't present. I went to install 'npm', but the install attempts failed silently. When I found that v0.2.6 was in the feeds, I tried installing 'npm' again and it succeeded without much of a headache. I installed v0.2.19 of 'npm'.

Since the node-o3-xml package needs to be compiled for Cloud9, I installed a bunch of native tools onto my BeagleBoard, including 'opkg install task-sdk-native nodejs-dev', but I don't remember 100% of what I installed. My confusion began around an error on 'import Scripting' when running node-waf. Fortunately, someone already figured the issue out for me when they were trying to build node-inotify on a Gumstix board. I installed the extra Python tools and copied the .py code from my Mac. I did need to edit wscript to remove any x86 specific optimization flags and remove any .pyo files that accidentally got copied over.

Once I built o3, I installed it into my Cloud9 directory, which I checked out following the online directions. I am working from the Cloud9 0.2.0 tag. Since the submodules of Cloud9 include a set of pre-built binaries for o3, I added a repository that included my newly built ARM binaries.

I think this was pretty much it to getting Cloud9 invoked, but using the latest Firefox 4 beta as a client wasn't working. I tried using the '-d' flag at invocation and moving Cloud9 to a user account instead of root, but that didn't help. Based on a blog post that described invoking Cloud9 on an Ubuntu machine, I was using this command-line to perform the start-up:

node ~/cloud9/bin/cloud9.js -c ~/cloud9/config.js -w ~/testproject -d

I decided to install Chrome to see if it was a browser dependency and viola!

After a simple web server app, I decided to poke the LED SYSFS entries. I needed to change the SYSFS file entry permissions to 777 to enable my user account to set the state, but I was easily able to do so.

Next step is to show how JavaScript closures can be used to create a web page that responds quickly when the USER button is pressed, generating a Linux input event.

Am I the only one that gets how cool it will be to be able to distribute pre-configured SD cards you can drop into your BeagleBoard, plop it onto a network and start editing code to peek and poke hardware using an IDE without ever installing *anything*?