nido.tex

无线通信的主要编程软件,是无线通信工作人员的必备工具,关天相关教程我会在后续传上.

To run {\tt Blink} with one mote, type {\tt run 1} or {\tt r 1}.  {\tt
r} is the GDB command to run the current executable, and all values
after the {\tt r} are passed as arguments to the executable. Therefore
the {\tt 1} specifies the number of motes to simulate to \sim. MoteIDs
are assigned starting at 0.  In this current example the moteID of the
single mote being simulated is 0.

Upon hitting the breakpoint at {\tt fire}, to print the value of {\tt
BlinkM}'s {\tt state}, type \\{\tt print
BlinkM\$state[tos\_state.current\_node]} (or {\tt p} for {\tt
print}). {\tt p} is the print command in GDB. {\tt BlinkM} corresponds
to the component the field {\tt state} belongs to. Since the
application was compiled for the pc, it is necessary to specify which
mote's {\tt BlinkM\$state} to access, as {\tt
[tos\_state.current\_node]} following the field name does.

\section{Concurrency Model}

\sim captures the TinyOS event-driven concurrency model at interrupt and
task granularity. For a description of the TinyOS concurrency model,
refer to the TinyOS documentation. This document does not describe the
model, merely how \sim implements it.

\sim models each TinyOS interrupt as a simulation event. Each event is
associated with a specific mote. Simulator events run atomically with
respect to one another. Therefore, unlike on real hardware, interrupts
cannot pre-empt one another. After each simulator event executes, \sim
checks the task queue for any pending tasks, and executes all of them
in FIFO scheduling order. In \sim, interrrupts do not pre-empt tasks.
This method of task execution means that spinning tasks (e.g., tasks
that enqueue themselves in a spin-lock fashion) will cause \sim to
execute that task indefinitely. Using tasks in this way is contrary to
the event-driven TinyOS programming model.

Once a simulator event calls an interrupt handler, the handler
executes TinyOS code through commands and events.

\subsection{Sample Execution}

\begin{figure*}
\scriptsize
\centering
\begin{tabular}{ll}
Time (4MHz ticks) & Action \\ \hline
3987340 & Simulator event is dequeued and handled at time 3987340.\\
        & The clock interrupt handler is called, signaling the application Timer
 event.\\
        & \hspace{0.2in} {\it The application's Timer handler requests a reading
 from the ADC.}\\
        & The ADC component puts a simulator ADC event on the queue with timesta
mp 3987540.\\
        & The interrupt handler completes; the clock event re-enqueues itself fo
r the next tick.\\

3987540 & Simulator ADC event is dequeued and handled at time 3987540.\\
        & The ADC interrupt handler is called, signaling an ADC ready event with
 a sensor value.\\
        & \hspace{0.2in}{\it The application event handler takes the top three b
its and calls LEDs commands.}\\
        & The ADC interrupt handler completes.\\

7987340 & Simulator event is dequeued and handled at time 7987340.\\
        & The clock interrupt handler is called, signaling the application Timer
 event.\\
        & \ldots execution continues as above
\end{tabular}
\caption{Sample Execution}
\label{fig:exec}
\end{figure*}

Figure \ref{fig:exec} contains a sample execution that demonstrates
the workings of \sim. A simple program, {\tt SenseToLeds}, is running
on a single \mote. This program has a 1Hz timer that samples the light
sensor and displays the three high order bits of the reading on the
\mote LEDs. Since simulator time is kept in terms of a 4MHz clock, the
timer events are four million ticks apart, and the 50$\mu$s ADC
capture takes 200 ticks between request and interrupt. In Figure
\ref{fig:exec} \sim-specific
execution is shown in plain text, while unchanged TinyOS execution is
shown in italics. This sample execution shows how a small number of
\sim events results in the series of TinyOS events and commands
comprising an entire (albeit very simple) application.

\section{Internals}
\label{sec:internals}

Currently, \sim compiles by using alternative implementations of some
core system components (e.g. {\tt Main.nc}, {\tt HPLUART.nc}) and
incorporating a few extra files (e.g. {\tt event\_queue.c}).

The basic \sim structure definitions exist in {\tt
platform/pc/nido.h}. These include the global simulation state
(event queue, time, etc.) and individual node state. Hardware settings
that affect multiple components (such as the potentiometer setting)
currently must be modeled as global node state. {\tt nido.h} also
includes a few useful macros, such as {\tt NODE\_NUM} and {\tt
THIS\_NODE}; these should be used whenever possible, so minimal code
modifications will be necessary if the data representation
changes. 

{\tt Nido.nc} is where the \sim global state is defined. The {\tt
main()} function parses the command line options, initializes the
\sim global state, initializes the external communication
functionality (defined in {\tt external\_comm.c, PCRadio.h}), then
initializes the state of each of the simulated motes with {\tt call
StdControl.init()} and {\tt call StdControl.start()}. It then starts
executing a small loop that handles events and schedules tasks.

\subsection{\sim Architecture}

\sim replaces a small number of TinyOS components, the components
that handle interrupts and the {\tt Main} component. Interrupts are
modeled as simulatgor discrete events. Normally, the core TinyOS loop
that runs on motes is this:

\begin{verbatim}
while(1){
  TOSH_run_task();
}
\end{verbatim}

