This script makes some assumptions about where your Maven versions are and how they are named.  First of all, it is assumed that you put all of your Maven installs in the same place.  It could be hacked to look in multiple locations, but we’re lazy developers so why the fuss?  Second assumption is that you retain the directory naming of the tar.gz or .zip distributions of Maven.  These begin with apache-maven-* and that’s how the script finds the versions.  I’m building the 3.0-SNAPSHOTs into the same common location so that I can switch between them easily as well.

As a bonus, if you set up your default M2_HOME to point to the symlink “apache-maven” in your $MAVEN_PARENT location, you can change the default Maven version for new terminal instances as well using defaultmvn.

I know there is some room for improvement, but as it is this script works well on Mac OSX as well as Linux, so hopefully someone else can find it useful.

Installation: Click the “copy to clipboard” link in the top right corner and save this as /etc/profile.d/setmvn.sh or just source it into your terminal by some other means.  Modify the MAVEN_PARENT to your parent location such as /opt or /usr/local/share, etc.

Usage: The command includes completions, so from your shell just “setmvn <hit tab>” and you should see all of your maven versions.  Partial completions work too, so if you are a tab-happy completion-abusing lazy developer like me, this will be right up your alley.

#!/bin/bash
MAVEN_PARENT=/usr/share

function defaultmvn {
    local mvndir=$MAVEN_PARENT
    local ver=${1?Usage: defaultmvn <version>}
    local mvnprefix=apache-maven-

    [ -z "$2" ] || error="Too many arguments"
    [ -d $mvndir/$mvnprefix$ver ] || local error="Unknown Maven version: $ver"
    [ "$(readlink $mvndir/apache-maven)" != "$mvndir/$mvnprefix$ver" ] || local error="Default Maven already set to $ver"

    if [ -n "$error" ]; then
    echo $error
    return 1
    fi

    echo "Setting default Maven to $ver ... "

    if [ "$(/usr/bin/id -u)" != "0" ]; then
    SUDO=sudo
    fi

    $SUDO /bin/rm $mvndir/apache-maven
    $SUDO /bin/ln -s $mvndir/$mvnprefix$ver $mvndir/apache-maven

    echo Done.
}

function setmvn {
    local mvndir=$MAVEN_PARENT
    local ver=${1?Usage: setmvn <version>}
    local mvnprefix=apache-maven-

    [ -d $mvndir/$mvnprefix$ver ] || {
    echo Unknown Maven version: $ver
    return 1
    }

    echo "Setting current Maven version to $ver ..."

    export M2_HOME=$mvndir/$mvnprefix$ver
    PATH=$(echo $PATH | tr ':' '\n' | grep -v $mvndir/$mvnprefix | tr '\n' ':')
    export PATH=$M2_HOME/bin:$PATH

    mvn -v
}

