stack.tex

传感器网络中的嵌入式操作系统源代码

are the same, the {\tt crc} field of the {\tt TOS\_Msg} is set to 1 (if({\tt calc\_crc} ==
{\tt rec\_ptr->crc})\{ {\tt rec\_ptr->crc} = 1; ...\}). If not, {\tt rec\_ptr->crc} is set to
0.

If the received {\tt crc} and calculated CRC match, {\tt MicaHighSpeedRadioM}
checks if the address of the packet was either its own moteID or the
broadcast address. If so, it tells {\tt SpiByteFifoC} to send the ack
(0x55) and changes its state to {\tt ACK\_SEND\_STATE}. If not, a call to
{\tt SpiByteFifoC} send is not made.

After receiving the last decoded byte of the packet being sent, the
receiver will receive the first 0xff byte sent by the receiver during
the sender's {\tt SENDING\_STRENGTH\_PULSE} state. During this instance of
{\tt dataReady}, {\tt MicaHighSpeedRadio} will call {\tt SpiByteFifo.txMode}(), which
keeps {\tt SpiByteFifoC} active but changes the state of the hardware to transmit.

For the next five instances of {\tt dataReady}, either 0x00 or 0x55 is sent
over the wire: 0x00 if packet was corrupted or intended for a
different mote, 0x55 if the packet was received properly and addressed
to itself.

During the fifth instance of {\tt dataReady}, {\tt MicaHighSpeedRadioM}
deactivates {\tt SpiByteFifo} (call {\tt SpiByteFifo.idle}()), and posts a
{\tt packetReceived} task. The {\tt packetReceived} task sets the radio stack to
{\tt IDLE\_STATE}, signals to the AM layer that the packet was received, and
activates {\tt ChannelMonC} to search for a preamble/start symbol (call
{\tt ChannelMon.startSymbolSearch}). The purpose for this check, ``if(tmp !=
0) {\tt rec\_ptr} = tmp;'' in the {\tt packetReceived} task is because the AM layer
will return a {\tt TOS\_Msg} (tmp), but that {\tt TOS\_Msg} may be an application's buffer
and different than the buffer used to receive the packet. Therefore,
it is an established convention that the receive signal handler return
a free {\tt TOS\_Msg} for the radio stack to use for reception of another
packet when a packet was signalled upon reception. 

To summarize, the receiver's interaction with the radio in the
{\tt CntToRfm} example is as follows:
\begin{verbatim}
                                bytes received
                                -------------------
        addr    = 0xff          0x9b, 0x55, 0x55
                  0xff          0x9b, 0x55, 0x55
        type    = 0x4           0x52, 0xaa, 0x9a
        group   = 0x7d          0x48, 0x95, 0x59
        length  = 0x4           0x9b, 0x55, 0x55
        data    = 0x1           0x5b, 0xaa, 0x9a
                  0x0           0xa4, 0xaa, 0xaa
                  0x0           0xa4, 0xaa, 0xaa
                  0x0           0xa4, 0xaa, 0xaa
        crc     = 0xd9          0x58, 0x59, 0x69
                  0x2d          0x95, 0xa6, 0x59
        strength pulse          0xff

        ---radio now set to sending---
                                byte sent 0x55
                                byte sent 0x55
                                byte sent 0x55
                                byte sent 0x55
                                byte sent 0x55
        DONE
\end{verbatim}

\section*{Timing}
As discussed previously, there are two components that communicate
directly with radio hardware: {\tt SpiByteFifoC} and
{\tt ChannelMonC}. {\tt SpiByteFifoC} reads from the radio and is the only component to send to the
radio. It samples/outputs to the radio every 100 clock ticks (40kbps).  {\tt ChannelMonC} only reads from the radio, and this
occurs every 200 clock ticks (20kbps).

When the sender sends the preamble/start symbol, the following bytes
are sent over the wire at 40kbps (using {\tt SpiByteFifoC}).

{\tt start}[12] = \{0xf0, 0xf0, 0xf0, 0xff, 0x00, 0xff, 0x0f, 0x00, 0xff, 0x0f, 0x0f, 0x0f\};

