mate-manual.tex

tinyos中文手册,是根据tinyos系统自带手册翻译过来的,虽然质量不好,但是对英文不强的人还是有用的

\documentclass[12pt]{article}

\usepackage{graphicx}
\usepackage{graphics}
\usepackage{multicol}
\usepackage{epsfig,amsmath,amsfonts}
\usepackage{xspace}
\usepackage{subfigure}

\makeatletter                                   % Make '@' accessible. 
\oddsidemargin=0in                              % Left margin minus 1 inch.
\evensidemargin=0in                             % Same for even-numbered pages.
\marginparsep=0pt                               % Space between margin & text

\renewcommand{\baselinestretch}{1.2}              % Double spacing

\textwidth=6.5in                                % Text width (8.5in - margins).
\textheight=9in                                 % Body height (incl. footnotes)

\topmargin=0in                                  % Top margin minus 1 inch.
\headsep=0.0in                                  % Distance from header to body.
\skip\footins=4ex                               % Space above first footnote.
\hbadness=10000                                 % No "underfull hbox" messages.
\makeatother                                    % Make '@' special again.

\newcommand{\mate}{Mat\'{e}\xspace}
\newcommand{\bomb}{Bombilla\xspace}

\title{Mat\'{e}: Safe and Rapid Sensor Network Scripting}
\author{Philip Levis\\[e-mail]}
\date{}

\begin{document}

%\fontfamily{cmss}                               % Make text sans serif.
%\fontseries{m}                                  % Medium spacing.
%\fontshape{n}                                   % Normal: not bold, etc.
%\fontsize{10}{10}                               % 10pt font, 10pt line spacing 

\maketitle
\vspace{2in}
\begin{center}
Version 1.0\\
March 22, 2004
\end{center}

\fontfamily{cmr}                                % Make text Roman (serif).
\fontseries{m}                                  % Medium spacing.
\fontshape{n}                                   % Normal: not bold, etc.
\fontsize{10}{10}                               % 10pt font, 10pt line spacing


\thispagestyle{empty}
\newpage
\tableofcontents
\newpage

\section{Introduction}

Programming sensor networks is difficult. They are large scale,
distributed systems with limited resources, lossy communication, whose
testing and debugging is made especially difficult by their being
embedded in uncontrolled environments. Often, it is hard to know exactly
what a certain algorithm or application will do without deploying it;
changes that seem minor can greatly change system behavior.
Deployment, however, is a time consuming and arduous process.

Sensor networks have a wide range of users, most of whom are not expert
programmers. However, these users need to use sensor networks in their
applications, such as habitat or structural monintoring, and therefore
need be able to program. This programming cannot involve many low-level
details of the system, or require expert knowledge of the system hardware
or a great deal of programming experience.

\mate is a system designed to provide an accessible programming
interface to sensor network end users. The core of \mate is a tiny VM
that runs on top of TinyOS, a sensor network operating system. The
bytecode interpreter can be customized for specific applications or
deployments. End users write programs has simple, high-level scripts,
which compile to the VM instruction set. These programs then
self-propagate through a network. Reprogramming only requires
introducing a single copy of a new program. This copy will then
install itself across the entire network.

This document describes \mate and how to use it. Its purpose is to
serve as an introduction to the system for users. It is divided into
four major sections, with increasing degrees of technical
detail. Section~\ref{sec:tinyscript} describes the TinyScript
language, and how one uses the Scripter tool to inject programs into a
\mate network. This section is intended for end users, and requires no
knowledge of TinyOS. Section~\ref{sec:building} describes how to build
a \mate VM and scripting environment. As programs will be constrained
by decisions made during this process, it is intended for users who
are knowledgeable about the targeted application domain.
Finally, Section~\ref{sec:extending} describes how to extend \mate VMs by
adding new function primitives and execution events by writing TinyOS
components in nesC.

\section{Programming with \mate}

There are two basic parts to programming a \mate network. The first is
a \mate VM installed on the network's motes. The second is a Java UI
for writing and injecting programs into the network. \mate nesC code
(for VMs) can be found in {\tt tos/lib/VM} while the Java tool code
can be found in {\tt tools/java/net/tinyos/script}.

Section~\ref{sec:building} describes how users can build customized
VMs; to start, however, you may want to use Bombilla, a simple example
VM. \bomb can be found in {\tt apps/Bombilla}. To get started, go to
{\tt apps/Bombilla} and compile for your desired platform (e.g., {\tt
make pc} or {\tt make mica2}). This will build a TinyOS VM as well as
a scripting environment.

If you're using motes, then you should install the VM on a few nodes
with {\tt make reinstall.x} where {\tt x} is the moteID for each
node. You shouldn't use a GenericBase as a programming point for a
\mate network. For example, if you're using a serial port to send data, you should
plug a \mate node into the programming board. To efficiently program a
network, you need to be able to reliably install new programs on a
single node (e.g., over the serial cable). If you use a GenericBase,
it's possible that some fragments of programs may be lost, preventing
the network from reprogramming.

Once you've set up your programming point, start the Scripter from the
Bombilla directory (it must be from this directory, to correctly find
all of the VM-specific configuration files), specifying the
communication port. For example,

\begin{verbatim}
java net.tinyos.script.Scripter -comm tossim-serial
\end{verbatim}

starts a Scripter to talk to TOSSIM through a virtual serial port to
mote 0. You can then write programs and inject them into a network.

\section{End Users: TinyScript}
\label{sec:tinyscript}

\mate has an event-driven execution model. Every \mate VM
has a set of events that trigger execution, such as receiving a
packet, or a timer firing. When one of these events occur, it triggers
the appropriate handler script to run. Handlers are written in a
simple BASIC-like language called TinyScript.

\subsection{Scripter}

Scripter is a Java tool that compiles TinyScript programs to the
instruction set of a \mate VM. As \mate VMs are customizable, programs
must be compiled for a specific VM, and will only run properly on that
VM. Compiling the same program to two different VMs will probably
result in different binary code for each.

\begin{figure}
\centering
\includegraphics[width=6in]{fig/scripter.jpg}
\caption{The Scripter Interface}
\label{fig:scripter}
\end{figure}

Figure~\ref{fig:scripter} shows a screenshot of the current Scripter
GUI. Scripter {\bf must be run from the VM application directory} and
has an optional communication argument:

\begin{verbatim}
    java net.tinyos.script.Scripter [-comm source] <vm-description>
\end{verbatim}

The comm parameter tells the Scripter where to send code packets,
whether it be to TOSSIM, a serial port, or a SerialForwarder.

The Scripter window is divided into three parts. The left subwindow is
where you select what event handler you want to install, and the
version number. Motes ignore handlers with older version numbers than
what they currently have. Normally, the Scripter automatically handles
these; each successful compilation of a given handler increments its
version number. However, you can manually change it if need be.

The left subwindow also keeps a tally of all currently used shared
variables (these are discussed in Section~\ref{sec:variables}). When a
shared variable is no longer used by any handler, the Scripter
deallocates it.

The center window is where you write TinyScript, which the rest of
this section descibes. The right window provides the list of available
primitives (library functions). Clicking on one of the primitives
brings up a brief description of its use in the lower text area.

To install a new event handler, you choose which event you wish to
write for, write its code in the Program Text window and press the
Inject button. TinyScript programs have a maximum size (approximately
240 bytes). Writing programs that are too long will cause a
compile-time error when the Scripter tries to inject them into a
network.

If you quit Scripter using the File menu, then the interface saves its
current state for later use. That is, it keeps track of the current
handler code, versions, and shared variables; you can quit and restart
the interface, resuming where you left off.

\subsection{Script Structure}

This is an example TinyScript program that increments a counter:

\begin{quotation}
\begin{verbatim}

! Define a shared variable, counter
shared counter;

! Increment it
counter = counter + 1;

\end{verbatim}
\end{quotation}

In TinyScript programs, all variables must be declared before any
program statements. For example, the following program is invalid (and
will throw a compilation error):

\begin{quotation}
\begin{verbatim}

! Define a shared variable, counter
shared counter;

! Increment it
counter = counter + 1;

! Define a shared variable, index: ERROR
shared index;

\end{verbatim}
\end{quotation}

There can only be one statement per line, and statements generally end
with a semicolon. {\tt !} declares the start of a comment, which extends
to the end of a line. For example,

\begin{quotation}
\begin{verbatim}

shared counter; ! Define a shared variable, counter
counter = counter + 1; ! Increment it

\end{verbatim}
\end{quotation}

is valid TinyScript code.

Certain words are TinyScript keywords, and cannot be used in programs
to name variables or functions. In the above scripts, {\tt shared} is
a keyword, declaring {\tt counter} to be a shared variable.

TinyScript programs are for the most part case-sensitive. Keywords
exist as both their uppercase and lowercase versions: {\tt shared} can
also be written {\tt SHARED}, but cannot be written {\tt sHarEd}.

\subsection{Variables}
\label{sec:variables}

TinyScript programs have two basic variable types: values and buffers. In the
above programs, the keyword {\tt shared} declared the variables to be
values. Values can also be declared with the keyword {\tt private}:
Section~\ref{sec:parallelism} describes the distinction between the two. The
keyword {\tt buffer} declares a data buffer. Values represent a single
data item, such as an integer or a sensor reading. Buffers are small
collections of values.

Both values and buffers are dynamically typed. That is, the variables
themselves have no explicit type in a program; instead, their type
is determined dynamically as a program runs. In this program,

\begin{quotation}
\begin{verbatim}

shared counter; 
shared sensor;
counter = call random();
sensor = call light();

\end{verbatim}
\end{quotation}

the variable {\tt counter} takes the type integer ({\tt rand()} returns an
integer) while {\tt sensor} takes the type light.

Types constrain how values can be modified, and how buffers can be
accessed. There is one basic type, integer (16-bit, signed).
Additionally, every sensor has its own type. Integers can be modified
freely, through arithmetic, assignment, and other
transformation. Sensor readings, however, are immutable. You cannot
add two sensor readings, even if from the same sensor.

The idea is that sensor readings should only be what is actually read
from a sensor. Transformations on these readings should be distinguishable
from actual readings. Additionally, allowing transformation raises
problematic questions: what is the type of a light reading added to a
humidity reading?

To modify sensor readings, they must be cast to an integer. For example,
this program computes an exponentially weighted moving average of the
light sensor:

\begin{quotation}
\begin{verbatim}

shared sensor; 
shared aggregate;

sensor = call light();
aggregate += call cast(sensor); ! Cast light reading to integer
aggregate = aggregate / 2;

\end{verbatim}
\end{quotation}

Buffers also have a type, which defines what values can be placed in
it. A cleared buffer has no type, and takes the type of the first
value placed in it. In the following program, {\tt aggBuffer} is
cleared, which clears its type. An integer ({\tt aggregate}) is added
to the buffer, making the buffer of the type integer.

\begin{quotation}
\begin{verbatim}

shared sensor;
shared aggregate;
buffer aggBuffer;

sensor = call light();
aggregate += call cast(sensor); ! Cast light reading to integer
aggregate = aggregate / 2;

call bclear(aggBuffer); ! Clear all buffer entries and type
aggBuffer += aggregate; ! Append aggregate value to buffer
                        ! Buffer is now of type integer

\end{verbatim}
\end{quotation}

Buffers have a fixed maximum size of ten values. The function {\tt
bfull()} can be used to see if a buffer is full. Individual buffer
values can be accessed by indexing into a buffer. The following
program obtains the median value stored in a buffer:

\begin{quotation}
\begin{verbatim}

shared size;
shared median;
buffer aggBuffer;
 
call bsorta(aggBuffer);        ! Sort buffer entries in ascending order
size = call bsize(aggBuffer);  ! Number of entries in buffer
median = aggBuffer[size / 2];  ! Return median value

\end{verbatim}
\end{quotation}

An empty index value implies the tail (last value) of a buffer on