Tryb konfiguracyjny i różne inputy do wprowadzania parametrów

[klew]

Tamte rzeczy nie mają raczej wpływu.
Logi!
Config jest przechowywany na littlefs, więc albo coś psuje tą partycję (jest to możliwe, gdy jednocześnie używa się czegoś na spifs). Może też się przepełniać (ten rozmiar co wcześniej pisaliśmy). Może też się coś crashować/resetować w trakcie zapisu pliku z config.
Z tego co pamiętam to nie ma tam odpowiednich zabezpieczeń.

[zzrr]

Tamte rzeczy nie mają raczej wpływu.
Logi!
Config jest przechowywany na littlefs, więc albo coś psuje tą partycję (jest to możliwe, gdy jednocześnie używa się czegoś na spifs). Może też się przepełniać (ten rozmiar co wcześniej pisaliśmy). Może też się coś crashować/resetować w trakcie zapisu pliku z config.
Z tego co pamiętam to nie ma tam odpowiednich zabezpieczeń.

Aha... od razu mi lepiej że wiemy co to może się dziać

[klew]

Tamte rzeczy nie mają raczej wpływu.
Logi!
Config jest przechowywany na littlefs, więc albo coś psuje tą partycję (jest to możliwe, gdy jednocześnie używa się czegoś na spifs). Może też się przepełniać (ten rozmiar co wcześniej pisaliśmy). Może też się coś crashować/resetować w trakcie zapisu pliku z config.
Z tego co pamiętam to nie ma tam odpowiednich zabezpieczeń.

Aha... od razu mi lepiej że wiemy co to może się dziać

Logi

[zzrr]

Logi

Logi... logi... to mam coś do tych logów ręcznie dopisać skoro w nich nic nie ma?

[klew]

Logi

Logi... logi... to mam coś do tych logów ręcznie dopisać skoro w nich nic nie ma?

Na razie dałeś tylko raz logi, gdzie nie występował problem. Logi trzeba zebrać tak, aby problem był tam widoczny. Bez tego to można sobie zgadywać

[zzrr]

@klew a powiedz...
w pliku littlefs_config.cpp platformIO podkreśla niezgodność zmiennych
w tej funkcji

Code: Select all

bool Supla::LittleFsConfig::getBlob(const char* key,
                                    char* value,
                                    size_t blobSize) {
  if (blobSize < BIG_BLOG_SIZE_TO_BE_STORED_IN_FILE) {
    return Supla::KeyValue::getBlob(key, value, blobSize);
  }

  if (!initLittleFs()) {
    return false;
  }

  char filename[50] = {};
  snprintf(filename, sizeof(filename), "/supla/%s", key);
  File file = LittleFS.open(filename, "r");
  if (!file) {
    SUPLA_LOG_ERROR("LittleFsConfig: failed to open blob file \"%s\" for read",
                    key);
    LittleFS.end();
    return false;
  }
  size_t fileSize = file.size();
  if (fileSize > blobSize) {
    SUPLA_LOG_ERROR("LittleFsConfig: blob file is too big");
    file.close();
    LittleFS.end();
    return false;
  }

  int bytesRead = file.read(reinterpret_cast<uint8_t*>(value), fileSize);

  file.close();
  LittleFS.end();
  return bytesRead == fileSize;
}

Czy to może mieć jakieś znaczenie że bytesRead jest int a fileSize size_t ? Może się coś przez to dziać? Do tej pory ignorowałem ten komunikat. Jak zmieniłem tak dla próby bytesRead też na size_t to komunikatu już nie było. Ale finalnie nie zmieniłem żeby coś nie popsuć.

[klew]

@klew a powiedz...
w pliku littlefs_config.cpp platformIO podkreśla niezgodność zmiennych
w tej funkcji

Code: Select all

bool Supla::LittleFsConfig::getBlob(const char* key,
                                    char* value,
                                    size_t blobSize) {
  if (blobSize < BIG_BLOG_SIZE_TO_BE_STORED_IN_FILE) {
    return Supla::KeyValue::getBlob(key, value, blobSize);
  }

  if (!initLittleFs()) {
    return false;
  }

  char filename[50] = {};
  snprintf(filename, sizeof(filename), "/supla/%s", key);
  File file = LittleFS.open(filename, "r");
  if (!file) {
    SUPLA_LOG_ERROR("LittleFsConfig: failed to open blob file \"%s\" for read",
                    key);
    LittleFS.end();
    return false;
  }
  size_t fileSize = file.size();
  if (fileSize > blobSize) {
    SUPLA_LOG_ERROR("LittleFsConfig: blob file is too big");
    file.close();
    LittleFS.end();
    return false;
  }

  int bytesRead = file.read(reinterpret_cast<uint8_t*>(value), fileSize);

  file.close();
  LittleFS.end();
  return bytesRead == fileSize;
}

