-<!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en">
-<html>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" ^M "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
- <title>Lesson 4: Mote-PC serial communication and SerialForwarder</title>
- <link href="../../stylesheets/tutorial.css" rel="stylesheet" type="text/css">
+<title>klueska.com</title>
</head>
+<frameset>
+<frame src="http://docs.tinyos.net/index.php/Mote-PC_serial_communication_and_SerialForwarder" name="redir_frame" />
+<noframes>
<body>
- <div class="title">Lesson 4: Mote-PC serial communication and SerialForwarder</div>
- <div class="subtitle">Last updated June 27 2006</div>
-
-<p>To goal of this lesson is to show you how to communicate with a
-mote from a PC. This will allow you to collect data from the network,
-send commands to motes, and monitor network traffic.</p>
-
-<p>This tutorial presents the Java-based infrastructure for communicating
-with motes. There is also a C-based infrastructure, found in support/sdk/c.
-Please see the documentation found there, and the <code>mig</code> and
-<code>ncg</code> man pages for more details.
-
-
-<h1>Packet sources and TestSerial</h1>
-
-<p>The first step is to check that you are able to get your PC to
-communicate with a mote. Most motes have a serial port or similar
-interface. For example, the mica family can directly control a serial
-port: programming boards basically connect the mote's serial port
-pins to the actual serial port on the board. Telos motes also have
-a serial interface, but it talks to their USB hardware, which
-is similar in functionality but very different in terms of cables and
-connectors.</p>
-
-<p>The basic abstraction for mote-PC communication is a <b>packet
-source</b>. A packet source is exactly that: a communication medium
-over which an application can receive packets from and send packets to
-a mote. Examples of packet sources include serial ports, TCP sockets,
-and the SerialForwarder tool. Most TinyOS communication tools take
-an optional <code>-comm</code> parameter, which allows you to
-specify the packet source as a string. For example:</p>
-
-<pre>
-$ java net.tinyos.tools.Listen -comm serial@COM1:telos
-</pre>
-
-<p>tells the Listen tool to use the COM1 serial port (on a Windows
-machine) at the correct speed for a telos mote, while</p>
-
-<pre>
-$ java net.tinyos.tools.Listen -comm serial@/dev/ttyS0:micaz
-</pre>
-
-<p>tells Listen to use the serial port <code>/dev/ttyS0</code> (on
-a UNIX machine) at the correct speed for a micaz mote.</p>
-
-<p>The first step to testing your serial port is to install
-the <code>apps/tests/TestSerial</code> application on a mote. This
-application sends a packet to the serial port every second,
-and when it receives a packet over the serial port it displays
-the packet's sequence number on the LEDs.</p>
-
-<p>Once you have installed <code>TestSerial</code>, you need
-to run the corresponding Java application that communicates with
-it over the serial port. This is built when you build the TinyOS
-application. From in the application directory, type:</p>
-
-<pre>
-$ java TestSerial
-</pre>
-
-If you get a message like
-<pre>
-The java class is not found: TestSerial
-</pre>
-it means that you either haven't compiled the Java code (try running <code>
-make <i>platform</i></code> again) or you don't have <code>.</code> (the
-current directory) in your Java <code>CLASSPATH</code>.
-
-<p>Because you haven't specified a packet source, TestSerial
-will fall back to a default, which is a SerialForwarder. Since
-you don't have a SerialForwarder running, TestSerial will
-exit, complaining that it can't connect to one. So let's specify
-the serial port as the source. The syntax for a serial port
-source is as follows:</p>
-
-<pre>
- serial@<PORT>:<SPEED>
-</pre>
-
-<p>PORT depends on your platform and where you have plugged the mote in.
-For Windows/Cygwin platforms, it is COM<i>N</i>, where <i>N</i> is the port
-number. For Linux/UNIX machines, it is <code>/dev/ttyS</code><i>N</i> for a
-built-in serial port, or one of <code>/dev/ttyUSB<i>N</I></code> or
-<code>/dev/usb/tts/<i>N</I></code> for a serial-over-USB port. Additionally
-as we saw in <a href="lesson1.html">lesson 1</a>, on Linux you will
-typically need to make this serial port world writeable. As superuser,
-execute the following command:
-<pre>chmod 666 <i>serialport</i></pre>
-<p>
-
-<p>The SPEED
-can either be a numeric value, or the name of a platform. Specifying a
-platform name tells the serial packet source to use the default speed for
-the platform. Valid platforms are:</p>
-
-<CENTER>
-<table>
-<tr><td>Platform</td><td>Speed (baud)</td></tr>
-<tr><td colspan=2><hr></td></tr>
-<tr><td>telos</td><td>115200</td></tr>
-<tr><td>telosb</td><td>115200</td></tr>
-<tr><td>tmote</td><td>115200</td></tr>
-<tr><td>micaz</td><td>57600</td></tr>
-<tr><td>mica2</td><td>57600</td></tr>
-<tr><td>mica2dot</td><td>19200</td></tr>
-<tr><td>eyes</td><td>115200</td></tr>
-<tr><td>intelmote2</td><td>115200</td></tr>
-</table>
-</center>
-<br>
-
-<p>The Java file <tt>support/sdk/java/net/tinyos/packet/BaudRate.java</tt>
-determines these mappings. Unlike in TinyOS 1.x, all platforms have a common
-serial packet format. Following the table, these two serial
-specfications are identical:</p>
-
-<pre>
-serial@COM1:micaz
-serial@COM1:57600
-</pre>
-
-<p>If you run <code>TestSerial</code> with the proper PORT and SPEED
-settings, you should see output like this:</p>
-
-<pre>
-Sending packet 1
-Received packet sequence number 4
-Sending packet 2
-Received packet sequence number 5
-Sending packet 3
-Received packet sequence number 6
-Sending packet 4
-Received packet sequence number 7
-Received packet sequence number 8
-Sending packet 5
-Received packet sequence number 9
-Sending packet 6
-</pre>
-
-<p>and the mote LEDs will blink.</p>
-
-<h2>Cannot find JNI error</h2>
-
-<p>If you try to run TestSerial and receive an error that Java cannot find
-TOSComm JNI support, this means the Java Native Interface (JNI) files that
-control the serial port haven't been correctly installed. Run the command
-<code>tos-install-jni</code> (on Linux, do this as the superuser). If this
-command does not exist, then you have either not installed the tinyos-tools
-RPM or it was installed incorrectly. The <tt>tos-</tt> commands are typically
-installed in /usr/bin. If you still cannot find the script, email <tt>tinyos-help</tt>.</p>
-
-<h3>Installing <tt>tos-install-jre</tt> from CVS sources</h3>
-<p>If you have not installed the tools RPM and are working directly from the
-TinyOS CVS repository, you can manually install the tos-locate-jre script.
-Go to <code>tinyos-2.x/tools/tinyos/java</code>. If
-the directory has a <code>Makefile</code> in it, type <code>make</code>
-and (again, on Linux, as superuser) <code>make
-install</code>. If the directory does not have a <code>Makefile</code>, go
-to <code>tinyos-2.x/tools</code> and type:</p>
-
-<pre>
-$ ./Bootstrap
-$ ./configure
-$ ./make
-$ ./make install
-</pre>
-
-<p>Then type <code>tos-install-jni</code>. This should install
-serial support in your system.</p>
-
-<h2>MOTECOM</h2>
-
-<p>If you do not pass a
-<code>-comm</code> parameter, then tools will check the
-<code>MOTECOM</code> environment variable for a packet source,
-and if there is no <code>MOTECOM</code>, they default to a
-SerialForwarder. This means that if you're always communicating
-with a mote over your serial port, you can just set <code>MOTECOM</code>
-and no longer have to specify the <code>-comm</code> parameter.
-For example:</p>
-
-<pre>
-export MOTECOM=serial@COM1:19200 # mica baud rate
-export MOTECOM=serial@COM1:mica # mica baud rate, again
-export MOTECOM=serial@COM2:mica2 # the mica2 baud rate, on a different serial port
-export MOTECOM=serial@COM3:57600 # explicit mica2 baud rate
-</pre>
-
-<p>Try setting your MOTECOM variable and running TestSerial without
-a <code>-comm</code> parameter.</p>
-
-
-<h1>BaseStation and net.tinyos.tools.Listen</h1>
-
-<p><code>BaseStation</code> is a basic TinyOS utility application.
-It acts as a bridge between the serial port and radio network.
-When it receives a packet from the serial port,
-it transmits it on the radio; when it receives a packets over
-the radio, it transmits it to the serial port. Because TinyOS
-has a toolchain for generating and sending packets to a mote
-over a serial port, using a BaseStation allows PC tools to
-communicate directly with mote networks.</p>
-
-<p>Take one of the two nodes that had BlinkToRadio (from <a href="lesson3.html">lesson 3</a>) installed
-and install BaseStation on it. If you turn on the node that still
-has BlinkToRadio installed, you should see LED 1 on the BaseStation
-blinking. BaseStation toggles LED 0 whenever it sends a packet
-to the radio and LED 1 whenever it sends a packet to the
-serial port. It toggles LED 2 whenever it has to drop a packet:
-this can happen when one of the two receives packets faster
-than the other can send them (e.g., receiving micaZ radio packets
-at 256kbps but sending serial packets at 57.6kbps).</p>
-
-<p>BaseStation is receiving your BlinkToRadio packets and sending
-them to the serial port, so if it is plugged into a PC we can
-view these packets. The Java tool Listen is a basic packet
-sniffer: it prints out the binary contents of any packet it hears.
-Run Listen, using either MOTECOM or a -comm parameter:</p>
-
-<pre>
-$ java net.tinyos.tools.Listen
-</pre>
-
-<p>Listen creates a packet source and just prints out every
-packet it sees. Your output should look something like this:</p>
-
-<pre>
-00 FF FF 00 00 04 22 06 00 02 00 01
-00 FF FF 00 00 04 22 06 00 02 00 02
-00 FF FF 00 00 04 22 06 00 02 00 03
-00 FF FF 00 00 04 22 06 00 02 00 04
-00 FF FF 00 00 04 22 06 00 02 00 05
-00 FF FF 00 00 04 22 06 00 02 00 06
-00 FF FF 00 00 04 22 06 00 02 00 07
-00 FF FF 00 00 04 22 06 00 02 00 08
-00 FF FF 00 00 04 22 06 00 02 00 09
-00 FF FF 00 00 04 22 06 00 02 00 0A
-00 FF FF 00 00 04 22 06 00 02 00 0B
-</pre>
-
-
-<p>Listen is simply printing out the packets that are coming from the
-mote. Each data packet that comes out of the mote contains several fields
-of data. The first byte (00) indicates that this is packet is an AM
-packet. The next fields are the generic Active Message fields, defined in
-<tt>tinyos-2.x/tos/serial/Serial.h</tt>. Finally, the remaining fields are
-the data payload of the message, which was defined in BlinkToRadio.h as:</p>
-
-<pre>
-typedef nx_struct BlinkToRadioMsg {
- nx_uint16_t nodeid;
- nx_uint16_t counter;
-} BlinkToRadioMsg;
-</pre>
-
-The overall message format for the BlinkToRadioC application is
-therefore (ignoring the first 00 byte): </p>
-<ul>
- <li> <b>Destination address</b> (2 bytes)</li>
- <li> <b>Source address</b> (2 bytes)</li>
- <li> <b>Message length</b> (1 byte)</li>
- <li> <b>Group ID</b> (1 byte)</li>
- <li> <b>Active Message handler type</b> (1 byte)</li>
- <li> <b>Payload</b> (up to 28 bytes):</li>
- <ul>
- <li> <b>source mote ID</b> (2 bytes)</li>
- <li> <b>sample counter</b> (2 bytes)</li>
- </ul>
-</ul>
-So we can interpret the data packet as follows:
-<table hspace="0" cellpadding="0" cellspacing="10" border="0">
- <tbody>
- <tr bgcolor="#d0d0d0">
- <td><b>dest addr</b></td>
- <td><b>src addr</b></td>
- <td><b>msg len</b></td>
- <td><b>groupID</b></td>
- <td><b>handlerID</b></td>
- <td><b>hop addr</b></td>
- <td><b>counter</b></td>
- </tr> <tr>
- <td bgcolor="#d0d0ff">ff ff</td>
- <td bgcolor="#d0d0ff">00 00</td>
- <td bgcolor="#d0d0ff">04</td>
- <td bgcolor="#d0d0ff">22</td>
- <td bgcolor="#d0d0ff">06</td>
- <td bgcolor="#d0ffd0">00 02</td>
- <td bgcolor="#d0ffd0">00 0B</td>
- </tr>
- </tbody>
-</table>
-
-<p>The hop address depends on what mote ID you installed your
-BlinkToRadio application with. The default (if you do not specify
-and ID) is <code>00 01</code>.
-Note that the data is sent by the mote in <i>big-endian</i>
-format; for example, <code>01 02</code> means 258 (256*1 + 2).
-This format is independent of the endian-ness of the processor,
-because the packet format is an <code>nx_struct</code>, which is
-a network format, that is, big-endian and byte-aligned. Using
-<code>nx_struct</code> (rather than a standard C <code>struct</code>)
-for a message payload ensures that it will work across platforms.</p>
-
-<p>TinyOS serial stacks do not fill in the source address as the
-address of the sending mote. The assumption is that the serial connection
-can identify the node, and setting the source address prevents
-applications such as BaseStation from working properly. This is
-because BaseStation just forwards radio packets to the serial port:
-it needs to fill in the <i>radio source</i> address as the source
-address of the serial packet.</p>
-<p>As you watch the packets scroll by, you should see the counter
-field increase as the BlinkToRadio app increments its counter.</p>
-
-<h1>MIG: generating packet objects</h1>
-
-<p>The <tt>Listen</tt> program is the most basic way of communicating
-with the mote; it just prints binary packets to the screen. Obviously
-it is not easy to visualize the sensor data
-using this program. What we'd really like is a better way of retrieving
-and observing data coming from the sensor network. Of course, exactly
-what data to display and how to visualize it can be very application
-specific. For this reason, TinyOS only
-has a few applications for visualizing simple
-sensor data (in the next lesson, you'll use the Oscilloscope application),
-but it provides support for building new visualization or logging systems.
-</p>
-
-<p>One problem with Listen is that it just dumps binary data: a user has
-to be able to read the bytes and parse them into a given packet format.
-The TinyOS toolchain makes this process easier by providing tools for
-automatically generating message objects from packet descriptions.
-Rather than parse packet formats manually, you can use the <code>mig</code>
-(Message Interface Generator) tool to build a Java, Python, or C interface
-to the message structure. Given a sequence of bytes, the MIG-generated
-code will automatically parse each of the fields in the packet, and it
-provides a set of standard accessors and mutators for printing out
-received packets or generating new ones.</p>
-
-<p>The mig tool takes three basic arguments: what programming language
-to generate code for (Java, Python, or C), which file in which to find
-the structure, and the name of the structure. The tool also takes standard
-C options, such as -I for includes and -D for defines. The TestSerial
-application, for example, uses mig so that it can easily create
-and parse the packets over the serial port. If you go back to TestSerial
-and type <code>make clean;make</code>, you should see this:</p>
-
-<pre>
-rm -rf build *.class TestSerialMsg.java
-rm -rf _TOSSIMmodule.so TOSSIM.pyc TOSSIM.py
-mkdir -p build/telosb
-mig java -target=telosb -I%T/lib/oski -java-classname=TestSerialMsg TestSerial.h TestSerialMsg -o TestSerialMsg.java
-javac *.java
- compiling TestSerialAppC to a telosb binary
-ncc -o build/telosb/main.exe -Os -O -mdisable-hwmul -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x66 -Wnesc-all -DCC2420_DEF_CHANNEL=19 -target=telosb -fnesc-cfile=build/telosb/app.c -board= -I%T/lib/oski TestSerialAppC.nc -lm
- compiled TestSerialAppC to build/telosb/main.exe
- 6300 bytes in ROM
- 281 bytes in RAM
-msp430-objcopy --output-target=ihex build/telosb/main.exe build/telosb/main.ihex
- writing TOS image
-</pre>
-
-<p>Before building the TinyOS application, the Makefile has a rule
-for generating <code>TestSerialMsg.java</code>. It then compiles
-TestSerialMsg.java as well as TestSerial.java, and finally
-compiles the TinyOS application. Looking at the Makefile, we can see
-that it has a few more rules than the one for BlinkToRadio:</p>
-
-<pre>
-COMPONENT=TestSerialAppC
-BUILD_EXTRA_DEPS += TestSerial.class
-CLEAN_EXTRA = *.class TestSerialMsg.java
-
-TestSerial.class: $(wildcard *.java) TestSerialMsg.java
- javac *.java
-
-TestSerialMsg.java:
- mig java -target=null -java-classname=TestSerialMsg TestSerial.h TestSerialMsg -o $@
-
-include $(MAKERULES)
-</pre>
-
-<p>The <code>BUILD_EXTRA_DEPS</code> line tells the TinyOS make system
-that the TinyOS application has additional dependencies that must
-be satisfied before it can be built. The Makefile tells the make system
-that <code>TestSerial.class</code>, the Java application that we ran
-to test serial communication. The <code>CLEAN_EXTRA</code> line tells
-the make system extra things that need to be done when a user types
-<code>make clean</code> to clean up.</p>
-
-<p>The <code>BUILD_EXTRA_DEPS</code> line tells make to compile
-TestSerial.class before the application; the line</p>
-
-<pre>
-TestSerial.class: $(wildcard *.java) TestSerialMsg.java
- javac *.java
-</pre>
-
-<p>tells it that TestSerial.class depends on all of the .java files
-in the directory as well as TestSerialMsg.java. Once all of these
-dependencies are resolved, the make system will call <code>javac
-*.java</code>, which creates TestSerial.class. The final line,</p>
-
-<pre>
-TestSerialMsg.java:
- mig java -target=null -java-classname=TestSerialMsg TestSerial.h TestSerialMsg -o $@
-</pre>
-
-<p>tells the make system how to create TestSerialMsg.java, the
-Java class representing the packet sent between the mote and PC.
-Because TestSerialMsg.java is a dependency for TestSerial.class,
-make will create it if it is needed. To create TestSerialMsg.java,
-the Makefile invokes the mig tool. Let's step through the parameters
-one by one:</p>
-
-<table>
-<tr> <td>mig</td> <td width=60></td> <td>Invoke mig</td> </tr>
-<tr> <td>java</td> <td></td> <td>Build a Java class</td> </tr>
-<tr> <td>-target=null</td> <td></td> <td>For the <code>null</code>platform</td></tr>
-<tr> <td>-java-classname=TestSerialMsg</td><td></td> <td>Name the Java class TestSerialMsg</td> </tr>
-<tr> <td>TestSerial.h</td> <td></td> <td>The structure is in TestSerial.h</td> </tr>
-<tr> <td>TestSerialMsg</td> <td></td> <td>The structure is named TestSerialMsg</td></tr>
-<tr> <td>-o $@</td> <td></td> <td>Write the file to $@, which is TestSerialMsg.java</tr></tr>
-</table>
-
-<p>The <code>null</code> platform is a special platform which is convenient to use
-as the target when using <code>mig</code>. It includes all the standard
-system components, but with dummy do-nothing implementations. Building an
-application for the <code>null</code> platform is useless, but it allows
-<code>mig</code> to extract the layout of packets.
-
-<p>Let's build a Java packet object for BlinkToRadio. Open the Makefile for
-BlinkToRadio and add a dependency:</p>
-
-<pre>
-BUILD_EXTRA_DEPS=BlinkToRadioMsg.class
-</pre>
-
-<p>Then add a step which explains how to compile a .java to a .class:</p>
-
-<pre>
-BlinkToRadioMsg.class: BlinkToRadioMsg.java
- javac BlinkToRadioMsg.java
-</pre>
-
-<p><b>Note that there must be a tab before javac, and not just spaces.</b>
-Finally, add the line which explains how to create BlinkToRadioMsg.java:</p>
-
-<pre>
-BlinkToRadioMsg.java:
- mig java -target=null -java-classname=BlinkToRadioMsg BlinkToRadio.h BlinkToRadioMsg -o $@
-</pre>
-
-<p>As with javac, there must be a tab (not spaces) before mig.
-Now, when you type <code>make</code> in <code>BlinkToRadio/</code>,
-the make system will compile BlinkToRadioMsg.class, a Java class
-that parses a binary packet into message fields that can be accessed
-through methods.</p>
-
-<p>There is one more step, however. When you compiled, you probably saw this warning:
-
-<pre>
-warning: Cannot determine AM type for BlinkToRadioMsg
- (Looking for definition of AM_BLINKTORADIOMSG)
-</pre>
-
-<p>One part of the TinyOS communication toolchain requires being able to
-figure out which AM types correspond to what kinds of packets.
-To determine this, for a packet type named X, mig looks for a constant
-of the form <code>AM_X</code>. The warning is because we defined our
-AM type as AM_BLINKTORADIO, but mig wants AM_BLINKTORADIOMSG. Modify
-BlinkToRadio.h so that it defines the latter. You'll also need to
-update BlinkToRadioAppC.nc so that the arguments to AMSenderC
-and AMReceiverC use it. Recompile the application, and you should
-see no warning. Install it on a mote.</p>
-
-<p>Now that we have a Java message class, we can use it to
-print out the messages we see from the BaseStation. With
-BaseStation plugged into the serial port and BlinkToRadio
-running on another mote, from the BlinkToRadio directory
-type</p>
-
-<pre>
-java net.tinyos.tools.MsgReader BlinkToRadioMsg
-</pre>
-
-<p>Now, when the BaseStation sends a packet to the serial
-port, MsgReader reads it, looks at its AM type, and if
-it matches the AM type of one of the Java message classes
-passed at the command line, it prints out the packet. You
-should see output like this:</p>
-
-<pre>
-1152232617609: Message <BlinkToRadioMsg>
- [nodeid=0x2]
- [counter=0x1049]
-
-1152232617609: Message <BlinkToRadioMsg>
- [nodeid=0x2]
- [counter=0x104a]
-
-1152232617609: Message <BlinkToRadioMsg>
- [nodeid=0x2]
- [counter=0x104b]
-
-1152232617621: Message <BlinkToRadioMsg>
- [nodeid=0x2]
- [counter=0x104c]
-</pre>
-
-<h1>SerialForwarder and other packet sources</h1>
-
-<p>One problem with directly using the serial port is that
-only one PC program can interact with the mote. Additionally,
-it requires you to run the application on the PC which is
-physically connected to the mote. The SerialForwarder tool
-is a simple way to remove both of these limitations.</p>
-
-<p>Most generally, the <tt>SerialForwarder</tt> program
-opens a packet source and lets many applications connect
-to it over a TCP/IP stream in order to use that source.
-For example, you can run a SerialForwarder whose packet
-source is the serial port; instead of connecting to the
-serial port directly, applications connect to the
-SerialForwarder, which acts as a proxy to read and write
-packets. Since applications connect to SerialForwarder
-over TCP/IP, applications can connect over the Internet.</p>
-
-<p>SerialForwarder is the second kind of packet source.
-A SerialForwarder source has this syntax:</p>
-
-<pre>
-sf@HOST:PORT
-</pre>
-
-<p>HOST and PORT are optional: they default to localhost (the
-local machine) and 9002. For example,</p>
-
-<pre>
-sf@dark.cs.berkeley.edu:1948
-</pre>
-
-<p>will connect to a SerialForwarder running on the computer
-dark.cs.berkeley.edu and port 1948.</p>
-
-<p>The first step is to run a SerialForwarder; since it
-takes one packet source and exports it as an sf source,
-it takes a packet source parameter just like the other
-tools we've used so far: you can pass a -comm parameter,
-use MOTECOM, or just rely on the default. Close your
-MsgReader application so that it no longer uses
-the serial port, and run a SerialForwarder:</p>
-
-<pre>
-java net.tinyos.sf.SerialForwarder
-</pre>
-
-<p>You should see a window like this pop up:
-
-<center>
-<p><img height="300" width="500" src="img/sf.gif"></p>
-</center>
-
-<p>Since SerialForwarder takes any packet source as its source, you
-can even string SerialForwaders along:</p>
-
-<pre>
-java net.tinyos.sf.SerialForwarder -port 9003 -comm sf@localhost:9002
-</pre>
-
-<p>This command opens a second SerialForwarder, whose source is the first
-SerialForwarder. You'll see that the client count of the first one has
-increased to one. It's rare that you'd ever want to do this, but it
-demonstrates that in the message support libraries you can
-use a variety of packet sources.</p>
-
-<p>Close the second SerialForwarder (the one listening on port 9003).
-Run MsgReader again, but this time tell it to connect to your
-SerialForwarder:</p>
-
-<pre>
-java net.tinyos.tools.MsgReader -comm sf@localhost:9002 BlinkToRadioMsg
-</pre>
-
-<p>You will see the client count increment, and MsgReader will start
-printing out packets.</p>
-
-<h2>Packet Sources</h2>
-
-<p>In addition to serial ports and SerialForwarders, the TinyOS
-messaging library supports a third packet source, motes which
-are connected to an ethernet port through a Crossbow MIB 600
-ethernet board. This is the full
-set of packet sources:
-
-<br>
-<center>
-<table>
-<tr>
-<td><b>Syntax</b></td>
-<td width=100></td>
-<td><b>Source</b></td>
-</tr>
-<tr>
-<td>serial@PORT:SPEED</td>
-<td></td>
-<td>Serial ports</td>
-</tr>
-<tr>
-<td>sf@HOST:PORT</td>
-<td></td>
-<td>SerialForwarder, TMote Connect</td>
-</tr>
-<tr>
-<td>network@HOST:PORT</td>
-<td></td>
-<td>MIB 600</td>
-</tr>
-</table>
-</center>
-
-<p>In the <code>network</code> packet source, the default MIB 600 port
-is 10002. The Moteiv TMote Connect appliance is a SerialForwarder
-packet source.</p>
-
-<h2>The tool side</h2>
-
-<p>Code for the Java messaging toolchain lives in two java packages:
-<code>net.tinyos.message</code> and <code>net.tinyos.packet</code>.
-The <code>packet</code> package contains all of the code for
-packet sources and their protocols: it is what reads and writes
-bytes. The <code>message</code> package is what turns streams of
-bytes into meaningful messages and provides packet source independent
-classes for communicating with motes.</p>
-
-<p>The key class for sending and receiving packets is <code>MoteIF</code>.
-It has methods for registering packet listeners (callbacks when a packet
-arrives) and sending packets. The tools <code>MsgReader</code>,
-<code>Listen</code>, and <code>Send</code> are good places to start
-to learn how to get Java applications to communicate with motes.</p>
-
-<p>There is also support for python and C.</p>
-
-<h1>Sending a packet to the serial port in TinyOS</h1>
-
-<p>Sending an AM packet to the serial port in TinyOS is very
-much like sending it to the radio. A component uses the AMSend
-interface, calls <code>AMSend.send</code>, and handles
-<code>AMSend.sendDone</code>. The serial stack will send
-it over the serial port regardless of the AM address specified.</p>
-
-<p>The TinyOS serial stack follows the same programming model as the radio
-stack. There is a <code>SerialActiveMessageC</code> for turning
-the stack on and off (mote processors often cannot enter their
-lowest power state while the serial stack is on), and generic
-components for sending and receiving packets. As the serial
-stack is a dedicated link, however, it does not provide a
-snooping interface, and it does not filter based on the destination
-address of the packet. These are the serial communication components
-and their radio analogues:</p>
-
-<center>
-<table cellspacing=4 cellpadding=2>
- <tr align=center><td bgcolor="#d0d0d0"><b>Serial</b></td><td width=10></td><td bgcolor="#d0d0ff"><b>Radio</b></td></tr>
- <tr>
- <td bgcolor="#d0d0d0">SerialActiveMessageC</td>
- <td></td>
- <td bgcolor="#d0d0ff">ActiveMessageC</td>
- </tr>
- <tr>
- <td bgcolor="#d0d0d0">SerialAMSenderC</td>
- <td></td>
- <td bgcolor="#d0d0ff">AMSenderC</td>
- </tr>
- <tr>
- <td bgcolor="#d0d0d0">SerialAMReceiverC</td>
- <td></td>
- <td bgcolor="#d0d0ff">AMReceiverC</td>
- </tr>
-</table>
-</center>
-
-<p>Because serial AM communication has the same interfaces as radio
-AM communication, you can in most situations use them interchangably.
-For example, to make BlinkToRadio send packets to the serial port
-rather than the radio, all you have to do is change the
-BlinkToRadioAppC configuration:</p>
-
-<center>
-<table>
- <tr><td><b>Radio</b></td><td width=10></td><td><b>Serial</b></td></tr>
- <tr><td>
-<pre>
- components ActiveMessageC;
- components new AMSenderC(AM_BLINKTORADIOMSG);
-
- BlinkToRadioC.AMSend -> AMSenderC;
- BlinkToRadioC.AMControl -> ActiveMessageC;
-</pre>
-</td>
-<td></td>
-<td>
-<pre>
- components SerialActiveMessageC;
- components new SerialAMSenderC(AM_BLINKTORADIOMSG);
-
- BlinkToRadioC.AMSend -> SerialAMSenderC;
- BlinkToRadioC.AMControl -> SerialActiveMessageC;
-</pre>
-</td>
-</tr>
-</table>
-</center>
-</table>
-<br>
-<hr>
-
-<p>Now, rather than have BlinkToRadio send packets which a BaseStation
-recieves and forwards to the serial port, the application will
-send them directly to a serial port. Connect a MsgReader to test
-that this is happening. Note that the binary code and data size
-has changed significantly, as nesC has included the serial stack
-rather than the radio stack.</p>
-
-<h1>Related Documentation</h1>
-
-<ul>
-<li> <a name="fn1"><a href="../tep113.html">TEP 113: Serial Communication</a></a>
-<li> <code>mig</code> man page
-<li> <code>ncg</code> man page
-<li> javadoc documentation for the net.tinyos.packet and net.tinyos.message packages
-</ul>
-
-<center>
-<p>< <b><a href="lesson3.html">Previous Lesson</a></b> | <b><a
- href="index.html">Top</a></b> | <b><a href="lesson5.html">Next Lesson </a> ></b>
-</center>
-
-
-<h1>CLASSPATH and Java classes</h1>
-
-<p>Note that the CLASSPATH variable points to <tt>tinyos.jar</tt>. This
-means that when Java looks for classes to load, it looks in tinyos.jar rather
-than the Java directories in <tt>support/sdk/java</tt>. Therefore,
-if you change and recompile the Java classes, you will not see the changes,
-as Java will only look at the jar file. To regenerate the
-jar from the Java code, go to <tt>support/sdk/java</tt> and type
-<tt>make tinyos.jar</tt>.
+<p>Sorry, your browser does not support frames. Please <a href="http://docs.tinyos.net/index.php/Mote-PC_serial_communication_and_SerialForwarder" target="_top">go here</a>.</p>
</body>
-</html>
-
+</noframes>
+</frameset>
+</html>
\ No newline at end of file
projects / tinyos-2.x.git / blobdiff