mote-mote radio communication - tinyos documentation wiki.htm

从官方网站上下载tinyos2.0的学习指南

  href="http://www.tinyos.net/tinyos-2.x/tos/system/AMSnoopingReceiverC.nc" 
  rel=nofollow>AMSnoopingReceiverC</A></CODE> - Provides <CODE>Receive</CODE>, 
  <CODE>Packet</CODE>, and <CODE>AMPacket</CODE>. 
  <LI><CODE><A class="external text" 
  title=http://www.tinyos.net/tinyos-2.x/tos/system/ActiveMessageAddressC.nc 
  href="http://www.tinyos.net/tinyos-2.x/tos/system/ActiveMessageAddressC.nc" 
  rel=nofollow>ActiveMessageAddressC</A></CODE> - Provides commands to get and 
  set the node's active message address. This interface is not for general use 
  and changing the a node's active message address can break the network stack, 
  so avoid using it unless you know what you are doing. </LI></UL><A 
name=Naming_Wrappers></A>
<H2><SPAN class=mw-headline>Naming Wrappers</SPAN></H2>
<P>Since TinyOS supports multiple platforms, each of which might have their own 
implementation of the radio drivers, an additional, platform-specific, naming 
wrapper called <CODE>ActiveMessageC</CODE> is used to bridge these interfaces to 
their underlying, platform-specific implementations. <CODE>ActiveMessageC</CODE> 
provides most of the communication interfaces presented above. Platform-specific 
versions of <CODE>ActiveMessageC</CODE>, as well the underlying implementations 
which may be shared by multiple platforms (e.g. Telos and MicaZ) include: </P>
<UL>
  <LI><CODE>ActiveMessageC</CODE> for the <A class="external text" 
  title=http://www.tinyos.net/tinyos-2.x/tos/platforms/eyesIFX/ActiveMessageC.nc 
  href="http://www.tinyos.net/tinyos-2.x/tos/platforms/eyesIFX/ActiveMessageC.nc" 
  rel=nofollow>eyesIFX</A> platform is implemented by <CODE><A 
  class="external text" 
  title=http://www.tinyos.net/tinyos-2.x/tos/chips/tda5250/Tda5250ActiveMessageC.nc 
  href="http://www.tinyos.net/tinyos-2.x/tos/chips/tda5250/Tda5250ActiveMessageC.nc" 
  rel=nofollow>Tda5250ActiveMessageC</A></CODE>. 
  <LI><CODE>ActiveMessageC</CODE> for the <A class="external text" 
  title=http://www.tinyos.net/tinyos-2.x/tos/platforms/intelmote2/ActiveMessageC.nc 
  href="http://www.tinyos.net/tinyos-2.x/tos/platforms/intelmote2/ActiveMessageC.nc" 
  rel=nofollow>intelmote2</A>, <A class="external text" 
  title=http://www.tinyos.net/tinyos-2.x/tos/platforms/micaz/ActiveMessageC.nc 
  href="http://www.tinyos.net/tinyos-2.x/tos/platforms/micaz/ActiveMessageC.nc" 
  rel=nofollow>micaz</A>, <A class="external text" 
  title=http://www.tinyos.net/tinyos-2.x/tos/platforms/telosa/ActiveMessageC.nc 
  href="http://www.tinyos.net/tinyos-2.x/tos/platforms/telosa/ActiveMessageC.nc" 
  rel=nofollow>telosa</A>, and <A class="external text" 
  title=http://www.tinyos.net/tinyos-2.x/tos/platforms/telosa/ActiveMessageC.nc 
  href="http://www.tinyos.net/tinyos-2.x/tos/platforms/telosa/ActiveMessageC.nc" 
  rel=nofollow>telosb</A> are all implemented by <CODE><A class="external text" 
  title=http://www.tinyos.net/tinyos-2.x/tos/chips/cc2420/CC2420ActiveMessageC.nc 
  href="http://www.tinyos.net/tinyos-2.x/tos/chips/cc2420/CC2420ActiveMessageC.nc" 
  rel=nofollow>CC2420ActiveMessageC</A></CODE>. 
  <LI><CODE>ActiveMessageC</CODE> for the <A class="external text" 
  title=http://www.tinyos.net/tinyos-2.x/tos/platforms/mica2/ActiveMessageC.nc 
  href="http://www.tinyos.net/tinyos-2.x/tos/platforms/mica2/ActiveMessageC.nc" 
  rel=nofollow>mica2</A> platform is implemented by <CODE><A 
  class="external text" 
  title=http://www.tinyos.net/tinyos-2.x/tos/chips/cc1000/CC1000ActiveMessageC.nc 
  href="http://www.tinyos.net/tinyos-2.x/tos/chips/cc1000/CC1000ActiveMessageC.nc" 
  rel=nofollow>CC1000ActiveMessageC</A></CODE>. </LI></UL><A 
