| David Gay, Jonathan Hui |
Note
This memo documents a part of TinyOS for the TinyOS Community, and @@ -310,14 +305,14 @@ requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This memo is in full compliance with TEP 1.
This memo documents a set of hardware-independent interfaces to non-volatile storage for TinyOS 2.x. It describes some design principles for the HPL and HAL layers of various flash chips.
Flash chips are a form of EEPROM (electrically-erasable, programmable read-only memory), distinguished by a fast erase capability. However, erases can only be done in large units (from 256B to 128kB depending on the @@ -338,17 +333,14 @@ significantly different tradeoffs than other flash chips:
One approach to hiding the differences between different flash chips is to provide a disk-like, block interface (with, e.g., 512B blocks). This is the approach taken by compact flash cards. However, in the context of TinyOS, @@ -503,8 +495,8 @@ this framework.
flash chips (Section 3), then describes the flash volumes and storage abstractions in detail (Section 4).The flash chip architecture follows the three-layer Hardware Abstraction Architecture (HAA), with each chip providing a presentation layer (HPL, Section 3.1), adaptation layer (HAL, Section 3.2) and @@ -515,8 +507,8 @@ family with a similar interface, the HAA SHOULD support all family members by relying, e.g., on platform-provided configuration information.
Appendix A shows example HPL and HAL specifications for the AT45DB and ST M25P chip families.
-The flash HPL has a chip-dependent, platform-independent interface. The implementation of this HPL is platform-dependent. The flash HPL SHOULD be stateless.
@@ -528,8 +520,8 @@ directory. If the flash chip implementation supports a family of flash chips, this directory MAY also contain a file describing the particular flash chip found on the platform.The flash HAL has a chip-dependent, platform-independent interface and implementation. Flash families with a common HPL SHOULD have a common HAL. Flash HAL's SHOULD expose a Resource interface and automatically @@ -538,8 +530,8 @@ provide a way to access the volume information specified by the programmer (see Section 3). This allows users to build new flash abstractions that interact cleanly with the rest of the flash system.
Each flash chip MUST support at least one of the storage abstractions described in Section 4. These abstractions SHOULD be presented in components named ChipAbstractionC, e.g., At45dbLogStorageC. @@ -553,13 +545,13 @@ SHOULD redirect uses of Abstracti chip, based on the requested volume.
The HIL implementations are platform-independent, but chip (family) dependent. They implement the three storage abstractions and volume structure discussed in the introduction.
-The division of the flash chip into fixed-size volumes is specified by an XML file that is placed in the application's directory (where one types 'make'). The XML file specifies the allocation as follows:
@@ -597,8 +589,8 @@ components new BlockStorageC(VOLUME_DELUGE0); compile-time error since the symbol will be undefined.A volume MUST NOT be used with more than one storage abstraction instance.
The motivating example for large objects is the transmission or long-term storage of large pieces of data. For instance, programs in a network-reprogramming system, or large data-packets in a reliable @@ -647,8 +639,8 @@ integrity of the BlockStorage data, but such support can easily be built by using the computeCrc command and storing the result in a well-defined location, and checking this CRC when desired.
Event and result logging is a common requirement in sensor networks. Such logging should be reliable (a mote crash should not lose data). It should also be easy to extract data from the log, @@ -735,8 +727,8 @@ a single record. However, the guarantee that only whole records are lost is sufficient to ensure that applications do not to have worry about incomplete or inconsistent log entries.
Sensor network applications need to store configuration data, e.g., mote identity, radio frequency, sample rates, etc. Such data is not large, but losing it may lead to a mote misbehaving or losing contact with the @@ -783,13 +775,13 @@ in the small object. definitions.
An AT45DB implementation can be found in tinyos-2.x/tos/chips/at45db.
An ST M25P implementation can be found in tinyos-2.x/tos/chips/stm25p.
The Atmel AT45DB family HPL is:
configuration HplAt45dbC {
@@ -878,8 +870,8 @@ copy. It also includes flush and sync operations to manage the cache.
The At45dbVolume interface has operations to report volume size and
map volume-relative pages to absolute pages.
The ST M25P family HPL is:
configuration Stm25pSpiC {
@@ -912,13 +904,13 @@ volume-relative addresses. Clients of the ST M25P HAL must implement the
obtain the volume id of each of its clients.
These interfaces are presented briefly here for reference; please refer to the TinyOS documentation for a full description of the commands, events and their parameters.
-The BlockStorage interfaces are:
interface BlockRead {
@@ -947,8 +939,8 @@ interface BlockWrite {
}
The ConfigStorage interfaces are:
interface Mount {
@@ -973,8 +965,8 @@ interface ConfigStorage {
}