zephyr

History

Marcin Niestroj 2d3365200c settings: file: drop CONFIG_SETTINGS_FILE_DIR There is already CONFIG_SETTINGS_FILE_PATH, which is set to full file path, while CONFIG_SETTINGS_FILE_DIR is required to be set to its parent directory. This is redundant, as parent directory path can be easily found out either during runtime or optionally during buildtime by CMake. CONFIG_SETTINGS_FILE_DIR was actually introduced recently after Zephyr 3.2 release as a replacement of deprecated CONFIG_SETTINGS_FS_DIR. This means, that there is no need to deprecate it for 3.3 release and dropping it should be fine. Adjust 3.3 release notes accordingly, so that CONFIG_SETTINGS_FILE_PATH will be used directly. This patch stops using deprecated CONFIG_SETTINGS_FS_DIR. There is actually no value in respecting it, as setting anything other than parent directory of CONFIG_SETTINGS_FS_FILE makes no sense. There is actually one use of CONFIG_SETTINGS_FILE_DIR in file backend tests, to derive directory for files containing tested settings. CONFIG_SETTINGS_FILE_PATH is not used there, so it makes little sense to derive directory name from it. Instead, just use hardcoded "/settings" subdirectory, as this was the default value of CONFIG_SETTINGS_FILE_DIR. Deriving parent directory can be done either in runtime or in buildtime (e.g. using some helper CMake function). Doing it in runtime however allows to create directory recursively (which this patch actually implements), e.g. for some more nested FS tree structure. Additionally it will simplify migration of settings configuration from Kconfig to device-tree (yet to be developed feature). Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>		2022-12-14 14:11:03 +01:00
..
boards	settings: file: drop CONFIG_SETTINGS_FILE_DIR	2022-12-14 14:11:03 +01:00
src	settings: file: change FS (or file system) wording to File	2022-11-24 09:36:31 +01:00
CMakeLists.txt
prj.conf
README.rst
sample.yaml	tests/samples: use integration_plaforms in more tests/samples	2022-11-29 16:03:23 +01:00

README.rst

.. _settings_subsys_sample:

Settings sample
###############

Overview
********

This is a simple application demonstrating use of the settings runtime
configuration module. In this application some configuration values are loaded
from persistent storage and exported to persistent storage using different
settings method. The example shows how to implement module handlers, how to
register them.

Requirements
************

* A board with settings support, for instance: nrf52840dk_nrf52840
* Or qemu_x86 target

Building and Running
********************

This sample can be found under :zephyr_file:`samples/subsys/settings` in
the Zephyr tree.

The sample can be build for several platforms, the following commands build the
application for the qemu_x86.

.. zephyr-app-commands::
   :zephyr-app: samples/subsys/settings
   :host-os: unix
   :board: qemu_x86
   :goals: run
   :compact:

After running the image to the board the output on the console shows the
settings manipulation messages.

Sample Output
=============

.. code-block:: console

   ***** Booting Zephyr OS build v2.1.0-rc1-123-g41091eb1d5e0 *****

   *** Settings usage example ***

   settings subsys initialization: OK.
   subtree <alpha> handler registered: OK
   subtree <alpha/beta> has static handler

   ##############
   # iteration 0
   ##############

   =================================================
   basic load and save using registered handlers

   load all key-value pairs using registered handlers
   loading all settings under <beta> handler is done
   loading all settings under <alpha> handler is done

   save <alpha/beta/voltage> key directly: OK.

   load <alpha/beta> key-value pairs using registered handlers
   <alpha/beta/voltage> = -3025
   loading all settings under <beta> handler is done

   save all key-value pairs using registered handlers
   export keys under <beta> handler
   export keys under <alpha> handler

   load all key-value pairs using registered handlers
   export keys under <beta> handler
   export keys under <alpha> handler

   =================================================
   loading subtree to destination provided by the caller

   direct load: <alpha/length/2>
   direct load: <alpha/length/1>
   direct load: <alpha/length>
     direct.length = 100
     direct.length_1 = 41
     direct.length_2 = 59

   =================================================
   Delete a key-value pair

   immediate load: OK.
     <alpha/length> value exist in the storage
   delete <alpha/length>: OK.
     Can't to load the <alpha/length> value as expected

   =================================================
   Service a key-value pair without dedicated handlers

   <gamma> = 0 (default)
   save <gamma> key directly: OK.
   ...