[Tinyos-beta-commits] CVS: tinyos-1.x/beta/ProgManual power.tex,
NONE, 1.1 Makefile, 1.2, 1.3 comm.tex, 1.1, 1.2 core.tex, 1.1,
1.2 pm.tex, 1.3, 1.4
Kristin Wright
kristinwright at users.sourceforge.net
Fri Oct 15 15:37:31 PDT 2004
Update of /cvsroot/tinyos/tinyos-1.x/beta/ProgManual
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19649
Modified Files:
Makefile comm.tex core.tex pm.tex
Added Files:
power.tex
Log Message:
some comm updates; will not make now but will format later
--- NEW FILE: power.tex ---
The whole point of using HPLPowerManagement is that you don't actually *use*
it. You call HPLPowerManagement.enable() and then the mote will
automatically sleep when the following conditions are met:
* the radio is off
* all high speed clock output compare interrupts are disabled
* spi interrupt disabled
* task queue is empty
There is no code to "use" power management, instead each service (Timer,
Radio, SpiByteFifo, etc) calls HPLPowerManagement.adjustPower() when the
component has shut down to notify the PowerManagement component that it
should check the state of the above items again and reset the sleep
register. Thus applications need not worry about explicitly telling the
mote to go to sleep (THIS is the main difference between HPLPowerManagement
and the *deprecated* Snooze).
The main advantage of this approach is it allows services to clean up, save
state, and shut down before the cpu is halted. In snooze, the cpu is stolen
out from under running services without any notification to those services.
For HPLPowerManagement to work, an application must call
CC1000RadioC.StdControl.stop(). After this call, HPLPowerManagement takes
over (once the radio is done shutting down), and sets the appropriate
registers to put the mote to sleep after the task queue empties. Note that
if using a low power radio listening state (such as
CC1000RadioIntM.setListeningMode(i)), the CC1000 radio module will take care
of notifying HPLPowerManagement to say it is okay to halt the CPU.
The mote will wake up on the next 32kHz Timer interrupt.
The long winded answer to your question, Mark, is that *only* services need
to call adjustPower() when they have finished shutting down or starting up.
It is invalid semantics for an application to call adjustPower(), however
you are not penalized by it in the current implementation. Thus, your
application should call HPLPowerManagement.enable() in its
StdControl.init(). Power Management is disabled by default.
I believe HPLPowerManagement is documented somewhere in the TOS 1.1 release.
GDI and TASK/TinyDB both enable HPLPowerManagement. The GDI code is in
contrib/ucb/apps/TestLabApp. GDI uses low power radio sampling (part of the
default CC1000 radio stack) and achieves 30uA sleep state. TinyDB uses its
own TDMA scheme for low power communications and also achieves the same low
power state.
Index: Makefile
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/ProgManual/Makefile,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** Makefile 6 Mar 2004 01:18:43 -0000 1.2
--- Makefile 15 Oct 2004 22:37:28 -0000 1.3
***************
*** 4,9 ****
#
! LATEX = pdflatex
! PDF = pdflatex
BIB = bibtex
--- 4,11 ----
#
! #LATEX = pdflatex
! #PDF = pdflatex
! LATEX = pdftex
! PDF = pdftex
BIB = bibtex
Index: comm.tex
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/ProgManual/comm.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** comm.tex 3 Mar 2004 21:52:42 -0000 1.1
--- comm.tex 15 Oct 2004 22:37:28 -0000 1.2
***************
*** 2,17 ****
\section{Communication}
\subsection{Communication Interfaces}
! \subsubsection{BareSendMsg}
\subsubsection{ReceiveMsg}
\subsubsection{RadioCoordinator}
\subsection{Communication Implementations}
\subsubsection{UART}
! \subsubsection{CC1000Radiol}
CC1000RadioControl
\subsubsection{CC2420 Radio}
--- 2,134 ----
\section{Communication}
+ \subsection{Communication Model: Active Messages}
+
+ Active message model. Use IDs to dispatch messages to message handler code. Refer to AM paper.
+
+ Buffer model.
+
+ Sending:
+ TinyOS Active Message buffers follow a strict alternating
+ ownership protocol to avoid expensive memory management, while still
+ allowing concurrent operation. If the message layer accepts the send()
+ command, it owns the send buffer and the requesting component should
+ not modify the buffer until the send is complete (as indicated by the
+ sendDone() event).
+
+ The simplicity of the send-buffer management in the underlying
+ communication layers usually requires that the application implement
+ some buffer management. A common mechanism is a pending flag which
+ keeps track of the buffer's status. If the previous messages is still
+ being sent, the application cannot modify the buffer and return FAIL
+ for any send requests. If the flag indicates that the send buffer is
+ available, the application is free to fill the buffer and send the
+ message.
+
+ Receiving: Memory management for incoming messages is inherently
+ dynamic. A message arrives and fills a buffer, and the Active Message
+ layer decodes the handler type and dispatches it. The buffer is handed
+ to the application component (through the ReceiveMsg.receive() event),
+ but, critically, the application component must return a pointer to a
+ free buffer upon completion.
+
+ If the application is done with the buffer, it can return a pointer to
+ that buffer. If your component needs to save the message contents for
+ later use, it needs to copy the message to a new buffer, or return a
+ new (free) message buffer for use by the network stack.
+
+ \subsection{Packet definition}
+
+ TOSMsg.
+
+ TOSH_DATA_LENGTH. TOSH_DATA_LENGTH is a constant that defines the
+ maximum length of the data payload in the messages. The actual length of
+ the data payload is in the length field of the TOSMsg structure.
+ There are hooks in the TinyOS make system (tools/make) that allow
+ you can to set the value of TOS_DATA_LENGTH in your application by
+ defining MSG_SIZE to the size you'd like in your application's makefile
+ where MSG_SIZE is the value you want to use for TOSH_DATA_LENGH.
+ For example, 'MSG_SIZE=40' would effectively change TOSH_DATA_LENGTH to
+ 40 bytes.
+
\subsection{Communication Interfaces}
! \subsubsection{SendMsg}
\subsubsection{ReceiveMsg}
+
+ \subsubsection{Mac-layer Control, Reliability & Error Detection}
+
+ Always call radio control (SetRFPower(), MacControl.enableAck(), etc.)
+ functions in StdControl.start() rather than StdControl.init(). The
+ order of init() calls in TinyOS cannot be predetermined, so the radio's init()
+ function may be called after the application's init() fucntion and
+ reset any previously set settings.
+
+ CRCs.
+
+ interface MacBackoff
+ {
+ async event int16_t initialBackoff(TOS_MsgPtr m);
+ async event int16_t congestionBackoff(TOS_MsgPtr m);
+ }
+
+ Acks (CC1000 & CC2420 below, RFM?)
+
+ interface MacControl
+ {
+ async command void enableAck();
+ async command void disableAck();
+ }
+
+ Protocol: MacControl.enableAck() must be called before message is
+ sent. If on, hardware will automatically send an acknowledgement. If
+ acknowledgements are enabled, the radio stack will wait for an ack or
+ timeout before signaling the sendDone event. If an ack is received,
+ the TOSMsg.ack field will be set to 1, it will be set to 0 otherwise.
+
+ Note: cc1000 requires 250us to switch radio's mode from rcv to xmit,
+ then 10-15 bytes to sync sending radio with receiver radio, and only
+ then can you send the ACK. The effective throughput cut by
+ 1/3. Nevertheless, ACKs can be sent on CC1000 (Is this still true?)
+
+ \subsection{Communication Components}
+
+ \subsection{GenericComm}
+
+ SendMsg, ReceiveMsg, StdControl.
+
+ \subsubsection{Low-level}
\subsubsection{RadioCoordinator}
+ \subsubsection{BareSendMsg}
\subsection{Communication Implementations}
\subsubsection{UART}
! \subsubsection{CC1000Radio}
CC1000RadioControl
+ \subsubsubsection{PowerManagement}
+
+ App needs to call radio component's StdControl.stop() function. For example:
+ CC2420RadioC.StdControl.stop()
+
\subsubsection{CC2420 Radio}
+ High-level overview
+ Design goals.
+
+ High-level use:
+ CC2420RadioC
+ - BareSendMsg
+ - ReceiveMsg
+ - CC2420Control
+ - MacControl
+ - MacBackoff
+
+ (wired to CC2420RadioM, CC2420RadioControlM)
+
+ \subsubsubsection{PowerManagement}
+
+
+
+
+
Index: core.tex
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/ProgManual/core.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** core.tex 6 Mar 2004 01:18:43 -0000 1.1
--- core.tex 15 Oct 2004 22:37:28 -0000 1.2
***************
*** 2,7 ****
Before one can understand how to customize components or place
! components together to form an application, some concepts central to
! TinyOS must first be explained.\footnote{The
information found in this section is covered in detail in \cite{jhill-thesis}.}
--- 2,7 ----
Before one can understand how to customize components or place
! components together to form an application, some central TinyOS concepts
! must first be explained.\footnote{The
information found in this section is covered in detail in \cite{jhill-thesis}.}
***************
*** 28,31 ****
--- 28,33 ----
\subsubsection{\nesc support for the execution model}
+ async / sync
+
\subsection{The Component Model}
Index: pm.tex
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/ProgManual/pm.tex,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** pm.tex 6 Mar 2004 01:18:43 -0000 1.3
--- pm.tex 15 Oct 2004 22:37:28 -0000 1.4
***************
*** 18,22 ****
\title{TinyOS Programmer's Manual}
\author{Kristin Wright}
! \date{May 2003}
\maketitle
--- 18,22 ----
\title{TinyOS Programmer's Manual}
\author{Kristin Wright}
! \date{October 2004}
\maketitle
More information about the Tinyos-beta-commits
mailing list