[Tinyos-beta-commits] CVS: tinyos-1.x/beta/teps/txt tep101.txt, 1.7, 1.8

[Phil Levis]

Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/txt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6923

Modified Files:
	tep101.txt 
Log Message:
Started editing, but ran out of time.


Index: tep101.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep101.txt,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** tep101.txt	26 May 2005 18:10:09 -0000	1.7
--- tep101.txt	31 May 2005 01:14:31 -0000	1.8
***************
*** 26,35 ****
  ====================================================================
  
! This TEP proposes a new hardware abstraction for the analog-to-digital
! converters (ADCs) in TinyOS 2.x. It focuses on aligning the ADC
  abstraction with the three-layer Hardware Abstraction Architecture
! (HAA) described in TEP 2. The ADC abstraction itself does not include
! an HIL, but the platform independent representation is discussed in
! TEP 109 (Sensorboards).
  
  Introduction
--- 26,35 ----
  ====================================================================
  
! This TEP proposes a hardware abstraction for TinyOS 2.x
! analog-to-digital converters (ADCs). It focuses on aligning the ADC
  abstraction with the three-layer Hardware Abstraction Architecture
! (HAA) described in TEP 2. This TEP only addresses the HPL and HAL of
! an ADC. TEP 109 (Sensorboards) presents an example HIL that can sit on
! top of the ADC.
  
  Introduction
***************
*** 41,65 ****
  `Hardware differences between the current platforms`_). This makes it
  difficult to find a chip independent representation for ADCs. Even if
! there was such a representation, the configuration details of an ADC
! would still depend on the actual device (sensor) producing the input
  signal. Neither a platform independent application nor the ADC
! hardware stack itself has access to this information. It can only be
! determined on a platform or sensorboard level, e.g. which ADC port a
! certain sensor is attached to and how a conversion result needs to be
! interpreted. Thus there is no platform independent (HIL)
! representation of an ADC in TinyOS.
  
! Instead, on top of the ADC hardware abstraction a further abstraction
! concept is required to use ADCs in a platform independent way. This
! concept is described in TEP 109 (Sensorboards): Named sensor
! components, called sensor wrappers, provide platform independent
! access to sensors by providing standard TinyOS interfaces.
  
! In order to facilitate the writing of sensor wrappers and allow them
! to incorporate certain services (e.g. access to the ADC on a round
! robin basis), the ADC hardware stack will include as its top layer a
! second, chip independent (but still platform dependent) HAL.  The
! following section gives an overview of the involved components.
! Afterwards each layer is discussed in detail.
  
  Overview
--- 41,69 ----
  `Hardware differences between the current platforms`_). This makes it
  difficult to find a chip independent representation for ADCs. Even if
! there were such a representation, the configuration details of an ADC
! still depend on the actual device (sensor) producing the input
  signal. Neither a platform independent application nor the ADC
! hardware stack itself has access to this information, which can only
! be determined on a platform or sensorboard level. For example,
! determining which ADC port a certain sensor is attached to and how a
! conversion result needs to be interpreted is a platform specific
! determination. Thus ADCs themselves are not well suited to a platform
! independent (HIL) representation.
  
! Although ADCs are very platform specific, there are commonalities
! across platforms. For example, many ADCs only allow a single sample at
! a time. As many components may be sampling different sensors that
! share an ADC, the ADC system needs to provide some form of resource
! arbitration, and being able to use a library of common arbitration
! components is desirable. Therefore, following a common structure to
! interface to the HIL can greatly simplify sensor deployment and
! development.
  
! In order to facilitate sensor development and allow them to
! incorporate certain services (e.g. access to the ADC on a round robin
! basis), the ADC hardware stack includes as its top layer a second,
! chip independent (but still platform dependent) HAL.  The following
! section gives an overview of the involved components.  Afterwards each
! layer is discussed in detail.
  
  Overview
***************
*** 72,84 ****
  component graph in a top-down fashion. 
  
! The highest layer of abstraction, the HIL, will be composed of named
! sensor components (sensor wrappers) that provide interfaces only for
! acquiring the corresponding data. TEP 109 covers the definition and
! implementation of these HIL sensor components. However, many sensors
! sit on top of a shared hardware ADC.
  
! As the ADC hardware will usually be multiplexed between several client
! applications, access to it needs to be arbitrated.  The ADC stack uses
! standard TinyOS resource management modules, such as
  AcquireDataRoundRobinM, to arbitrate access. These generic arbitration
  modules use parameterized AcquireData[Now] (and Resource) interfaces.
--- 76,87 ----
  component graph in a top-down fashion. 
  
! The highest layer of abstraction, the HIL, is composed of named sensor
! components that provide interfaces only for acquiring the
! corresponding data (TEP 109). However, many sensors sit on top of a
! shared hardware ADC.
  
! As the ADC hardware can be multiplexed between several client
! applications, it requires access arbitration.  The ADC stack uses a
! library of standard TinyOS resource management modules, such as
  AcquireDataRoundRobinM, to arbitrate access. These generic arbitration
  modules use parameterized AcquireData[Now] (and Resource) interfaces.