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.