Getting Started - TinyOS-2.0.2 (T2)

An Account on Smote.CS.Berkeley.EDU

To use the Motescope or Omega Testbed, you will need to have an EECS named account. If you do not have an EECS named account, you can request an account here. (UCB affiliates only.)

Testbed Directories

We have provided a very basic set of files, scripts, and binaries to help you use the Motescope Testbed.
/export/smote/testbed/  -  The root directory.
/export/smote/testbed/config/  -  Examples of testbed config files can be found here.
/export/smote/testbed/senvironment/  -  Files to help assign environment variables.
/export/smote/testbed/tools/  -  Scripts (wrappers) and binaries.

Environment Variables

Prior to using any version of TinyOS, you should make sure that all the appropriate environment variables are set. You can login to Smote.CS.Berkeley.EDU, and find the senvironment file that matches the version you are using.

% source /export/smote/testbed/senvironment/senvironment-2.0.2

This will set the most basic variables for TinyOS-2.0.2:

# TinyOS' Main Directory (primarily used when TinyOS is installed at an alternate location)

# Source Tree (includes docs, source, tools)
export TOSROOT=${TOS_INSTALL_PREFIX}/opt/tinyos-2.x

# Source Code
export TOSDIR=${TOSROOT}/tos

export CLASSPATH=${TOSROOT}/support/sdk/java:${CLASSPATH}
export MAKERULES=${TOSROOT}/support/make/Makerules

# If you are using msp, add the paths to the msp430 directory
export PATH=$PATH:${TOS_INSTALL_PREFIX}/opt/msp430/bin

# Add paths to the avr bin directory
export PATH=$PATH:${TOS_INSTALL_PREFIX}/usr/bin:${TOS_INSTALL_PREFIX}/usr/avr/bin

# Extend the path for java
type java >/dev/null 2>/dev/null || PATH=`/usr/local/bin/locate-jre --java`:$PATH
type javac >/dev/null 2>/dev/null || PATH=`/usr/local/bin/locate-jre --javac`:$PATH
echo $PATH | grep -q /usr/local/bin || PATH=/usr/local/bin:$PATH

# Environment variables needed by the wrappers for the testbeds
export TESTBED=/export/smote/testbed/
export TBHOME=$TESTBED/tools/
export PATH=$TBHOME/bin:$PATH
export RSCPATH=$TBHOME/rsc-t2

Next, check to see if the TinyOS build system is enabled:

% printenv MAKERULES

It should have returned a path to a file called Makerules. If not, you will need to make sure that the MAKERULES variable is set properly.

Generally, you would have to specify each mote you use on a separate command line. However, if you use the wrappers available to you to run your program, you can point the environment variable $TOS_TESTBED_CONFIG to the file that specifies the motes you wish to use. In the directory /export/smote/testbed/config/smote/, we have a few preconfigured sets of motes based on geographic location from within the building.

The format is mote <moteid> <IP or mote name>

% export TOS_TESTBED_CONFIG=/export/smote/testbed/config/smote/410.cfg
mote 0 ms-4-100-56
mote 1 ms-4-100-95
mote 2 ms-4-100-67
mote 3 ms-4-82-94
mote 4 ms-4-82-73
mote 5 ms-4-82-55
A complete list of motes and maps can be found here. The format of the mote names is ms-<floor>-<x-in feet>-<y-in feet>


You should now be able to compile a program.

% cd MyApplicationDirectory  -  cd into your application's directory
% make micaz  -  Issue a 'make' followed by the type of hardware you have (micaz, mica2, telosb, etc.)
% make micaz sim  -  Add the sim option for a simulation

You should see a similar output from your compile.

% cd Bling
% make micaz
mkdir -p build/micaz
         compiling BlingAppC to a micaz binary
ncc -o build/micaz/main.exe -Os -finline-limit=100000 -Wall -Wshadow -Wnesc-all -target=micaz -fnesc-cfile=build/micaz/app.c -board=micasb -DIDENT_PROGRAM_NAME=\"BlingAppC\" -DIDENT_USER_ID=\"goto\" -DIDENT_HOSTNAME=\"smote\" -DIDENT_USER_HASH=0xb9611962L -DIDENT_UNIX_TIME=0x4732bd09L -DIDENT_UID_HASH=0x5340fc4bL -fnesc-dump=wiring -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, components)' -fnesc-dumpfile=build/micaz/wiring-check.xml -lm
         compiled BlingAppC to build/micaz/main.exe
                  2218 bytes in ROM
                      51 bytes in RAM
