[Tinyos-contrib-commits] CVS: tinyos-1.x/contrib/umass LICENSE, NONE, 1.1 README, NONE, 1.1

Gaurav gmathur at users.sourceforge.net
Sat Dec 9 13:05:47 PST 2006


Update of /cvsroot/tinyos/tinyos-1.x/contrib/umass
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv17795

Added Files:
	LICENSE README 
Log Message:
Added contrib/umass containing Capsule -- a storage system for sensors

--- NEW FILE: LICENSE ---
/**********************************************************************
Copyright 2006 The University of Massachusetts -- Amherst.
All Rights Reserved.

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without written
agreement is hereby granted, provided that the above copyright notice
and the following three paragraphs appear in all copies and derivatives
of this software.

IN NO EVENT SHALL THE UNIVERSITY OF MASSACHUSETTS BE LIABLE TO ANY PARTY
FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF
THE UNIVERSITY OF MASSACHUSETTS HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.

THE UNIVERSITY OF MASSACHUSETTS SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
MASSACHUSETTS HAS NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES,
ENHANCEMENTS, OR MODIFICATIONS.

The authors of this software are Gaurav Mathur {gmathur at cs.umass.edu} and
Peter Desnoyers {pjd at cs.umass.edu}
at the Sensors Laboratory (http://sensors.cs.umass.edu),
University of Massachusetts, Amherst. Any publications based on the
use of this software or its derivatives must clearly acknowledge such
use in the text of the publication.
**********************************************************************/

--- NEW FILE: README ---
--------------------------------------------------------------
                         Capsule v0.9
          http://sensors.cs.umass.edu/projects/capsule
    
                      Sensors Laboratory
             University of Massachusetts - Amherst
        Authors: Gaurav Mathur   (gmathur at cs.umass.edu)
                 Peter Desnoyers (pjd at cs.umass.edu)
                 Deepak Ganesan (dganesan at cs.umass.edu)
--------------------------------------------------------------

NOTE: THE LICENSE FOR THIS SOFTWARE HAS BEEN PROVIDED IN THE "LICENSE" FILE
      IN THIS DIRECTORY.

This distribution includes:
- The Capsule storage system
- Driver code for the NAND flash (independent of Capsule)

Directory Structure:
--------------------
The umass directory should be placed in contrib/ directory of the TinyOS tree

umass - apps
      - tos
            - interfaces
            - system
            - lib
            - platform
              ...

Applications can be placed in the apps/ tree. The Makefile present in the apps/ directory
should allow correct code compilation as is.

The sample applications that should be looked at are StressChkpt and StressTest. The other
applications present are old test applications some of which may not compile correctly
as the codebase has undergone extensive modifications -- most of these will be removed from
the final release.


Config:
-------
- It is currently configured to use the Mica2 NOR flash directly. To
  use the NAND flash, comment out "#define PLATFORM_MICA2_NOR" in tos/platform/mica2/platform.h
  Currently one can use the Mica2 NOR flash or the NAND flash in the same application, but not
  both -- this will be fixed in the next release.

- Create a sym-link in tos/platform named micaz and mica2dot pointing to the mica2
  directory -- the codebase for all the 3 platforms is common.

- Each application should have a sizes.h file in its directory which is used for 
  configuring Capsule, enabling/disabling debug messages, etc. 

Misc / Eccentricities:
---------------------
1. Most of the objects have an init method - be sure to call these before you start 
   using the object... all hell might break loose otherwise

2. Be careful to wire StdControl directly to FalC or the flash driver code

3. Be careful about the objects that use the parameterized interfaces (ie. xxx[yyy])
   Look at the wiring of existing applications
   [Some of the internal object code uses the interface number to maintain state about
    the object -- hence, the reason why the interface parameters are important.
    We are currently looking at simplifying this]

4. The storage objects should be initialized in the following order:
   First, call init on the ChunkStorage component
   Second, call init on all the objects
   Third, call init on the Transaction component
   Fourth, call init on the RootDirectory component
   Intuition: The root dir component may trigger a rollback if the system had failed;
    you would want the objects to be correctly initialized before this happens.

5. The Index needs to be saved by your code manually before you can checkpoint it. This is 
   because the index stores everything in an in-memory buffer (to minimize flash 
   operations), and performing a save operation forces a buffer flush.

6. The number of objects instantiated is picked up using uniqueCount(). Thus, it
   is important to use ONLY the following unique Strings when you are wiring object
   instances.
    App.Stream -> StreamM.Stream[unique("Stream")]; // for Stream object
    App.Index -> IndexM.Index[unique("Index")];     // for Index object
    App.Stack -> StackM.Stack[unique("Stack")];     // for Stack object
    App.Queue -> QueueM.Queue[unique("Queue")];     // for Queue objec

7. The application directory should have a sizes.h file in it which is used to
   declare the following.
     -- The following applies to only the index data-structure. Number of elements in 
     Level 2 * number of elements in Level 1 of the index = total capacity of the 
     Index. (Data stored in the index is termed to be at level 0)
     /*
      * This indicates the number of elements in level 1 of the index
      */
     #define ARRAY_ELEMENTS_PER_CHUNK 10

     /*
      * This indicates the number of index elements in level 2 of the index
      */
     #define INDEX_ELEMENTS_PER_CHUNK 10
    
     Thus, here the size of the index will be 100 elements.

     -- You can enable debugging by defining the debug for the appropriate component
     #define INDEX_DEBUG
     #define ARRAY_DEBUG
     #define CHUNK_DEBUG
     #define QUEUE_DEBUG
     #define STACK_DEBUG
     #define STREAM_DEBUG
     #define STREAM_INDEX_DEBUG
     #define CHECKPOINT_DEBUG
     #define ROOT_DIR_DEBUG
     #define COMPACT_DEBUG

8. Debug currently dumps data to the serial port and minicom can be used to pick that up
   -- woefully, this is not good to debug any timing issues.

9. Debug messages can be enabled by uncommenting the appropriate #define in the sizes.h 
   file that should be present in the application directory.

10. The size of the write buffer used by the FAL can be changed by changing the
   following #define in tos/platform/mica2/platform.h
     #define BUFFER_SIZE 256
   The default size is equal to the page size of the flash (most energy efficient).

11. We are facing some issues with the Telos platform -- most code seems to work
    alright, but some code gives run-time errors. We are looking at rectifying this
    soon -- any help / insight is appreciated.



More information about the Tinyos-contrib-commits mailing list