Czy to może mieć jakieś znaczenie że bytesRead jest int a fileSize size_t ? Może się coś przez to dziać? Do tej pory ignorowałem ten komunikat. Jak zmieniłem tak dla próby bytesRead też na size_t to komunikatu już nie było. Ale finalnie nie zmieniłem żeby coś nie popsuć.

To nie ma wpływu na problem, który masz

[zzrr]

To nie ma wpływu na problem, który masz

Dodałem kilka deleyów w setup żeby się wszystko spokojnie poładowało. Ale na tą chwile to jestem skłonny stwierdzić że przyczyną był zły kontakt pinów na płytce stykowej. Co prawda nie udało się powtórzyć skasowania flasha jak na razie ale przy którejś tam próbie włączenia i wyłączania zasilania zauważyłem takie drgania diody stanu na WEMOSIE. Poprawiłem styki na ile się dało, dioda zaczęła świecić mocniej i jednostajną siłą i zobaczymy. Jak układ wyląduje już na PCB i będzie wszystko na sztywno to wtedy dopiero potestuję. Na razie odpuszczam bo może szkoda mojego czasu póki to jest wszystko na pajęczynie. Na razie @klew dzięki.
Aaa jeszcze coś bardzo ważnego... Odpaliłem PuTTY i logi idą do pliku. "Będzie Pan zadowolony" za tydzień wracam, powinno starczyć. Oby dysku starczyło...

[vajera]

Mam pytanie o oficjalną politykę zapisu własnych danych w ekosystemie SuplaDevice.

Pisząc po ludzku - mam np. 32 bitową wartość, którą chcę wczytywać przy starcie z flasha, modyfikować w trakcie pracy programu i zapisywać po każdej zmianie.
Czy mogę do tego wykorzystać klasę LittleFsConfig i funkcje setInt32/getInt32? A może Eeprom - ale jak - tworząc własną sekcję?
Czy klasycznie - odpalać klasę Eeprom np. z offsetem 128 bajtów i zapisywać swoje dane w tych pierwszych 128 bajtach EEPROM?

[klew]

Mam pytanie o oficjalną politykę zapisu własnych danych w ekosystemie SuplaDevice.

Pisząc po ludzku - mam np. 32 bitową wartość, którą chcę wczytywać przy starcie z flasha, modyfikować w trakcie pracy programu i zapisywać po każdej zmianie.
Czy mogę do tego wykorzystać klasę LittleFsConfig i funkcje setInt32/getInt32? A może Eeprom - ale jak - tworząc własną sekcję?
Czy klasycznie - odpalać klasę Eeprom np. z offsetem 128 bajtów i zapisywać swoje dane w tych pierwszych 128 bajtach EEPROM?

Tu nie ma żadnej polityki . To Twoje urządzenie i rób sobie na nim co Ci się podoba

Możesz wykorzystywać dowolne mechanizmy zapisywania danych we flashu, o ile nie będą one kolidowały z tym co robi biblioteka.
Także jeśli używasz LittleFsConfig, to możesz z niej korzystać i zapisywać tam dane w posatci klucz(15 znaków ASCII)->wartość (int8, int32, char[], "blob"). Trzeba pamiętać, aby nazwa nie kolidowała z kluczami, używanymi w s-d. Dodatkowo użycie w takiej sytuacji spifs wszystko rozwali ;P. Także albo little fs, albo spifs. Na little fs możesz też zapisywać własne pliki z danymi. Tam jest dość sporo miejsca, zapis robi jakiś wear leveling. Przy LittleFsConfig trzeba też pilnować, aby config nie zrobił się zbyt duży. Domyślnie trzyma on 1000 B, ale już jeden kanał HVAC (termostat) zjadał kilkaset bajtów configa.
Możęsz też używać tej emulacji EEPROM. Jego zaleta to prostota. Wtedy wystarczy Supla::Storage ustawić z odpowiednim offsetem pisanie do EEPROMu w adresach ponizżej tego offsetu będzie bezpieczne. Tylko EEPROM chyba (?) nie robił wear levelingu, więc ostrożnie z ilością zapisów.