Add `yd_esp32` board:
- Model name: YD-ESP32
- Manufacturer: VCC-GND® Studio
- Espressif module: ESP32-WROOM-32E
Signed-off-by: Julio Cesar <hi@jcsx.dev>
Remove virtual esp32 board and replace it with the
real word boards:
- esp32_devkitc_wroom
- esp32_devkitc_wrover (with PSRAM option)
Signed-off-by: Marek Matej <marek.matej@espressif.com>
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>
Currently there is inconsistency in repository file names, APIs, Kconfig
options and documentation around file / file-system backend for settings
storage, as both "file" and "FS (file system)" are used. As an example,
there is `CONFIG_SETTINGS_FS` Kconfig option, but the file that implements
this settings backend is called `settings_file.c`. Another example are
names of static functions that implement settings storage API:
`settings_file_load()`, `settings_file_save()` and
`settings_fs_storage_get()`.
This backend is actually storing all settings in a single file, so it makes
sense to use "File" as the name of backend, instead of a more general
"FS" (which would make sense if several files would be used to store
settings).
Fix inconsistency in used wording in the tree and unify it to "settings
file backend". This naming is more precise to how the implementation looks.
It will also make it easier to grep through the codebase and analyze
existing code.
Deprecate settings_mount_fs_backend() function and all Kconfig options
starting with `CONFIG_SETTINGS_FS`.
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
In the flash partition definitions for ARM boards,
the link to the legacy partition macros does not
exist any more. The commit cleans up the partition
definition by removing this link.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
The board name for the nRF52 DK, so far known as nrf52_pca10040, is
renamed to nrf52dk_nrf52832. Its documentation and all references
to its name in the tree are updated accordingly. Overlay and
configuration files specific to this board are also renamed, to
match the new board name.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The nRF52840 DK board target, so far known as nrf52840_pca10056,
is renamed to nrf52840dk_nrf52840.
Its documentation and all references to its name in the tree are
updated accordingly. Overlay and configuration files specific to
this board are also renamed, to match the new board name.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
Added support for native_posix targets.
Added setting FS back-end initialization which is used by
native_posix targets.
The test harness was adapted to the fact that key-value pairs
read-out order might be different for each back-end when call
settings_load().
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Added sample for the settings subsystem.
The sample shows how to:
-initialize and register handler
-implement handles
-save and load data using registered handlers
-load subtree
-save or delete a certain value
-load subtree values or a value directly
- example on how to write data to the
setting destination and how to read data
from the setting destination using runtime API.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
