[Tinyos-Storage WG] Support checkpointing / rollback for storageobjects

[David Moss]

The microcontrollers we're dealing with now on the Mica* and Tmote platforms
have internal microcontroller user memory.  The Tmote has 256 bytes of
flash, divided into two erase units of 128 bytes.  The Mica* has something
like 4kB of EEPROM.

By implementing DirectStorage on top of these (and a similar interface -
DirectModify - since those user memory areas can support it) we can access
the user memory just like we would the external memory.  The user memory is
small enough that there is no need to implement separate volumes on it, but
it can be used to implement one storage mechanism able to store state
information and other small configuration values.

The trick is sharing the small user area of flash across multiple components
in the application.  If we were to define a framework by which we could
share the internal flash space, then this should help in supporting not only
the state-type information we need for maintaining, but also small
non-volatile state- and configuration-type variables the user wants to store
from their application.

To this end, I've implemented DirectStorage (and DirectModify) on top of the
ATmega128 internal EEPROM, and MSP430 internal flash as an abstraction
layer.

On top of this, we build a mechanism to share those small portions of memory
across multiple components in an application.  I believe the goals of this
type of sharing mechanism should be:

* Ability to store small values of any type and of any length from multiple
components
* Ability to verify that data read back has not been corrupted
* Ability to load and store variables from non-volatile memory directly into
the location in RAM where the application accesses that particular variable.

Rincon has implemented a library called "Configurator" that does just that.
It was originally developed to support applications running on both Mica*
and Tmote platforms, and effectively shares the user memory across multiple
components in the system.

The interface for Configurator looks like this (comments are available in
the actual Configurator.nc interface file located in
tinyos-2.x-contribs/rincon/tos/lib/configurator)

interface Configurator {

  command error_t login(void *data, uint8_t size);
  
  command error_t store();
  
  command error_t load();

  command void cancel();
  
  
  event void requestLogin();

  event void stored(error_t error);
  
  event void loaded(bool valid, void *data, uint8_t size, error_t error);

}

Here's how it works:
Upon boot, the Configurator library sends out an event to each connected
component to requestLogin().  The order in which it pings the parameterized
interfaces to request logins is the same each time for any program, and
that's what allows it to effectively share the flash.

Each component that wants to access the internal uC memory MUST call back
the login() command, providing a pointer to the data it wants to store and
that data's length.  If there's enough space to support that data, then
login() returns SUCCESS.

After every component has logged in at boot time, the Configurator
automatically pulls all values stored on uC memory and loads them into each
connected components' RAM, signaling loaded() each time.  The component can
define a default value if the loaded value is not valid, and can store() and
load() at any time.  The configurator knows, based on the parameterized
interface, where to store and load the component's value on non-volatile
memory.  Values stored automatically have an 8-bit CRC tacked on to verify
the value is valid when loaded.

When the user installs a different program on the mote, the user memory is
automatically erased.  


The only trick we've had to deal with is getting the Configurator library to
startup *before* all the other components startup and after interrupts are
enabled (for cross-platform support).  This is useful because when the
components actually get the Boot.booted() event, they'll already have their
variables in non-volatile loaded.

Code is available in:
tinyos-2.x-contribs\rincon\tos\lib\configurator
tinyos-2.x-contrib\rincon\apps\testsTestConfigurator

-David



-----Original Message-----
From: tinyos-storage-bounces at millennium.berkeley.edu
[mailto:tinyos-storage-bounces at millennium.berkeley.edu] On Behalf Of Prabal
Dutta
Sent: Thursday, April 12, 2007 8:58 PM
To: tinyos-storage at millennium.berkeley.edu
Subject: [Tinyos-Storage WG] Support checkpointing / rollback for
storageobjects

[From Gaurav Mathur's original e-mail]

Storage objects should be able to maintain state across system
resets/reboots (if the user wants). Rather than each object
maintaining its own state, it might be a better to develop a common
framework that can be used to store and retrieve object state to and
from flash.

Questions
* What should be the design of such a common framework that objects can
re-use ?
* Should the implementation be platform dependent or independent ?
_______________________________________________
Tinyos-Storage mailing list
Tinyos-Storage at millennium.berkeley.edu
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-storage