name=The_TinyOS_2.0_Message_Buffer></A>
<H1><SPAN class=mw-headline>The TinyOS 2.0 Message Buffer</SPAN></H1>
<P>TinyOS 2.0 introduces a new message buffer abstraction called 
<CODE>message_t</CODE>. If you are familiar with earlier versions of TinyOS, you 
need to know that <CODE>message_t</CODE> replaces <CODE>TOS_Msg</CODE>. The 
<CODE>message_t</CODE> structure is defined in <CODE><A class="external text" 
title=http://www.tinyos.net/tinyos-2.x/tos/types/message.h 
href="http://www.tinyos.net/tinyos-2.x/tos/types/message.h" 
rel=nofollow>tos/types/message.h</A></CODE>. </P><PRE>typedef nx_struct message_t {
  nx_uint8_t header[sizeof(message_header_t)];
  nx_uint8_t data[TOSH_DATA_LENGTH];
  nx_uint8_t footer[sizeof(message_header_t)];
  nx_uint8_t metadata[sizeof(message_metadata_t)];
} message_t;
</PRE>
<P><B>Note: The header, footer, and metadata fields are all opaque and must not 
be accessed directly. It is important to access the <CODE>message_t</CODE> 
fields only through <CODE>Packet</CODE>, <CODE>AMPacket</CODE>, and other such 
interfaces, as will be demonstrated in this tutorial.</B> The rationale for this 
approach is that it allows the data (payload) to be kept at a fixed offset, 
avoiding a copy when a message is passed between two link layers. See Section 3 
in TEP 111<SUP class=reference id=_ref-fn1_1><A title="" 
href="http://docs.tinyos.net/index.php/Mote-mote_radio_communication#_note-fn1">[1]</A></SUP> 
for more details. </P><A name=Sending_a_Message_over_the_Radio></A>
<H1><SPAN class=mw-headline>Sending a Message over the Radio</SPAN></H1>
<P>We will now create a simple application that increments a counter, displays 
the counter's three least significant bits on the three LEDs, and sends a 
message with the counter value over the radio. Our implementation will use a 
single timer and a counter, in a way similar to the <CODE>BlinkSingle</CODE> 
example from <A title="Modules and the TinyOS Execution Model" 
href="http://docs.tinyos.net/index.php/Modules_and_the_TinyOS_Execution_Model">lesson 
2</A>. </P><A name=Reimplementing_Blink></A>
<H2><SPAN class=mw-headline>Reimplementing Blink</SPAN></H2>
<P>As a first step, we can reimplement <CODE>Blink</CODE> using a single timer 
and counter. Create a new directory in <TT>apps</TT> named 
<TT>BlinkToRadio</TT>: </P><PRE>$ cd tinyos-2.x/apps
$ mkdir BlinkToRadio
</PRE>
<P>Inside this directory, create a file <CODE>BlinkToRadioC.nc</CODE>, which has 
this code: </P><PRE> #include &lt;Timer.h&gt;
 #include "BlinkToRadio.h"
 
 module BlinkToRadioC {
   uses interface Boot;
   uses interface Leds;
   uses interface Timer&lt;TMilli&gt; as Timer0;
 }
 implementation {
   uint16_t counter = 0;
 
   event void Boot.booted() {
     call Timer0.startPeriodic(TIMER_PERIOD_MILLI);
   }
 
   event void Timer0.fired() {
     counter++;
     call Leds.set(counter);
   }
 }
 
 
</PRE>
<P>Let's look at a few specific lines in this program. First, notice the C 
preprocessor <CODE>include</CODE> directive on the first line. This directive 
tells the compiler to simply replace the directive with the entire contents of 
<CODE>Timer.h</CODE>. The compiler looks for <CODE>Timer.h</CODE> in the 
<I>standard</I> places. In this case, standard means the TinyOS system 
directories that are located in <CODE>tos</CODE> or its subdirectories. It is 
possible to tell the compiler to look beyond these standard directories by using 
the <CODE>-I</CODE> flag in the Makefile, for example, as is common when 
including contributed libraries located in <CODE>contrib</CODE> directory tree. 
</P>
<P>The second line of this program is also an <CODE>include</CODE> directive, 
but note that it uses quotes around the filename rather than angle brackets. The 
quotes tell the preprocessor to look in the current directory before searching 
through the standard directories for the particular file. In this case, the 
<CODE>BlinkToRadio.h</CODE> file is located in the same directory and defines 
some constants that are used in this program. We will take a look at 
<CODE>BlinkToRadio.h</CODE> in just a bit. </P>
<P>Next, the call to <CODE>Leds.set</CODE> directly sets the three LEDs to the 
three low-order bits of the counter. </P>
<P>Finally, note the <CODE>call Timer0.startPeriodic(TIMER_PERIOD_MILLI)</CODE> 
line in the <CODE>Boot.booted</CODE> function. The value of 
<CODE>TIMER_PERIOD_MILLI</CODE> is defined in the <CODE>BlinkToRadio.h</CODE> 
header file: </P><PRE> #ifndef BLINKTORADIO_H
 #define BLINKTORADIO_H
 
 enum {
   TIMER_PERIOD_MILLI = 250
 };
 
 #endif
 
</PRE>
<P><CODE>BlinkToRadio.h</CODE> is a pretty standard header file but there are 
two things to note here. First, notice the use of the <CODE>ifndef</CODE>, 
<CODE>define</CODE>, and <CODE>endif</CODE> directives. These directives are 
used to ensure that the definitions in each header file is not included multiple 
times because the compiler would complain about multiply-defined objects. By 
convention, the literal used for these directives is an all-caps version of the 
filename with any periods converted to underscores. The other important thing to 
note is the use of an <CODE>enum</CODE> declaration for defining the constant 
<CODE>TIMER_PERIOD_MILLI</CODE>. Using <CODE>enum</CODE> for defining constants 
is preferred over using <CODE>define</CODE> because <CODE>enum</CODE> does not 
indiscriminantly replace every occurence of the <CODE>define</CODE>d literal, 
regardless of where it appears in the source. As a result, <CODE>enum</CODE>s 
provide better scoping as well. </P>
<P><CODE>BlinkToRadioC.nc</CODE> provides the <I>implementation</I> logic of the 
program and <CODE>BlinkToRadio.h</CODE> defines constants and/or data 
structures. A third file is needed to <I>wire</I> the interfaces that the 
implementation <CODE>uses</CODE> to the actual components which 
<CODE>provide</CODE> these interfaces. The <CODE>BlinkToRadioAppC.nc</CODE> 
provides the needed wiring: </P><PRE> #include &lt;Timer.h&gt;
 #include "BlinkToRadio.h"
 
 configuration BlinkToRadioAppC {
 }
 implementation {
   components MainC;
   components LedsC;
   components BlinkToRadioC as App;
   components new TimerMilliC() as Timer0;
 
   App.Boot -&gt; MainC;
   App.Leds -&gt; LedsC;
   App.Timer0 -&gt; Timer0;
 }
 