function _setmvn_completion (){
    COMPREPLY=()

    local mvndir=$MAVEN_PARENT
    local cur=${COMP_WORDS[COMP_CWORD]//\\\\/}
    local options=$(cd $mvndir; ls -d -1 apache-maven-* | awk '{match($0,"apache-maven-.*"); print substr($0,14,RLENGTH-13)}' | tr '\n' ' ')

    COMPREPLY=($(compgen -W "${options}" ${cur}))
}

complete -F _setmvn_completion -o filenames setmvn
complete -F _setmvn_completion -o filenames defaultmvn

In order to get the defaultmvn part to work, I have the following in my /etc/profile.d/maven.sh file (adjust based on your OS).

M2_HOME=/usr/share/apache-maven
PATH=$M2_HOME/bin:$PATH
export M2_HOME PATH

So thanks to David Blevins for the still awesome after all these years setjdk script which I completely and unabashedly stole for the basis for the setmvn script.

My basic findings were that the tos-bsl bootstrap loader for the msp430 (Telos, TelosB, etc) does not work with the JCreate, but the bootloader included with the Sentilla SDK is argument compatible with the tos-bsl so if you replace tos-bsl things seem to work.  If anyone knows how to make tos-bsl from the msp430 tool chain work with JCreate please let me know.  In addition, there are some conflicts with the FTDI USB drivers and the communication method used by the Sentilla SDK, which I outline below.

These directions are based on Mac OSX and using the telosb target for compiling.  There are some limitations in doing this (only 3 LEDS on telos platform definition, no accelerometer, etc).  I am working on a platform definition for the JCreate which includes all 8 LEDs and hopefully I can get the accelerometer and ADCs to work as well, but I will save that for another post.

Step 1:  Remove FTDI VCP Drivers
One of the first problems was that the Sentilla code uses the FTDI D2XX libraries to talk directly to the USB device as opposed to the FTDI VCP drivers which map the device to a serial port (COM or /dev/ttyXXX).  Most other software uses the VCP method which looks for the default VID/PID of the FTDI chip and maps any matching devices to the com ports.  Unfortunately the Sentilla devices use the default VID/PID as well, so when you insert them your device gets locked by the VCP driver.  So if you have the VCP drivers installed (which everyone probably does if you are using TinyOS), you need to uninstall them so that the D2XX libraries can talk to the device.  This could be specific to the Mac drivers, but I tend to think it would be a problem for other platforms as well, although FTDI has something called “Combined driver model” for Windows so that might be some kind of option if you are on Windows.

Step 2: Install FTDI D2XX libraries
Go grab the FTDI D2XX libraries and install them according to the directions in the download.  Basically this will involve putting the dll or shared libs in a system library path.

Step 3: Locate tmote-bsl from Sentilla SDK
Locate the tmote-bsl from the Sentilla SDK.  I think the Windows version was included on the CDROM in the PERK kit and the Mac and Linux versions are available here if you are a registered Sentilla customer.  On my Mac, the tmote-bsl is located in /opt/SentillaWork-1.1.01/SentillaWork/plugins/com.sentilla.work_1.1.1/ but this will vary by platform.

Step 4: Create new target for JCreate
Once you locate tmote-bsl, the easiest ways to use it is to create a new target for the JCreate.  Copy /tinyos-2.x/support/make/telosb.target to a new file called jcreate.target in the same directory.  Edit the jcreate.target and modify the bsl variables on lines 12-13 to look like this based on the location of tmote-bsl in step 3 (original values commented):

MSP_BSL ?= /opt/SentillaWork-1.1.01/SentillaWork/plugins/com.sentilla.work_1.1.1/tmote-bsl
#MSP_BSL ?= tos-bsl
MSP_BSL_FLAGS = -bsl=mini
#MSP_BSL_FLAGS = --telosb

Because the new bsl uses the D2XX libraries, there are some differences in the way you reference motes.  So before you would use something like:

make telosb install bsl,/dev/ttyUSB0
Now you are going to use the serial number of the USB device and the jcreate target:

make jcreate install bsl,ftd/M4ASU2X7

To get the USB device serial number you can use the motelist from the same directory as tmote-bsl in the Sentilla SDK (which enumerates the FTDI USB devices by serial number vs COM port), or you can use something like device manager (Windows) or system profiler (Mac OSX).

Using the different device syntax above with the jcreate target, I have been able to load all of the example apps without any issues other than the mismatch in sensors and LEDs.  I will post the jcreate platform definition once I have time to work all of that out.

Step 5 (Optional):  Getting the Java apps to run
Because I uninstalled the VCP drivers, the standard toscom JNI library used for the Java apps won’t be able to talk to the devices.  I suppose it is possible that installing the VCP drivers again at this point might work, but then you would have to uninstall every time you want to flash an app using the bsl.  As I said earlier, Sentilla uses the D2XX libraries in place of the VCP COM port drivers and it appears that the toscom library has been modified to use D2XX as well.  Out of curiosity, I replaced the toscom lib in my tinyos source tree with the one from the Sentilla SDK and re-ran tos-install-jni.  After trying to run some of the Java apps it was clear that the tinyos.jar file did not match the modified toscom JNI lib, so I used the tinyos.jar from Sentilla and that seemed to work up to a point.  Eventually I realized that some parts of the generated message interfaces were not working between the NesC code and Java.  I had the Sentilla tinyos.jar open in IntelliJ and from the errors I was getting it was apparent that the JNI calls has a slightly different signature than what was in TinyOS 2.1.  Once I modified net/tinyos/comm/TOSCommJNI.java to match those signatures, all of the Java apps started working perfectly.  You can download TOSCommJNI.patch and apply it to your local source tree.

At this point you should have a perfectly functioning TinyOS 2.x installation and build tools.

Wow that was a long post!  I know there are a lot of details here but I wanted to be specific and encourage others to offer their advice if there is a better way to do this.  If anyone has suggestions or questions feel free to leave a comment, or even better, post to the tinyos-help mailing list.

So here is my plan…  I’m going to get Android running on this thing ASAP.  I think most of this work has been done already because the similarly spec’d BeagleBoard already has Android running on it.  I am hopeful that the patches are already documented somewhere but it wouldn’t be the first time I have hacked some Linux kernel and driver code.  The end goal is to have a sort of home hub or all in one remote console device with a touch screen LCD, VOIP speakerphone, all in one IR remote, , etc.  Bonus points if I can get ServiceMix or ActiveMQ involved somewhere along the line.  I think an OSGi API for the IR and home page would be rather sweet as well, don’t you?  I will post more in the next week or two once I get my feet back on the ground.  Too excited to think rationally right now 

The possibilities are endless, and I promise to open source everything under the Apache Software License where possible.  Should be a fun project, if anyone is interested in helping out let me know.

The first thing that comes to mind is that both the hardware and the software far exceeded my expectations.  Now I had never spent much time playing with the SDK or reading blogs before the official release of the G1 but I just didn’t expect anything extraordinary from the 1.0 release of Android and a brand new handset model.  I have used other people’s iPhones for short periods of time so I can honestly say that I was surprised at how good the quality is on the G1 handset and the Android software was fantastic for a 1.0 release.

From the pictures I had seen before I bought my handset, I actually thought the handset looked cheap and dorky.  In reality I was surprised at how solid and nice the thing turned out to be.  I bought the new Bronze color model and it really looks quite nice and has a great feel.  Even the flip up screen that reveals the keyboard has a solid feel to it.  I don’t exactly like the keyboard and the little “chin” at the bottom of the handset, but they hardly bother me now that I have gotten used to them.

I’m really looking forward to improvements and I think that although the current release is pretty solid, the opportunities for interesting new features and improvements has me excited.  I guess I am biased since I am am open source Java developer, but the Android software has a lot of potential when you consider all the people that will be able to find new ways to tweak it.  I think there are plenty of people who will be happier working in their familiar Java language than learning Objective-C.

So if you are reading this and have any doubts about the choice between an iPhone or a G1, I recommend playing wih the G1 and giving it a try.  You just might be surprised like me.

The outcome of the class was a Simon game with four colored LED push pads.  The microcontroller at the center of the device is the ATmega168 which is commonly found on the Arduino boards these days.  The software for the game is available from the Sparkfun web site and was programmed onto the chip through the Arduino IDE.  I think Billy and I are going to hack around with the Arduino IDE and write up some new programs on our Simon games just for shits and grins.  We put in a special request for an Arduino/Processing class so that would be a blast if they decide to put one together.

This picture shows just how small these solder joints are.  The trained eye will laugh at my solder work (its quite bad when you look through a magnifying glass), but the damn thing works like a champ…  or it did until it sat in my car for an hour at 15deg F on the way home and something shrunk up from the cold.  But hey, if you hold it just right and give it some love, it works just fine.  I guess I need to buy Billy and I a soldering iron for some touch up work    By the way, we hand soldered *everything* onto this board, including the AT168 and all of those little tiny resistors and caps.  Some of those who had soldering experience finished in about 1.5-2 hours while those of us with nada took up the full 3 hours and then some extra for troubleshooting bad joints, etc.

Matt and Nate did a great job with the class and were extremely helpful to us beginners, even staying an extra hour to help Billy and I troubleshoot a problem with one of our boards and send us home with some swag.  They tell me that they are going to try to do a new class every month or so, so if you live in the Boulder area or you just want an excuse to come put in some slope time in Colorado, keep an eye on their front page for more classes. 

More pictures of the class here on my Flickr.

Thanks to Nate, Matt and the SparkFun folks for a really great time. 

I ended up going through a couple of different battery solutions before finding one that had enough current to properly boot the device AND had good battery life at the same time.  In the end I went with the Tekkeon MP3450 and I have been extremely pleased with it.  This battery is really much larger than I really needed for the CTR-500 but it has the added benefit of being able to power almost any device I use remotely except for my MacBook Pro.  I bought mine from eCost.com for a ridiculously low price of around $80 but normally they go for over $100. 

I have powered the CTR-500 for over 16 hours of average usage and used the battery for charging my phone and iPod several times over and still had at least one light on the battery meter so I guess I have never really gone far enough to find out its limits.  This battery also has a USB port for charging/powering any USB or min-USB device and comes with a handy little retractable USB cord.  They also supply a bag full of little adapters for almost all common DC connectors (I couldn’t find any devices that didn’t have a matching adapter, other than proprietary phone connectors).

One issue I have is that I can’t power on the router with the Sierra 597E Express Card already inserted.  The router seems to cycle repeatedly in a loop which I think is because it can’t get enough surge current to power up the router AND the card.  I haven’t tried any other cards, but I assume this will be true for others.  Either way, it isn’t a big deal to insert the card after the router starts to boot (I barely give it 2 seconds before I pop it in and things work great after that). 

One word of caution, the MP3450 has adjustable voltage from 5v to 19v and it is easy to #@ck up and fry your nice little router.  I know, because I did it….. once.  The top of the unit has a row of lights that serve several purposes.  Normally it displays the currently selected voltage, which for the CTR-500 is the first, and default setting of 5v.  On the side of the battery there is a switch that locks the voltage and when you press the button on top, you see battery level indicated by the number of lights.  If you unlock this switch, a press of the button changes the voltage.  So the moral of the story is, don’t ever leave the damn thing unlocked and throw it into your backpack where something can accidentally press the button several times as you walk down the street until the voltage goes up to where it pops, emits a faint little bit if smoke, and renders your $160 router completely useless. 

So now that I have that off my chest, I really love the totally mobile setup and as you can see from the pictures the battery is about the same overall form factor as the router and the express card.  I usually have them all set up just like the picture and I wrap an elastic/velcro strap around them all to make a nice little package to throw in my backpack.  What I would really like is to find a removable hard drive case with a little reinforcement so that I can fit it all in there perfectly and use small external antennas, but that is getting a bit overkill.  Then again…

I promised the attendees that I would post the slides so in case any of you read my blog, here you go.