+<p>This lesson shows how configuration data can be written to and read
+from non-volatile storage. Configuration data typically exhibit some
+subset of the following properties. They are <b>limited in size</b>,
+ranging from a fews tens to a couple hundred bytes. Their values may
+be <b>non-uniform</b> across nodes. Sometimes, their values are
+<b>unknown</b> prior to deployment in the field and sometimes their
+values are <b>hardware-specific</b>, rather than being tied to the
+software running on a node.
+
+<p>Because configuration data can be non-uniform across nodes or
+unknown <em>a priori</em>, their values may be difficult to specify at
+compile-time and since the data are sometimes hardware-specific, their
+values must survive reprogramming, suggesting that encoding these
+values in the program image is not the simplest approach. Storing
+configuration data in volatile memory is also problematic since this
+data would not survive a reset or power cycle.
+
+<p>In summary, configuration data must persist through node resets,
+power cycles, or reprogramming, and then be restored afterward. The
+ability to persist and restore configuration data in this manner is
+useful in many scenarios.
+
+<p><ul>
+
+<li><b>Calibration.</b> Calibration coefficients for sensors might be
+factory-configured and persisted, so they are not lost when power is
+removed for shipping or the node is reprogrammed post-calibration.
+For example, a hypothetical temperature sensor might have an offset
+and gain that must be calibrated, because these parameters are
+hardware-specific, and stored because they are needed to convert the
+output voltage into the more useful units of degrees Celcius. The
+calibration data for such a sensor might look like:
+
+<pre>
+typedef struct calibration_config_t {
+ int16_t temp_offset;
+ int16_t temp_gain;
+} calibration_config_t;
+</pre>
+
+<li><b>Identification.</b> Device identification information, like
+IEEE-compliant MAC addresses or the TinyOS TOS_NODE_ID parameters are
+non-uniform across nodes although they are not hardware-specific, once
+they are assigned to a node, these values should be <em>sticky</em> in
+that they are persisted across reset, power cycle, and reprogramming
+operations (and not lost or reassigned to another node).
+
+<pre>
+typedef struct radio_config_t {
+ ieee_mac_addr_t mac;
+ uint16_t tos_node_id;
+} radio_config_t;
+</pre>
+
+<li><b>Location.</b> Node location data may be unknown at compile-time
+and only become available during deployment. An application might,
+for example, store node coordinates as follows and update these values
+in the field:
+
+<pre>
+typedef struct coord_config_t {
+ uint16_t x;
+ uint16_t y;
+ uint16_t z;
+} coord_config_t;
+</pre>
+
+<li><b>Sensing.</b> Sensing and signal processing parameters like
+sample period, filter coefficients, and detection thresholds might be
+adjusted in the field. The configuration data for such an application
+might look like: