getting started with tinyos - tinyos documentation wiki.htm

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

Reset device...
Reset and release device...
</PRE><A name=Installing_on_an_IntelMote2></A>
<H2><SPAN class=mw-headline>Installing on an IntelMote2</SPAN></H2><A 
name=Installation_options></A>
<H1><SPAN class=mw-headline>Installation options</SPAN></H1>
<P>You can now test the program by unplugging the mote from the programming 
board and turning on the power switch (if it's not already on). With any luck 
the three LEDs should be displaying a counter incrementing at 4Hz. </P>
<P>The <TT>reinstall</TT> command told the make system to install the currently 
compiled binary: it skips the compilation process. Type <TT>make clean</TT> to 
clean up all of the compiled binary files, then type, e.g., <TT>make telosb 
install</TT> This will recompile Blink and install it on one action. </P>
<P>Networking almost always requires motes to have unique identifiers. When you 
compile a TinyOS application, it has a default unique identifier of 1. To give a 
node a different identifier, you can specify it at installation. For example, if 
you type <TT>make telosb install.5</TT> or <TT>make telosb reinstall.5</TT>, you 
will install the application on a node and give it 5 as its identifier. </P>
<P>For more information on the build system, please see <A 
title="TinyOS Toolchain" 
href="http://docs.tinyos.net/index.php/TinyOS_Toolchain">Lesson 13</A>. </P><A 
name=Components_and_Interfaces></A>
<H1><SPAN class=mw-headline>Components and Interfaces</SPAN></H1>
<P>Now that you've installed Blink, let's look at how it works. Blink, like all 
TinyOS code, is written in nesC, which is C with some additional language 
features for components and concurrency. </P>
<P>A nesC application consists of one or more <I>components</I> assembled, or 
<I>wired</I>, to form an application executable. Components define two scopes: 
one for their specification which contains the names of their <I>interfaces</I>, 
and a second scope for their implementation. A component <I>provides</I> and 
<I>uses</I> interfaces. The provided interfaces are intended to represent the 
functionality that the component provides to its user in its specification; the 
used interfaces represent the functionality the component needs to perform its 
job in its implementation. </P>
<P>Interfaces are bidirectional: they specify a set of <I>commands</I>, which 
are functions to be implemented by the interface's provider, and a set of 
<I>events</I>, which are functions to be implemented by the interface's user. 
For a component to call the commands in an interface, it must implement the 
events of that interface. A single component may use or provide multiple 
interfaces and multiple instances of the same interface. </P>
<P>The set of interfaces which a component provides together with the set of 
interfaces that a component uses is considered that component's 
<I>signature</I>. </P><A name=Configurations_and_Modules></A>
<H2><SPAN class=mw-headline>Configurations and Modules</SPAN></H2>
<P>There are two types of components in nesC: <I>modules</I> and 
<I>configurations</I>. Modules provide the implementations of one or more 
interfaces. Configurations are used to assemble other components together, 
connecting interfaces used by components to interfaces provided by others. Every 
nesC application is described by a top-level configuration that wires together 
the components inside. </P><A name=Blink:_An_Example_Application></A>
<H1><SPAN class=mw-headline>Blink: An Example Application</SPAN></H1>
<P>Let's look at a concrete example: <TT><A class="external text" 
title=http://www.tinyos.net/tinyos-2.x/apps/Blink 
href="http://www.tinyos.net/tinyos-2.x/apps/Blink" rel=nofollow>Blink</A></TT> 
in the TinyOS tree. As you saw, this application displays a counter on the three 
mote LEDs. In actuality, it simply causes the LED0 to to turn on and off at 
.25Hz, LED1 to turn on and off at .5Hz, and LED2 to turn on and off at 1Hz. The 
effect is as if the three LEDs were displaying a binary count of one to seven 
every two seconds. </P>
<P>Blink is composed of two <B>components</B>: a <B>module</B>, called 
"<TT>BlinkC.nc</TT>", and a <B>configuration</B>, called 
"<TT>BlinkAppC.nc</TT>". Remember that all applications require a top-level 
configuration file, which is typically named after the application itself. In 
this case <TT>BlinkAppC.nc</TT> is the configuration for the Blink application 
and the source file that the nesC compiler uses to generate an executable file. 
<TT>BlinkC.nc</TT>, on the other hand, actually provides the 
<I>implementation</I> of the Blink application. As you might guess, 
<TT>BlinkAppC.nc</TT> is used to wire the <TT>BlinkC.nc</TT> module to other 
components that the Blink application requires. </P>
<P>The reason for the distinction between modules and configurations is to allow 
a system designer to build applications out of existing implementations. For 
example, a designer could provide a configuration that simply wires together one 
or more modules, none of which she actually designed. Likewise, another 
developer can provide a new set of library modules that can be used in a range 
of applications. </P>
<P>Sometimes (as is the case with <TT>BlinkAppC</TT> and <TT>BlinkC</TT>) you 
will have a configuration and a module that go together. When this is the case, 
the convention used in the TinyOS source tree is: </P>
<CENTER>
<TABLE cellSpacing=1 cellPadding=1 border=1>
  <TBODY>
  <TR>
    <TD>File Name </TD>
    <TD>File Type </TD></TR>
  <TR>
    <TD><TT>Foo.nc</TT> </TD>
    <TD>Interface </TD></TR>
  <TR>
    <TD><TT>Foo.h</TT> </TD>
    <TD>Header File </TD></TR>
  <TR>
    <TD><TT>FooC.nc </TT></TD>
    <TD>Public Module </TD></TR>
  <TR>
    <TD><TT>FooP.nc</TT> </TD>
    <TD>Private Module </TD></TR></TBODY></TABLE></CENTER>
<P>While you could name an application's implementation module and associated 
top-level configuration anything, to keep things simple we suggest that you 
adopt this convention in your own code. There are several other conventions used 
in TinyOS; <A class="external text" 
title=http://www.tinyos.net/tinyos-2.x/doc/html/tep3.html 
href="http://www.tinyos.net/tinyos-2.x/doc/html/tep3.html" rel=nofollow>TEP 
3</A> specifies the coding standards and best current practices. </P><A 
name=The_BlinkAppC.nc_Configuration></A>
<H1><SPAN class=mw-headline>The BlinkAppC.nc Configuration</SPAN></H1>
<P>The nesC compiler compiles a nesC application when given the file containing 
the top-level configuration. Typical TinyOS applications come with a standard 
Makefile that allows platform selection and invokes ncc with appropriate options 
on the application's top-level configuration. </P>
<P>Let's look at <TT>BlinkAppC.nc</TT>, the configuration for this application 
first: </P><PRE>configuration BlinkAppC {
}
implementation {
  components MainC, BlinkC, LedsC;
  components new TimerMilliC() as Timer0;
  components new TimerMilliC() as Timer1;
  components new TimerMilliC() as Timer2;

  BlinkC -&gt; MainC.Boot;
  BlinkC.Timer0 -&gt; Timer0;
  BlinkC.Timer1 -&gt; Timer1;
  BlinkC.Timer2 -&gt; Timer2;
  BlinkC.Leds -&gt; LedsC;
}
</PRE>
<P>The first thing to notice is the key word <TT>configuration</TT>, which 
indicates that this is a configuration file. The first two lines, </P><PRE>configuration BlinkAppC {
}
</PRE>
<P>simply state that this is a configuration called <TT>BlinkAppC</TT>. Within 
the empty braces here it is possible to specify <TT>uses</TT> and 
<TT>provides</TT> clauses, as with a module. This is important to keep in mind: 
a configuration can use and provide interfaces. Said another way, not all 
configurations are top-level applications. </P>
<P>The actual configuration is implemented within the pair of curly brackets 
following the key word <TT>implementation </TT>. The <TT>components</TT> lines 
specify the set of components that this configuration references. In this case 
those components are <TT>Main</TT>, <TT>BlinkC</TT>, <TT>LedsC</TT>, and three 
instances of a timer component called <TT>TimerMilliC</TT> which will be 
referenced as Timer0, Timer1, and Timer2 <SUP class=reference 
id=_ref-timermillic_footnote_0><A title="" 
href="http://docs.tinyos.net/index.php/Getting_Started_with_TinyOS#_note-timermillic_footnote">[1]</A></SUP>. 
This is accomplished via the <I>as</I> keyword which is simply an alias <SUP 
class=reference id=_ref-hint10_0><A title="" 
href="http://docs.tinyos.net/index.php/Getting_Started_with_TinyOS#_note-hint10">[2]</A></SUP>. 
</P>
<P>As we continue reviewing the BlinkAppC application, keep in mind that the 
BlinkAppC component is not the same as the BlinkC component. Rather, the 
BlinkAppC component is composed of the BlinkC component along with MainC, LedsC 
and the three timers. </P>
<P>The remainder of the BlinkAppC configuration consists of connecting 
interfaces used by components to interfaces provided by others. The 
<TT>MainC.Boot</TT> and <TT>MainC.SoftwareInit</TT> interfaces are part of 
TinyOS's boot sequence and will be covered in detail in Lesson 3. Suffice it to 
say that these wirings enable the LEDs and Timers to be initialized. </P>
<P>The last four lines wire interfaces that the BlinkC component <I>uses</I> to 
interfaces that the TimerMilliC and LedsC components <I>provide</I>. To fully 
understand the semantics of these wirings, it is helpful to look at the BlinkC 
module's definition and implementation. </P><A name=The_BlinkC.nc_Module></A>
<H1><SPAN class=mw-headline>The BlinkC.nc Module</SPAN></H1><PRE>module BlinkC {
  uses interface Timer&lt;TMilli&gt; as Timer0;
  uses interface Timer&lt;TMilli&gt; as Timer1;
  uses interface Timer&lt;TMilli&gt; as Timer2;
  uses interface Leds;
  uses interface Boot;
}
implementation
{
  // implementation code omitted
}
</PRE>
<P>The first part of the module code states that this is a module called 
<TT>BlinkC</TT>and declares the interfaces it provides and uses. The 
<TT>BlinkC</TT> module <B>uses</B> three instances of the interface 
<TT>Timer&lt;TMilli&gt;</TT> using the names Timer0, Timer1 and Timer2 (the 
<TT>&lt;TMilli&gt;</TT> syntax simply supplies the generic Timer interface with 
the required timer precision). Lastly, the <TT>BlinkC</TT> module also uses the 
Leds and Boot interfaces. This means that BlinkC may call any command declared 
in the interfaces it uses and must also implement any events declared in those 
interfaces. </P>
<P>After reviewing the interfaces used by the <TT>BlinkC</TT> component, the 
semantics of the last four lines in <TT>BlinkAppC.nc</TT> should become clearer. 
The line <TT>BlinkC.Timer0 -&gt; Timer0</TT> wires the three 
<TT>Timer&lt;TMilli&gt;</TT> interface used by <TT>BlinkC</TT> to the 
<TT>Timer&lt;TMilli&gt;</TT> interface provided the three <TT>TimerMilliC</TT> 
component. The <TT>BlinkC.Leds -&gt; LedsC</TT> line wires the <TT>Leds</TT> 
interface used by the <TT>BlinkC</TT> component to the <TT>Leds</TT> interface 
provided by the <TT>LedsC</TT> component. </P>
<P>nesC uses arrows to bind interfaces to one another. The right arrow 
(<TT>A-&gt;B</TT>) as "A wires to B". The left side of the arrow (A) is a user 
of the interface, while the right side of the arrow (B) is the provider. A full 
wiring is <TT>A.a-&gt;B.b</TT>, which means "interface a of component A wires to 
interface b of component B." Naming the interface is important when a component 
uses or provides multiple instances of the same interface. For example, BlinkC 
uses three instances of Timer: Timer0, Timer1 and Timer2. When a component only 
has one instance of an interface, you can elide the interface name. For example, 
returning to BlinkAppC: </P><PRE>apps/Blink/BlinkAppC.nc: 
configuration BlinkAppC {
}
implementation {
  components MainC, BlinkC, LedsC;
  components new TimerMilliC() as Timer0;
  components new TimerMilliC() as Timer1;
  components new TimerMilliC() as Timer2;

  BlinkC -&gt; MainC.Boot;
  BlinkC.Timer0 -&gt; Timer0;
  BlinkC.Timer1 -&gt; Timer1;
  BlinkC.Timer2 -&gt; Timer2;
  BlinkC.Leds -&gt; LedsC;
}
</PRE>
<P>The interface name Leds does not have to be included in LedsC: </P><PRE>  BlinkC.Leds -&gt; LedsC; // Same as BlinkC.Leds -&gt; LedsC.Leds
</PRE>
<P>Because BlinkC only uses one instance of the Leds interface, this line would 
also work: </P><PRE>  BlinkC -&gt; LedsC.Leds; // Same as BlinkC.Leds -&gt; LedsC.Leds
</PRE>
<P>As the TimerMilliC components each provide a single instance of Timer, it 
does not have to be included in the wirings: </P><PRE>  BlinkC.Timer0 -&gt; Timer0;
  BlinkC.Timer1 -&gt; Timer1;
  BlinkC.Timer2 -&gt; Timer2;
</PRE>
<P>However, as BlinkC has three instances of Timer, eliding the name on the user 
side would be a compile-time error, as the compiler would not know which 
instance of Timer was being wired: </P><PRE>  BlinkC -&gt; Timer0.Timer;  // Compile error!
</PRE>
<P>The direction of a wiring arrow is always from a user to a provider. If the 
provider is on the left side, you can also use a left arrow: </P><PRE>  Timer0 &lt;- BlinkC.Timer0; // Same as BlinkC.Timer0 -&gt; Timer0;
</PRE>
<P>For ease of reading, however, most wirings are left-to-right. </P><A 
name=Visualizing_a_Component_Graph></A>
<H1><SPAN class=mw-headline>Visualizing a Component Graph</SPAN></H1>
<P>Carefully engineered TinyOS systems often have many layers of configurations, 
each of which refines the abstraction in simple way, building something robust 
with very little executable code. Getting to the modules underneath -- or just 
navigating the layers -- with a text editor can be laborious. To aid in this 
process, TinyOS and nesC have a documentation feature called nesdoc, which 
generates documentation automatically from source code. In addition to comments, 
nesdoc displays the structure and composition of configurations. </P>
<P>To generate documentation for an application, type </P><PRE>  make <I>platform</I> docs
</PRE>
<P>You should see a long list of interfaces and components stream by. If you see 
the error message </P><PRE>sh: dot: command not found
</PRE>
<P>then you need to <A class="external text" 
title=http://www.graphviz.org/Download..php 
href="http://www.graphviz.org/Download..php" rel=nofollow>install graphviz</A>, 
which is the program that draws the component graphs. </P>
<P>Once you've generated the documentation, go to 
<TT>tinyos-2.x/doc/nesdoc</TT>. You should see a directory for your platform: 
open its <TT>index.html</TT>, and you'll see a list of the components and 
interfaces for which you've generated documentation. For example, if you