Commit graph

6 commits

Author SHA1 Message Date
Joakim Nohlgård de7850ed58 core/lib/settings.h: fix warning: function declaration isn't a prototype 2016-03-02 07:00:57 +01:00
Enrico Joerns e4db33f560 [doc] updated settings manager documentation 2014-11-10 23:53:32 +01:00
Adam Dunkels bb2dcaa057 A massive all-tree automated update of all double inclusion guard #defines that changes from using two underscores as a prefix, which are reserved, to not using two underscores as a prefix 2013-11-24 20:20:11 +01:00
Robert Quattlebaum 0308d3fcf0 settings: Correct a problem where sometimes CC_INLINE is not defined properly. 2013-07-02 08:46:03 -07:00
Robert Quattlebaum ed2dd29eda core/lib/settings: Added SETTINGS_CONF_SKIP_CONVENIENCE_FUNCS.
Unfortunately, some platforms don't properly drop unreferenced functions,
so on these broken platforms we can save a significant amount
of space by skipping the definition of the convenience functions.
2013-03-20 11:57:13 -07:00
Robert Quattlebaum 28a1e40ebd core/lib/settings: Generalized Settings Manager to work on any platform
This commit moves the Settings Manager from the AVR codebase
into the Contiki core library. Any platform that implements
the Contiki EEPROM API can now use the Settings Manager's
key-value store for storing their persistent configuration info.

The Settings Manager is a EEPROM-based key-value store. Keys
are 16-bit integers and values may be up to 16,383 bytes long.
It is intended to be used to store configuration-related information,
like network settings, radio channels, etc.

 * Robust data format which requires no initialization.
 * Supports multiple values with the same key.
 * Data can be appended without erasing EEPROM.
 * Max size of settings data can be easily increased in the future,
   as long as it doesn't overlap with application data.

The format was inspired by the [OLPC manufacturing data format][].

Since the beginning of EEPROM often contains application-specific
information, the best place to store settings is at the end of EEPROM
(the "top"). Because we are starting at the end of EEPROM, it makes
sense to grow the list of key-value pairs downward, toward the start of
EEPROM.

Each key-value pair is stored in memory in the following format:

Order    | Size     | Name         | Description
--------:|---------:|--------------|-------------------------------
       0 |        2 | `key`        | 16-bit key
      -2 |        1 | `size_check` | One's-complement of next byte
      -3 |   1 or 2 | `size`       | The size of `value`, in bytes
-4 or -5 | variable | `value`      | Value associated with `key`

The end of the key-value pairs is denoted by the first invalid entry.
An invalid entry has any of the following attributes:

 * The `size_check` byte doesn't match the one's compliment of the
   `size` byte (or `size_low` byte).
 * The key has a value of 0x0000.

[OLPC manufacturing data format]: http://wiki.laptop.org/go/Manufacturing_data
2013-03-20 11:57:13 -07:00