</PRE>
<P>The <CODE>BlinkToRadioAppC</CODE> should look familiar to you since it is 
essentially a subset of the <CODE>Blink</CODE> application/configuration from an 
earlier lesson. </P>
<P>These three files constitute all of the application code: the only other 
thing it needs is a Makefile. Create a file named <CODE>Makefile</CODE>. For an 
application as simple as this one, the Makefile is very short: </P><PRE>COMPONENT=BlinkToRadioAppC
include $(MAKERULES)
</PRE>
<P>The first line tells the TinyOS make system that the top-level application 
component is BlinkToRadioAppC. The second line loads in the TinyOS build system, 
which has all of the rules for building and installing on different platforms. 
</P><A name=Defining_a_Message_Structure></A>
<H2><SPAN class=mw-headline>Defining a Message Structure</SPAN></H2>
<P>Now that <CODE>Blink</CODE> has been reimplemented using a single timer and 
counter, we can now turn our attention to defining a message format to send data 
over the radio. Our message will send both the node id and the counter value 
over the radio. Rather than directly writing and reading the payload area of the 
<CODE>message_t</CODE> with this data, we will use a structure to hold them and 
then use structure assignment to copy the data into the message payload area. 
Using a structure allows reading and writing the message payload more 
conveniently when your message has multiple fields or multi-byte fields (like 
uint16_t or uint32_t) because you can avoid reading and writing bytes from/to 
the payload using indices and then shifting and adding (e.g. <CODE>uint16_t x = 
data[0] &lt;&lt; 8 + data[1]</CODE>). Even for a message with a single field, 
you should get used to using a structure because if you ever add more fields to 
your message or move any of the fields around, you will need to manually update 
all of the payload position indices if you read and write the payload at a byte 
level. Using structures is straightforward. To define a message structure with a 
<CODE>uint16_t</CODE> node id and a <CODE>uint16_t</CODE> counter in the 
payload, we add the following lines to <CODE>BlinkToRadio.h</CODE>, just before 
the <CODE>endif</CODE> directive: </P><PRE>typedef nx_struct BlinkToRadioMsg {
  nx_uint16_t nodeid;
  nx_uint16_t counter;
} BlinkToRadioMsg;
</PRE>
<P>If this code doesn't look even vaguely familiar, you should spend a few 
minutes reading up on C structures. If you are familiar with C structures, this 
syntax should look familar but the <CODE>nx_</CODE> prefix on the keywords 
<CODE>struct</CODE> and <CODE>uint16_t</CODE> should stand out. The 
<CODE>nx_</CODE> prefix is specific to the nesC language and signifies that the 
<CODE>struct</CODE> and <CODE>uint16_t</CODE> are <I>external types</I> <SUP 
class=reference id=_ref-fn3_0><A title="" 
href="http://docs.tinyos.net/index.php/Mote-mote_radio_communication#_note-fn3">[2]</A></SUP><SUP 
class=reference id=_ref-fn4_0><A title="" 
href="http://docs.tinyos.net/index.php/Mote-mote_radio_communication#_note-fn4">[3]</A></SUP>. 
External types have the same representation on all platforms. The nesC compiler 
generates code that transparently reorders access to <CODE>nx_</CODE> data types 
and eliminates the need to manually address endianness and alignment (extra 
padding in structs present on some platforms) issues. So what is endianness? 
Read on... </P>
<P>Different processors represent numbers in different ways in their memory: 
some processors use a "big endian" representation which means that the most 
significant byte of a multi-byte (e.g. 16- or 32-bit) number is located at a 
lower memory address than the least significant byte, while "little endian" 
stores data in exactly the opposite order. A problem arises when data is 
serialized and sent over the network because different processors will decode 
the same set of bytes in different ways, depending on their "endianness." The 
main difficulty endianness presents is that it requires operations to rearrange 
byte orders to match the network protocol specification or the processor 
architecture -- an annoying and error-prone process. The <CODE>htons</CODE>, 
<CODE>htonl</CODE>, <CODE>ntohs</CODE>, and <CODE>ntohl</CODE> calls used with 
the sockets API are an example of platform-specific calls that convert between 
network and host byte orders, but you have to remember to use them. The nesC 
programming language takes a different approach to the problem and defines 
<I>external types</I> which allow the programmer to avoid dealing with byte 
reordering. In particular, the <CODE>nx_</CODE> prefix on a type (e.g. 
<CODE>nx_uint16_t</CODE>) indicates the field is to serialized in big endian 
format. In contrast, the <CODE>nxle_</CODE> prefix signifies that the field is 
serialized in little endian format. </P><A name=Sending_a_Message></A>
<H2><SPAN class=mw-headline>Sending a Message</SPAN></H2>
<P>Now that we have defined a message type for our application, 
<CODE>BlinkToRadioMsg</CODE>, we will next see how to send the message over the 
radio. Before beginning, let's review the purpose of the application. We want a 
timer-driven system in which every firing of the timer results in (i) 
incrementing a counter, (ii) displaying the three lowest bits of the counter on 
the LEDs, and (iii) transmitting the node's id and counter value over the radio. 
To implement this program, we follow a number of simple steps, as described in 
the next paragraph. </P>