{\tt ChannelMonC} monitors for packet reception by searching for the preamble and
start symbol. The following timing diagram illustrates the
transmission and reception of the preamble/start symbol.
\newpage
\small
\begin{verbatim}

Sender      1  1  1  1  0  0  0  0  1  1  1  1  0  0  0  0  1  1  1  1

Receiver     ^     ^     ^     ^     ^     ^     ^     ^     ^     ^            

            |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |   
            0              500            1000           1500
           (time in clock ticks)
__________________________________________________________________________

Sender      0  0  0  0  1  1  1  1  1  1  1  1  0  0  0  0  0  0  0  0

Receiver     ^     ^     ^     ^     ^     ^     ^     ^     ^     ^            

            |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |   
            2000           2500           3000           3500
__________________________________________________________________________

Sender      1  1  1  1  1  1  1  1  0  0  0  0  1  1  1  1  0  0  0  0

Receiver     ^     ^     ^*    ^     `     ^     `     ^     `     ^            

            |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |   
            4000           4500           5000           5500
__________________________________________________________________________

Sender      0  0  0  0  1  1  1  1  1  1  1  1  0  0  0  0  1  1  1  1

Receiver     `     ^     `     ^     `     ^     `     ^     `     ^            

            |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |   
            6000           6500           7000           7500
__________________________________________________________________________

Sender      0  0  0  0  1  1  1  1  0  0  0  0  1  1  1  1  \  \  \  \

Receiver     `     ^     `**   

            |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |   
            8000           8500           9000           9500

^ indicates when the Receiver received a bit using CM_search[0]
` indicates when the Receiver received a bit using CM_search[1]

The sender sends a bit once very 100 clock ticks.

\end{verbatim}
\normalsize
{\tt ChannelMonC} has an unsigned short {\tt CM\_search}[2] that it uses to shift
in bits once every 200 clock ticks. When {\tt ChannelMonC} is
in its {\tt IDLE\_STATE}, it shifts in bits into {\tt CM\_search}[0] only. Everytime a
bit is received ({\tt TOSH\_SIGNAL(SIG\_OUTPUT\_COMPARE2)}), it masks {\tt CM\_search}[0]
with 0x777 and checks to see if it is equal to 0x707. If so, it
changes its state to {\tt START\_SYMBOL\_SEARCH}, sets both {\tt CM\_search}[0] and
{\tt CM\_search}[1] to 0 and sets {\tt CM\_startSymBits} to 30. 
\\
\\preamble check:                               0111 0000 0111
\\preamble mask in bits:                        0111 0111 0111
\\
\\bits received up to :           110 0110 0110 0111 1000 0111
\\preamble detection
\\
As shown from the timing diagram above, the last bit received before
start symbol detection is the 1 bit {\tt ChannelMonC} samples right after
4400 clock ticks as indicated by a ``*''.

During start symbol detection, both {\tt CM\_search}[0] and {\tt
CM\_search}[1] are used. Since \\ {\tt
TOSH\_SIGNAL(SIG\_OUTPUT\_COMPARE2)} runs once every 200 clock ticks
and the start symbol sent by the sender is actually a 10kbps signal,
the bits received in two consecutive instances of \\ {\tt
TOSH\_SIGNAL(SIG\_OUTPUT\_COMPARE2)} go to separate buffers.  As shown
in the timing diagram above, where there is a ``\^'' the bit was
shifted into {\tt CM\_search}[0], and where there is a ```'' the bit
was shifted into {\tt CM\_search}[1].

The contents of {\tt CM\_search}[0] and {\tt CM\_search}[1] after preamble detection
are shown below:
\\
\\start\_symbol mask:                           0001 1111 1111
\\start\_symbol check:                          0001 0011 0101
\\
\\{\tt CM\_search}[1]:                            01 0011 0101 
\\{\tt CM\_search}[0]:                            10 1001 1010 
\\
In the timing diagram above, {\tt CM\_search}[1] will detect the start symbol before
{\tt CM\_search}[0]. The bit received, as marked by the ``**'' is the last
bit received by {\tt ChannelMonC}. Upon receiving this bit, {\tt ChannelMonC}
disables itself and signals {\tt startSymDetect} to {\tt MicaHighSpeedRadioM}.