{\tt TOSH\_run\_task} runs tasks until the task queue is empty, at which
point it puts the CPU to sleep. An interrupt will wake the mote. If
the interrupt has caused a task to be scheduled, then that task will
be run. While that task is running, interrupts can be handled.

The core \sim loop is slightly different:

\begin{verbatim}
for (;;) {
  while(TOSH_run_next_task()) {}
  if (!queue_is_empty(&(tos_state.queue))) {	
    tos_state.tos_time =
       queue_peek_event_time(&(tos_state.queue));
    queue_handle_next_event(&(tos_state.queue));
}
\end{verbatim}


A notion of virtual time (stored as a 64-bit integer) is kept in the
simulator (stored in {\tt tos\_state.tos\_time}), and every event is
associated with a specific mote. Most events are emulations of
hardware interrupts. For example, when the clock in {\tt hpl.c} is
initialized to certain counter values, \sim's implementation
enqueues a clock interrupt event, whose handler calls the function
normally registered as the clock interrupt handler; from this point,
normal TinyOS code takes over (in terms of events being signaled,
etc.) In addition, the event enqueues another clock event for the
future, with its time (for the event queue) being the current time
plus the time between interrupts.

When compiling for \sim, the nesC compiler modifies code generation
for components such that fields declared in components result in
arrays of each field.  The maximum number of motes that can be
simulated at once is set at compile time by the size of this array;
the default value is 1000 and is specified in {\tt /apps/Makerules}
with the {\tt -fnesc-tossim-tosnodes=} flag. Since every event is
associated with a specific mote, the {\tt tos\_state.current\_node}
field is set just before the event handler function is called, so that
all modifications to component fields affect the correct mote's
state. Since all TinyOS tasks enqueued by an event are run to
completion before the next event is handled, tasks all execute with
the same node number and access the enqueuing mote's state.

\subsection{\sim Implementations}

To load a component, the nesC compiler uses a directory search
path. The default search path is:

\begin{itemize}
\item The application directory
\item {\tt tos/platform/xxx} (the selected platform)
\item {\tt tos/sensorboards/xxx} (the selected sensor board(s))
\item {\tt tos/system}
\item {\tt tos/lib}
\end{itemize}
Entries can be prepended to the search path with the {\tt -I} option
to the compiler. Using the {\tt -I} option therefore allows you to use
alternative implementations of components provided by TinyOS. For
example, one can write a \sim implementation of the microphone, and
put it in a separate directory, then include that directory with {\tt
-I}. This will cause the compiler to load the new \sim implementation
instead of the default one in the sensor board directory.

The component model of TinyOS means that \sim implementations are not
constrained to hardware abstractions. For example, \sim has an
implementation of the {\tt EEPROM} component, instead of the
lower-level hardware interface. Similarly, instead of using a
bit-level simulation, one can write a \sim implementation of {\tt
AMStandard}, for a packet-level simulation.

\subsection{RFM}

A \sim network model has the following structure:

\begin{verbatim}
typedef struct {
  void(*init)();
  void(*transmit)(int, char);   // int moteID, char bit
  void(*stop_transmit)(int);    // int moteID
  char(*hears)(int);            // char bit,   int moteID
  bool(*connected)(int,int);    // int moteID1, int moteID2
  link_t*(*neighbors)(int);      // int moteID
} rfm_model;
\end{verbatim}

{\tt init}, {\tt transmit}, {\tt stop\_transmit} and {\tt hears} are
straightforward; they're used to transmit and receive bits. The {\tt
connected} and {\tt neighbors} functions are used for some specific
low-level emulations of the radio channel during bit synchronization.

To give a feel for how the \sim RFM model works, we'll step through
the lossy model. The variable names have been changed to make it a bit
easier to explain.

In the lossy model, each mote has four variables: the value it
currently {\tt hears}, whether it is transmitting or not, and a
structure defining its network links. Each network link has a bit
error probability and stores the value currently being transmitted
along that link (after error).

Every time a mote {\tt transmit()}s (after error) a 1 to another mote,
that mote's {\tt hears} variable is incremented. When the transmitting
mote calls {\tt stop\_transmit()}, the variable is decremented. When
the receiver calls {\tt hears()}, it receives a 1 if the {\tt hears}
variable is non-zero. Signals are therefore modeled as a logical or.

When a mote transmits a zero or one with {\tt transmit()}, the
function scans through the list of network connections ({\tt
neighbors()}). For each link, it flips the bit with the probability
specified by that link, and stores the bit that's actually transmitted
(this is needed for when {\tt stop\_transmit()} is called, so {\tt
hears} can be decremented properly).

\bibliographystyle{unsrt}
\small

\begin{thebibliography}{99}
\bibitem{empirical}
\newblock{D.~Ganesan, B.~Krishnamachari, A.~Woo, D.~Culler, D.~Estrin, and  S.~Wicker.}
\newblock {An empirical study of epidemic algorithms in large scale multihop  wireless networks.}
\newblock {\url{citeseer.nj.nec.com/ganesan02empirical.html}, 2002.}
\newblock {Submitted for publication, February 2002.}

\bibitem{tossim}
\newblock{P.~Levis, N.~Lee, M.~Welsh, and D.~Culler.}
\newblock{TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications}
\newblock{To appear in {\it Proceedings of the First ACM Conference on Embedded Networked Sensor Systems (SenSys 2003)}.}

\end{thebibliography}

\end{document}