[Tinyos-2-commits] CVS: tinyos-2.x/doc/html/tutorial lesson5.html, 1.1.2.12, 1.1.2.13

Wed Nov 1 09:15:30 PST 2006

Update of /cvsroot/tinyos/tinyos-2.x/doc/html/tutorial
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv12993/doc/html/tutorial

Modified Files:
      Tag: tinyos-2_0_devel-BRANCH
	lesson5.html 
Log Message:
Updated with Kevin's suggestions.

Index: lesson5.html
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/html/tutorial/lesson5.html,v
retrieving revision 1.1.2.12
retrieving revision 1.1.2.13
diff -C2 -d -r1.1.2.12 -r1.1.2.13
*** lesson5.html	1 Jul 2006 18:11:05 -0000	1.1.2.12
--- lesson5.html	1 Nov 2006 17:15:25 -0000	1.1.2.13
***************
*** 29,35 ****
  used the <code>ADC</code> and <code>ADCControl</code> interfaces to collect
  sensor data. When new platforms appeared with sensors that were read out via
! the serial interface, not only additional interfaces like <code>ADCError</code>
! had to be introduced, but it became clear that equating a sensor with an ADC is
! difficult.

  <p> Usually sensing involves two tasks: configuring a sensor (and/or the
--- 29,35 ----
  used the <code>ADC</code> and <code>ADCControl</code> interfaces to collect
  sensor data. When new platforms appeared with sensors that were read out via
! the serial interface, not only did additional interfaces like <code>ADCError</code>
! have to be introduced, but it became clear that equating a sensor with an ADC was
! not always the appropriate thing to do.

  <p> Usually sensing involves two tasks: configuring a sensor (and/or the
***************
*** 38,46 ****
  example, <code>Sense</code> is meant to run on any TinyOS platform. How can
  <code>Sense</code> know the configuration details (e.g. input channel, the
! required reference voltage, etc.) of an attached sensor ? It can't, because the
! configuration details of, for example, the light sensor on the <i>tmote</i>
! platform will be different from the <i>eyes</i> platform.  Unless
! <code>Sense</code> knows about all sensors on all platforms it can't perform
! the configuration task, since the interfaces for the configuration of a sensor
  will differ from platform to platform (and potentially from sensor to sensor).
  However, the second task - reading the sensor data - can be solved so that the
--- 38,46 ----
  example, <code>Sense</code> is meant to run on any TinyOS platform. How can
  <code>Sense</code> know the configuration details (e.g. input channel, the
! required reference voltage, etc.) of an attached sensor? It can't, because the
! configuration details of sensors will be different from platform to platform, 
! i.e. (the light sensor on the <i>tmote</i> and the one on the <i>eyes</i> platform.  
! Unless <code>Sense</code> knows about all sensors on all platforms it will be unable to
! perform the configuration task since the interfaces for the configuration of a sensor
  will differ from platform to platform (and potentially from sensor to sensor).
  However, the second task - reading the sensor data - can be solved so that the
***************
*** 50,55 ****
  <p> In TinyOS 2.0 <i>platform independent</i> sensing applications such as
  <code>Oscilloscope</code>, <code>Sense</code> or <code>RadioSenseToLeds</code>
! are not using configuration interfaces like <code>ADCControl</code> anymore;
! instead they are only using the standard data acquisition interfaces
  <code>Read</code>, <code>ReadStream</code> or <code>ReadNow</code> for
  collecting sensor data. All configuration details are hidden from the
--- 50,55 ----
  <p> In TinyOS 2.0 <i>platform independent</i> sensing applications such as
  <code>Oscilloscope</code>, <code>Sense</code> or <code>RadioSenseToLeds</code>
! do not use configuration interfaces like <code>ADCControl</code> anymore;
! instead they use the standard data acquisition interfaces
  <code>Read</code>, <code>ReadStream</code> or <code>ReadNow</code> for
  collecting sensor data. All configuration details are hidden from the
***************
*** 64,80 ****

<li> Since the <code>Sense</code> application component only uses standard
! data acquisition interfaces who defines what sensor it samples ?

<li> If the <code>Sense</code> application component is not configuring the
! sensor, who is responsible for that ?

! <li> How can an application like <code>Sense</code> display sensor data when it
! does not know the details about sensor configuration ? This includes questions
 like "what is the value range of the sensor data" or "is a temperature reading
! to be interpreted in degree Celsius or Fahrenheit" ?

<li> Let's assume there are several sensors on a platform: what steps have to
! be done to let the <code>Sense</code> or <code>Oscilloscope</code> application
! display data of a different sensor ?

  </ul> 
--- 64,80 ----

<li> Since the <code>Sense</code> application component only uses standard
! data acquisition interfaces who is in charge of defining which sensor it samples?

<li> If the <code>Sense</code> application component is not configuring the
! sensor, then who is responsible for that?

! <li> How can an applications like <code>Sense</code> display sensor data when they
! do not know the details about sensor configuration? This includes questions
 like "what is the value range of the sensor data" or "is a temperature reading
! to be interpreted in degrees Celsius or Fahrenheit"?

<li> Let's assume there are several sensors on a platform: what steps have to
! be taken to let the <code>Sense</code> or <code>Oscilloscope</code> application
! display data from a different sensor?

</ul> 
***************
*** 84,88 ****
 example, the following sections explain how the data acquisition interfaces are
 used, how the configuration procedure works and, as an example, how
! <code>Sense</code> can be hooked up to a different than the default sensor on
 the telosb platform.

--- 84,88 ----
  example, the following sections explain how the data acquisition interfaces are
  used, how the configuration procedure works and, as an example, how
! <code>Sense</code> can be hooked up to sensors other than the default one on
  the <i>telosb</i> platform.

***************
*** 173,177 ****
  <code>Read</code> interface takes a type parameter. Generic interfaces are
  explained in the nesC Language Reference Manual (version 1.2 and above).
! Here it is enough to know that generic interfaces have at least one type
  parameter and two components can be wired together only if they provide/use the
  interface with the same types (note that the <code>readDone</code> event passes
--- 173,177 ----
  <code>Read</code> interface takes a type parameter. Generic interfaces are
  explained in the nesC Language Reference Manual (version 1.2 and above).
! For now it is enough to know that generic interfaces have at least one type
  parameter and two components can be wired together only if they provide/use the
  interface with the same types (note that the <code>readDone</code> event passes
***************
*** 187,192 ****

Recall that the wiring is defined in the <code>SenseAppC.nc</code>
! configuration. Let's again take a look, which component <code>SenseC.nc</code>
! is wired to with the <code>Read&lt;uint16_t&gt;</code> interface in the
 <code>SenseAppC</code> configuration. The interesting lines are

--- 187,192 ----

Recall that the wiring is defined in the <code>SenseAppC.nc</code>
! configuration. Let's again take a look at which component <code>SenseC.nc</code>
! is wired to using the <code>Read&lt;uint16_t&gt;</code> interface in the
 <code>SenseAppC</code> configuration. The interesting lines are

***************
*** 200,207 ****

This means that the generic <code>DemoSensorC</code> component provides
! the <code>Read&lt;uint16_t&gt;</code> interface to <code>SenseC.nc</code> (a
! generic component is a component that can be instantiated more than once
! and can take constant and type arguments; each instantiation is a
! different component).

  <p> It is important to understand that the <code>SenseC.nc</code> module has no
--- 200,204 ----

This means that the generic <code>DemoSensorC</code> component provides
! the <code>Read&lt;uint16_t&gt;</code> interface to <code>SenseC.nc</code>

  <p> It is important to understand that the <code>SenseC.nc</code> module has no
***************
*** 213,222 ****
  values. The last sentence hints that the <code>DemoSensorC</code> component is
  different for every platform: therefore you will not find
! <code>DemoSensorC.nc</code> in the TinyOS libraries. Instead
! <code>DemoSensorC.nc</code> has to be written for every platform, because, for
! example, on the <i>telosb</i> platform <code>DemoSensorC</code> needs to be
! implemented differently than on the the <i>micaz</i> platform. This is the
  answer to the first question asked in the <a
! href="#introduction">introduction</a>: the <i>platform dependent</i>
  <code>DemoSensorC</code> component defines which sensor the <code>Sense</code>
  or <code>Oscilloscope</code> application is sampling and every platform that
--- 210,219 ----
  values. The last sentence hints that the <code>DemoSensorC</code> component is
  different for every platform: therefore you will not find
! <code>DemoSensorC.nc</code> in the TinyOS libraries. Instead, a different
! <code>DemoSensorC.nc</code> has to be written for every platform, i.e. the
! <code>DemoSensorC.nc</code> implementation for telosb will be different than
! the <code>DemoSensorC.nc</code> implementation for micaz.  This is the
  answer to the first question asked in the <a
! href="#introduction">introduction</a> section: the <i>platform dependent</i>
  <code>DemoSensorC</code> component defines which sensor the <code>Sense</code>
  or <code>Oscilloscope</code> application is sampling and every platform that
***************
*** 225,230 ****
  version of <code>DemoSensorC</code>. Additionally, sensor boards may come
  with their own version of <code>DemoSensorC</code> (e.g., the 
! <code>basicsb</code> sensorboard for the mica-family of motes is defined to
! be that board's light sensor).

  <a name="demosensorc"><h2>The DemoSensorC component</h2></a>
--- 222,227 ----
  version of <code>DemoSensorC</code>. Additionally, sensor boards may come
  with their own version of <code>DemoSensorC</code> (e.g., the 
! <code>basicsb</code> sensorboard for the mica-family of motes define 
! <code>DemoSensorC.nc</code> to be that board's light sensor).

  <a name="demosensorc"><h2>The DemoSensorC component</h2></a>
***************
*** 253,262 ****
  component that <code>DemoSensorC</code> instantiates.

! How can <code>Sense</code> be changed to sample another than the platform's
 default sensor? Usually this requires changing only a single line of code in
 <code>DemoSensorC</code>; for example, if you wanted to replace the
 <code>VoltageC</code> component on telosb by the constant sensor
! component <code>ConstantSensorC</code> you could change (in
! <code>DemoSensorC</code>)

  <pre>
--- 250,259 ----
  component that <code>DemoSensorC</code> instantiates.

! How can <code>Sense</code> be changed to sample a sensor other than the platform's
 default sensor? Usually this requires changing only a single line of code in
 <code>DemoSensorC</code>; for example, if you wanted to replace the
 <code>VoltageC</code> component on telosb by the constant sensor
! component <code>ConstantSensorC</code> you could change the follwoing line in
! <code>DemoSensorC</code> from:

<pre>
***************
*** 281,286 ****
 To compile the <code>Sense</code> application, go to the
 <code>apps/Sense</code> directory and depending on which hardware you have,
! type e.g. <code>make telosb install</code>. If you get errors like the
! following

  <pre>
--- 278,283 ----
  To compile the <code>Sense</code> application, go to the
  <code>apps/Sense</code> directory and depending on which hardware you have,
! type something similar to <code>make telosb install</code>.  If you get errors such as 
! the following,

  <pre>
***************
*** 290,294 ****
  </pre>

! your platform has not implemented the <code>DemoSensorC</code> component. For a
  quick solution you can copy <code>DemoSensorC.nc</code> from
  <code>tinyos-2.x/tos/platforms/micaz</code> to your platform directory; then
--- 287,291 ----
  </pre>

! your platform has not yet implemented the <code>DemoSensorC</code> component. For a
 quick solution you can copy <code>DemoSensorC.nc</code> from
 <code>tinyos-2.x/tos/platforms/micaz</code> to your platform directory; then
***************
*** 307,312 ****
 the sensor readings are displayed on the node's LEDs (0 = off, 1 = on). If your
 <code>DemoSensorC</code> represents a sensor whose readings are fluctuating
! greatly you may see the LEDs toggle, otherwise <code>Sense</code> is not so
! impressive. Let's have a look at a more interesting application:
 <code>Oscilloscope</code>.

--- 304,309 ----
  the sensor readings are displayed on the node's LEDs (0 = off, 1 = on). If your
  <code>DemoSensorC</code> represents a sensor whose readings are fluctuating
! greatly you may see the LEDs toggle, otherwise <code>Sense</code> does not seem to
! be very impressive.  Let's take a look at a more interesting application:
  <code>Oscilloscope</code>.

***************
*** 371,378 ****
  <code>Oscilloscope</code> is a combination of different building blocks
  introduced in previous parts of the tutorial. Like <a
! href="#sense"><code>Sense</code></a> <code>Oscilloscope</code> uses
  <code>DemoSensorC</code> and a timer to periodically sample the default sensor
  of a platform. When it has gathered 10 sensor readings
! <code>OscilloscopeC</code> puts them into a message and broadcasts the message
  via the <code>AMSend</code> interface.  <code>OscilloscopeC</code> uses the
  <code>Receive</code> interface for synchronization purposes (see below) and the
--- 368,375 ----
  <code>Oscilloscope</code> is a combination of different building blocks
  introduced in previous parts of the tutorial. Like <a
! href="#sense"><code>Sense</code></a>,  <code>Oscilloscope</code> uses
  <code>DemoSensorC</code> and a timer to periodically sample the default sensor
  of a platform. When it has gathered 10 sensor readings
! <code>OscilloscopeC</code> puts them into a message and broadcasts that message
  via the <code>AMSend</code> interface.  <code>OscilloscopeC</code> uses the
  <code>Receive</code> interface for synchronization purposes (see below) and the
***************
*** 386,390 ****
  To install the <code>Oscilloscope</code> application go to
  <code>tinyos-2.x/apps/Oscilloscope</code> and depending on which hardware you
! have, type e.g. <code>make telosb install,1</code>. Note the "<code>,1</code>"
  after the <code>install</code> option, which assigns ID 1 to the node.
  Assigning IDs to nodes is helpful to differentiate them later on in the GUI, so
--- 383,387 ----
  To install the <code>Oscilloscope</code> application go to
  <code>tinyos-2.x/apps/Oscilloscope</code> and depending on which hardware you
! have, type something similar to <code>make telosb install,1</code>. Note the "<code>,1</code>"
  after the <code>install</code> option, which assigns ID 1 to the node.
  Assigning IDs to nodes is helpful to differentiate them later on in the GUI, so
***************
*** 440,444 ****
  the raw data as signalled by the <code>Read.readDone()</code> event. They do
  not perform semantic processing and cannot decide questions like "is a reading
! to be interpreted in degree Celsius or Fahrenheit". This decision is forwarded
  to the user and therefore the GUI let's you adapt the visible portion of the
  y-axis to a plausible range (at the bottom right).
--- 437,441 ----
  the raw data as signalled by the <code>Read.readDone()</code> event. They do
  not perform semantic processing and cannot decide questions like "is a reading
! to be interpreted in degrees Celsius or Fahrenheit". This decision is forwarded
  to the user and therefore the GUI let's you adapt the visible portion of the
  y-axis to a plausible range (at the bottom right).