Yboichuk/sdk/nvs config

[black-ghost-off]

Add support for save and read config from nvs for keira OS

Now setting have only one field, named as "language", but here we can story any what for save from boot to boot

` lilka::Configuration config;

// Load the configuration
lilka::loadConfiguration(config);

// Print the language from the configuration
Serial.print("Current language: ");
Serial.println(config.language);`

[and3rson]

Не впевнений, чи варто це робити, бо в нас вже є Preferences, а додаткова абстракція поверх нього - це додаткові потенційні проблеми. Наприклад, reinterpret_cast<const char*>(&config), sizeof(Configuration)) поламається, якщо зміниться структура Configuration. Краще вже всі налаштування зберігати окремими ключами в неймспейсі keira.

[black-ghost-off]

Покажи де то вже використовується, бо я ще не бачив нині?

[black-ghost-off]

@and3rson , я вважаю що network preferences і ftp потрібно винести в одне і якщо вдруг все попливе по налаштуваннях, то завжди можна викликати функцію з абрстракції setDefaultConfiguration()

p.s. Як варіант робити бекап і вигружати все в INI файл в SD карту, або SPIFFS і звідти ж завантажувати

[and3rson]

@black-ghost-off оскільки Preferences не вміє отримувати список всіх ключів або всіх неймспейсів, можливо і справді є сенс тримати все в одному неймспейсі - keira. Це дозволить нам просто дропнути весь неймспейс.
Але Ця зміна має бути в Кірі, оскільки бібліотека lilka не має перекладів чи конфігурацій, вона - лише такий собі HAL для Лілки.
TL;DR: Думаю, варто заімплементити це на рівні Кіри - наприклад, зробити так:

// keiraprefs.h
#pragma once

#include <Preferences.h>

class KeiraPrefs : public Preferences {
    KeiraPrefs(bool readOnly);
}

KeiraPrefs::KeiraPrefs(bool readOnly) : Preferences("keira", readOnly) {}

...і тоді по всього проєкту keira замітити Preferences prefs("...", ro) на KeiraPrefs prefs(ro)

Інший варіант - зробити в Кірі якийсь config.h, який визначить ключ KEIRA_PREFS_NS, і тоді робити всюди таке:

Preferences prefs(KEIRA_PREFS_NS, ro);

Але перший варіант дозволить нам додати якісь додаткові методи - скажімо, factoryReset(), чи якийсь кастомний механізм лістінгу ключів, чи гетери/сетери для кастомних типів.