The next timing issue that needs to be discuessed is the
synchronization/input capture the receiver of a packet performs after
detecting the preamble/start symbol. In essence, since the sender is
sending the packet at 40kbps and the receiver is receiving bits at
40kbps, it is crucial that they are in sync. Since start symbol
detection was performed at 10kbps, having the receiver know when to
start clocking in bits at 40kbps is critical. This is accomplished
through input capture. The receiver loops until a 1 bit is received,
and begins clocking in bits for the packet some offset from when the 1
bit was received.

In the timing diagram above, the first bit of the packet is sent at
9500 clock ticks, 100 after the last 1 bit sent at 9400 clock ticks. Seeing
that the last bit received for the start symbol occurs sometime
between 8400 and 8500 as marked by `**, the receiver synchronizes
itself with the sender between 8500 and 9500.  The bits over the wire
during this time are:

\small
\begin{verbatim}
1 1 1 0 0 0 0 1 1 1 1 \ \ \ \
| | | | | | | | | | |
8500      9000      9500

each bit separated by 100 clock ticks.
\end{verbatim}
\normalsize

As soon as the `** bit is received, {\tt RadioTiming}'s getTiming method is
called from \\{\tt MicaHighSpeedRadioM}'s {\tt startSymDetect}. The code line
``while({\tt TOSH\_READ\_RFM\_RXD\_PIN()}) \{ \}'' will hold the receiver in a
spin loop until the 0 at 6800 clock ticks is received.  {\tt RadioTimingC}
then enables input capture from the radio and the code line
``while((inp({\tt TIFR}) \& (0x1 << {\tt ICF1})) == 0) \{ \}'' pauses the receiver
until the 1 at 9200 is received. {\tt RadioTimingC} returns
the time the input capture occurred to {\tt MicaHighSpeedRadioM}, and
{\tt MicaHighSpeedRadioM} then calls {\tt SpiByteFifo}'s {\tt startReadBytes} with the time stamp of
when the input capture occurred.

{\tt startReadyBytes} sets {\tt SpiByteFifoC}'s state to reading, and delays
itself based on the timestamp of when the input capture occurred to
begin clocking in bits between 9600 and 9700, when the first {\tt TOS\_Msg} packet bit
is sent over the network.

The last timing issue that needs to be addressed is the phase shift that
occurs when the sender switches its state from {\tt SENDING\_STRENGTH\_PULSE}
to {\tt WAITING\_FOR\_ACK}. Up to this point, the sender and receiver are in
perfect sync. The sender sends at 40kbps and the receiver receives at 40kbps. When the
sender and receiver switch roles for the transmission and reception of
the ack, it is necessary for the sender of the packet, to delay
{\tt SpiByteFifo} so that it remains in sync with the receiver of the packet
(the one sending the ack).  The timing diagram below illustrates the
phase shift.

\small
\begin{verbatim}
                <- tx       rx ->
sender:   1    1    1  ###  0    1    0    1

          tx ->
receiver:   1    0    1    0    1    0    1    0

            |    |    |    |    |    |    |    |    |
            0    100  200  300  400  500  600  700  800 (clock ticks)
\end{verbatim}
\normalsize

As shown above, the sender is sending the last 3 bits of the strength
pulse, 0xff. The \#\#\# indicates that the sender shifts its timing,
changes its radio hardware to receive so that the next bit {\tt SpiByteFifoC}
shifts in occurs after the 0 bit is transmitted by the receiver of the
packet shortly after 300 clock ticks.

% Refer to as
%
% Figure \ref{fig:timing}

\begin{figure}
\centering
\includegraphics[scale=0.6,angle=-90]{fig/stack.pdf}
\caption{Timing Diagram of Network Send/Receive}
\label{fig:timing}
\end{figure}


\end{document}