NVS umpartitionieren - wie umsetzen?

Wir hatten hier vor längerer Zeit mal das Thema, dass jmd. berichtet hatte, dass sein NVS zum Lernen der RFIDs voll ist. Nun ist das Thema mit einem neuen Partitions-Layout ja vergleichsweise einfach umzusetzen, aber es hat auch Impact. Und zwar derart, dass wenn ich das Layout ändere, dass das NVS dann überschrieben wird und damit auch die bisherigen Zuweisungen und Konfigurationen. Man hat dann zwar noch die backup.txt, aber ich denke viele Leute werden das ggf. nicht wissen und werden einigermaßen stinkig sein, dass offenbar nix mehr funktioniert.

Habt ihr vielleicht Ideen, wie man das mit möglichst wenig Bauchweh umsetzen kann? Mir schwebt vor, es vielleicht mit dem neuen Refactoring.Branch umzusetzen. Das macht es ggf. etwas einfacher, weil sich ja eh noch andere Sachen ändern. Dann sind die Benutzer vielleicht eher drauf vorbereitet.

Gibts ne Möglichkeit, das beim Umpartitionieren auf dem Rechner zwischenzuspeichern und dann wieder hochzuladen, als script beim Upload.
so:
-Abfrage NVS Layout
-Falls alt → Inhalt runterladen
- Umpartitionierung
- Inhalt Upload
-Weiter mit normalem Build/Upload

Könnte vermutlich mit der Funktion nvs_get_stats gehen. Aber das Problem ist halt, dass das Umpartitionieren ja vorgelagert gemacht wird und nicht erst beim Start.

Ich denke ich werde den Benutzer irgendwie warnen müssen.

Das sollte doch reichen , Backup und Restore ist doch einfach geworden . Dann kann auch jeder die Gelegenheit nutzen seine Einträge im NVS zu überprüfen und ggf. „Leichen“ entfernen .
Wobei wir wieder bei unserem Thema " sauberes Backup " sind . :wink:
VG

Ich habe das auch nicht vergessen und extra nochmal in meine ToDo-Liste aufgenommen: ESPuino · GitHub

Irgendwann wird’s kommen, hehe.

So, für ein 4 MB großes Flash (das haben alle ESP32-WROOM, der ESP-A1S und manche ESP32-WROVER habe ich nun folgendes Partitions-Layout festgelegt:

app0, app, factory, 0x10000, 0x3B0000,
nvs, data, nvs, , 0x40000,

D.h. die Firmware darf maximal 3.866.624 Bytes groß sein und das NVS hat 256 kB (normalerweise sind es 24 kB). OTA wird es hier also nicht geben, dafür reicht der Speicher nicht (zumindest mal dann, wenn Bluetooth aktiviert ist).

Ich wollte jetzt mal für die ESP32-WROVER mit 16 MB Flash das Partitionslayout zur Disposition stellen. Also im Grunde tut es meiner das hier: arduino-esp32/default_16MB.csv at 21947ebe76cf6380fe06aa885390b86cc477709a · espressif/arduino-esp32 · GitHub
Allerdings brauchen wir ein größes NVS. Das würde ich dann vom SPIFFs abziehen. Ob SPIFFS jemals gebraucht wird ist unklar, aber für OTA sollten 6.5MB pro OTA-Partition ja dicke reichen.

Hat jmd. von euch eine Meinung dazu?

EDIT: Bin mir gerade nicht sicher, ob ESP32-A1S wirklich 4 MB oder 16 MB Flash hat. Kann wer dazu was sagen?

Hat 4MB , Datenblatt von Espressif stimmt da nicht

Ich habe meinen Wrover 16 MB ( kosten nur 3,21 € je Chip , also warum geizen) mal zum Test so partitioniert , ohne recht zu wissen was ich da mache. War zu faul das alles zu lesen und wollte nur mal schnell OTA testen. Funktioniert .

Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x5000,
otadata, data, ota, 0xe000, 0x2000,
app0, app, ota_0, 0x10000, 0x2F0000,

Ist der überhaupt von Espressif? Dachte immer der sei von AI Tinker.
Aber danke für die Info.

Der Espuino könnte beim Start das Backup von der SD Karte selbstständig wieder einspielen, wenn er merkt, dass noch keine Karten konfiguriert sind. Dann würden nach der Änderung des Partitionsschema zumindest die Karten wieder funktionieren. Um festzustellen, ob Karten konfiguriert sind, könnte man einen speziellen Schlüssel im NVS speichern. Ist dieser vorhanden, wird beim Start das Backup nicht eingespielt.

Meint ihr denn, dass so häufig die Software aktualisiert wird, nachdem ein Espuino erst mal in Betrieb gegangen ist? Ich habe zumindest meine beiden seit Inbetriebnahme nicht mehr aktualisiert, da sie sehr gut funktionieren.

Hast recht , ich hatte diese Übersicht .
Die 4MB werden beim Flashen angezeigt

Na ab und an wird es schon mal ne Aktualisierung geben für ein neues Feature oder vielleicht auch mal einen Bugfix. Ob ein Benutzer das dann einspielt, obliegt ihm natürlich selbst, hehe. Aber ich kann das schon verstehen: Die ESPuinos meiner Kinder aktualisiere ich auch nur alle paar Monate mal.

Die restlichen Einstellungen sind halt weg - WLAN-Zugang zum Beispiel. Ich bin derzeit am überlegen, ob ich hier eine zweisprachige Anleitung schreibe und den Link dann in einer fetten Warnung nach dem Flashen verlinke. Die Warnung zeige ich, keine Ahnung, vielleicht 10mal nach dem Booten an.

Zur Vollständigkeit hier:

16MB custom: ESPuino/custom_16mb_ota.csv at 10555b16fb2da285e9df5b9cf4e3d4ea30c627cf · biologist79/ESPuino · GitHub
4 MB custom: ESPuino/custom_4mb_noota.csv at 10555b16fb2da285e9df5b9cf4e3d4ea30c627cf · biologist79/ESPuino · GitHub

16 MB:

  • Zwei OTA-Partitionen mit jeweils 6.5 MB => OTA ist also möglich, aber wird aktuell von ESPuino noch nicht unterstützt
  • SPIFFs vorhanden, nutzt ESPuino jedoch nicht
  • 256 kB NVS (anstelle 20 kB)

4 MB:

  • Eine App-Partition mit 3.8 MB => OTA ist nicht möglich
  • kein SPIFFs
  • 256 kB NVS (anstelle 20 kB)

Alle Boards, die einen WROOM besitzen, habe ich via platformio.ini auf das 4er-Profil gesetzt. Dann weiterhin den TTGO T8 und den ESP32-A1S. Meines Wissens haben die nur 4 MB Flash, aber korrigiert mich gerne. Nur dem Lolin D32 pro habe ich das 16er-Profil spendiert.

Was die Sache etwas erschwert ist z.B., dass es den Lolin D32 pro auch mit 4 MB gibt. Ich warte jetzt aber einfach mal ab, wie sich das so entwickelt. Stand jetzt hat man mit 4 MB auf jeden Fall keinen Nachteil, da die Applikation deutlich kleiner als 3.8 MB ist und OTA bislang noch nicht integriert ist. Aber mit 16 MB könnte ich das mal angehen, ist nicht arg viel Arbeit.

Wichtig:
Man man zwischen Partitions-Profilen wechselt, dann wird das NVS gelöscht. Ergo muss dann das hier beachtet werden: 📗 Wechsel zum Refactoring-Branch: Was ist zu beachten?

Falls es Probleme gibt, dann teilt mir das gerne mit.