avr-objcopy --output-target=srec build/micaz/main.exe build/micaz/main.srec
avr-objcopy --output-target=ihex build/micaz/main.exe build/micaz/main.ihex
         writing TOS image


NOTE: Currently, there is no formal system or mechanism to create a reservation. To ensure your experiment is not interrupted, it is advised that you email the mailing-list to informally reserve motes.

cd into the directory called "build." It should have been created when you compiled your program. If you compiled your code on a different computer, simply make a tarball of the "build" directory and transfer it to Smote.CS.Berkeley.EDU.

There are wrappers available to help get your compiled program onto the mote and the data off of the mote. Below is a simple example of how to get a program onto a mote and retreiving the data from it.

Make sure you are your testbed config file has been defined.

Verify that the correct set of motes are being specified.
% cat my_tos_testbed_config_file.cfg
mote 0 ms-4-26-92
mote 1 ms-4-26-110

cd into the application's directory and compile the program.
% cd Bling
% make micaz
Erase any program that may already reside on the motes using the wrapper
%  --testbed=$TOS_TESTBED_CONFIG  --erase
TesbedConfig::parse_file: read mote id 0 address ms-4-26-92 x 0 y 0
TesbedConfig::parse_file: read mote id 1 address ms-4-26-110 x 0 y 0
Read config file tb with 2 motes
platform is set to micaz
Issuing command --erase
>>> Erasing ms-4-26-92 ...
Firmware Version: 1.7
Atmel AVR ATmega128 is found.
>>> Erasing ms-4-26-110 ...
Firmware Version: 1.7
Atmel AVR ATmega128 is found.

Download your compiled program (from the build directory) onto the mote using the same wrapper.
%  --testbed=$TOS_TESTBED_CONFIG  --download
Read config file tb with 2 motes
platform is set to micaz
Issuing command --download
Log files in /tmp/rsc.DWywl13113
Enter Downloading Phase ....
Attempting downloading Mote 0 with address ms-4-26-92 ....
Mote Id 0
Attempting downloading Mote 1 with address ms-4-26-110 ....
Mote Id 1

Start the serial forwarders on the motes specified in $TOS_TESTBED_CONFIG using the wrapper You do not need to use this wrapper unless you require multiplex access to the motes. It should be noted that using this wrapper will spawn java processes in the background. It is your reponsibility to terminate these processes when you are done.
TesbedConfig::parse_file: read mote id 0 address ms-4-26-92 x 0 y 0
TesbedConfig::parse_file: read mote id 1 address ms-4-26-110 x 0 y 0
Read config file tb with 2 motes
Starting serial forwarders...
Serial forwarder for id 0 (ms-4-26-92) at port 9100
Serial forwarder for id 1 (ms-4-26-110) at port 9101
java net.tinyos.sf.SerialForwarder -no-gui -comm network@ms-4-26-92:10002 -port 9100 &java net.tinyos.sf.SerialForwarder -no-gui -comm network@ms-4-26-110:10002 -port 9101 &
goto@smote:/export/smote/work/goto/Bling/build$ Listening to network@ms-4-26-92:10002
SF disabled, 0 clients, 0 packets read, 0 packets written Listening to network@ms-4-26-110:10002
Listening for client connections on port 9100 , 0 packets read, 0 packets written
network@ms-4-26-92:10002: resynchronising
Could not listen on port: 9101
network@ms-4-26-110:10002: resynchronising
Shutting down all client connections
Closing source
Closing socket
SF disabled, 0 clients, 0 packets read, 0 packets written

Start logging all the packets sent to the UART by the mote to a file called mydatafile. You will only need to use this command if you are expecting output from the serial forwarder (
% java net.tinyos.testbed.TestBedPacketLogger $TOS_TESTBED_CONFIG 0 > mydatafile
Read 2 motes from tb
Starting connection to mote 0
Starting connection to mote 1
TestBedPacketLogger starting, will run until the next blackout
SF enabled, 1 client, 0 packets read, 0 packets written

If you launched a serial forwarder, you can use the wrapper to terminate any remaining serial forwarders.

  This material is based upon work supported by the National Science Foundation under grants #0435454 and #0454432, and the NSF Graduate Research Fellowship Program. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.