Serveur ESP32 : implémentation (4ème partie)

Serveur ESP32 : implémentation

(4ème partie)

Ceci est la suite des trois articles précédents :
Serveur ESP32 : implémentation
Serveur ESP32 : implémentation (2ème partie)
Serveur ESP32 : implementation (3eme-partie)

Dans cette 4ème partie nous allons parler des données.

Pour l'instant nous avons deux types de données :

• les fichier HTML dans la partition SPIFFS
• les données utilisateurs en RAM

Pour pouvoir enregistrer les données utilisateur en mémoire permanente il nous faudra un support de données non volatile, c'est à dire une mémoire qui ne sera pas vidée en cas de redémarrage du serveur ou de coupure secteur.

1. Une SD

L'espace mémoire d'une SD est énorme. A moins d'avoir à gérer un très grand nombre d'abonnés, ce n'est pas très judicieux. Cette solution nécessiterait un module SD. De plus mon expérience de la SD sur ARDUINO me laisse assez perplexe. La fiabilité n'est pas exceptionnelle, et dépend fortement de la SD.

2. EEPROM

L'EEPROM existant sur ARDUINO est émulée sur ESP32 dans un espace en mémoire FLASH appelé NVS (Non Volatile Storage).

Voici la table des partitions par défaut d'un ESP32 :

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x5000,
otadata,  data, ota,     0xe000,  0x2000,
app0,     app,  ota_0,   0x10000, 0x140000,
app1,     app,  ota_1,   0x150000,0x140000,
spiffs,   data, spiffs,  0x290000,0x170000,

On voit que cet espace a une taille de 0x5000 octets soit 20480 octets. C'est luxueux par rapport à un ARDUINO.

C'est un espace adressable directement, par adresse, sans notion de fichiers.
Cela convient-il ?
Oui, si le nombre d'abonnés est fixe.
Cela va nous obliger à partager l'espace disponible entre les différents abonnés. S'il y en a cinq au total cela permet d'avoir 4000 octets par abonné.
Un historique des opérations est envisagé, dans lequel chaque opération sera enregistrée avec une date et un libellé :

22/03/2020 16:33 : +10 credits

Une ligne ferait 30 caractères en moyenne.
Dans 4000 octets on pourrait enregistrer 133 lignes de 30 octets.
Cela pourrait convenir si les nombre d'opérations et d'abonnés est limité. Si l'on envisage 1 opération par mois et 10 abonnés, une année s'écoulera avant que notre espace soit saturé. C'est peu.

Mais le système que j'imagine a un nombre d'abonnés indéterminé. On peut en ajouter, en enlever. Cela ne semble pas optimal.

3. Fichiers SPIFFS

Cela semble une bonne solution. Nous disposons déjà d'un espace SPIFFS conséquent (voir la ligne spiffs dans la table des partitions).
Cet espace a une taille de 0x170000 octets soit 1507328 octets. C'est déjà beaucoup plus spacieux, et les données pourront être organisées :

• un fichier global contenant une ligne par abonné
• nom
• ID
• validité de la carte
• solde
• un fichier par abonné pour l'historique

Cet espace contient déjà les fichiers HTML, mais est-il utilisable pour nos données ?
Oui et non. On peut effectivement créer des fichiers mais ceux-ci disparaîtront lorsque nous devrons recharger les ressources HTML.
Pourquoi ? parce que le logiciel de chargement des données SPIFFS, le fameux "ESP32 Sketch Data Upload" vu dans la première partie, construit une image de partition contenant les fichiers HTML (ou autres) et la charge dans la FLASH de l'ESP32. Cette nouvelle partition écrase la première et nos précieux fichiers abonnés disparaissent.

4. Fichiers FAT

Il existe une solution pourtant, créer deux partitions :

• une partition dédiée aux ressources
• une partition dédiée aux données

Comment faire ? il faut créer une nouvelle table des partitions.
Et pendant que nous y sommes pourquoi ne pas adopter une partition FAT qui nous apportera plus de performances ?

Cette solution ne sera adaptée qu'à l'ESP32.

5. Plus d'espace

L'ESP32 n'est pas limité à 4Mo. Il existe des versions 16Mo pour des applications plus exigeantes.
Il est possible aussi d'utiliser un espace de stockage déporté, par exemple une RASPBERRY PI pourrait offrir les services d'un serveur HTTP permettant d'enregistrer et relire nos données grâce à une base MYSQL ou SQLITE.

Dans ce cas, on se demande s'il ne serait pas plus intéressant de brancher le lecteur RC522 directement sur la RASPBERRY PI. Après tout, le SPI fait partie de ses possibilités et le RC522 est supporté :
https://raspberry-lab.fr/Composants/Module-RFID-RC522-Raspberry-Francais/

Le seul intérêt de l'ESP32 dans ce cas est sa taille miniature.

6. Partitionnement

Nous allons maintenant examiner en détail la solution 4. Fichiers FAT.
Rappel : seul l'ESP32 pourra offrir cette possibilité.

Les différents schémas de partitionnement sont décrits dans des fichiers CSV situés dans le répertoire suivant :

Sous Linux :
/home/username/.arduino15/packages/esp32/hardware/esp32/1.0.4/tools/partitions

Sous OS X :
/Users/username/Library/Arduino15/packages/esp32/hardware/esp32/1.0.4/tools/partitions

Sous Windows :
C:\Users\username\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.4\tools\partitions

Voici le fichier default.csv :

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x5000,
otadata,  data, ota,     0xe000,  0x2000,
app0,     app,  ota_0,   0x10000, 0x140000,
app1,     app,  ota_1,   0x150000,0x140000,
spiffs,   data, spiffs,  0x290000,0x170000,

La partition SPIFFS démarre en 0x290000 et a une taille de 0x170000 octets.

Nous allons d'abord copier ce fichier en le nommant spiffs_fat.csv et puis nous allons le modifier :

# Name,   Type, SubType, Offset,  Size, Flags
nvs,      data, nvs,     0x9000,  0x5000,
otadata,  data, ota,     0xe000,  0x2000,
app0,     app,  ota_0,   0x10000, 0x140000,
app1,     app,  ota_1,   0x150000,0x140000,
spiffs,   data, spiffs,  0x290000,0x10000,
ffat,     data, fat,     0x2A0000,0x160000,

La partition SPIFFS a maintenant une taille de 0x10000 (64Ko), la partition FAT démarre donc en 0x290000 + 0x10000 = 0x2A0000. Elle a une taille de 0x170000 - 0x10000 soit 0x160000 octets.

64Ko seront plus que suffisants pour stocker nos fichiers HTML. L'espace FAT a quant à lui une taille de 0x160000 = 1441792 octets.
Dans cet espace on pourrait enregistrer 48059 lignes de 30 octets.
Si l'on envisage 1 opération par semaine et 10 abonnés, 92 années s'écouleront avant que notre espace soit saturé.

Nous sommes parfaitement à l'aise cette fois-ci.

Notre fichier spiffs_fat.csv est prêt. Il faut l'ajouter au fichier boards.txt dans le répertoire suivant :

Sous Linux :
/home/username/.arduino15/packages/esp32/hardware/esp32/1.0.4

Sous Windows :
C:\Users\username\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.4

Voici, en gras, ce qu'il faut ajouter :

esp32.menu.PartitionScheme.default=Default 4MB with spiffs (1.2MB APP/1.5MB SPIFFS)
esp32.menu.PartitionScheme.default.build.partitions=default
esp32.menu.PartitionScheme.defaultffat=Default 4MB with ffat (1.2MB APP/1.5MB FATFS)
esp32.menu.PartitionScheme.defaultffat.build.partitions=default_ffat
esp32.menu.PartitionScheme.defaultspiffs_fat=Default 4MB with spiffs+ffat (1.2MB APP/1.5MB SPIFFS64K+FAT)
esp32.menu.PartitionScheme.defaultspiffs_fat.build.partitions=spiffs_fat

Ensuite il faut recharger nos resssources HTML, car la partition SPIFFS n'est plus au même endroit en mémoire :

Menu "Outils / ESP32 Sketch Data Upload"

L'ESP32 redémarre et nous avons donc maintenant deux espaces SPIFFS et FAT.

REMARQUE : en cas de réinstallation de l'IDE, ces fichiers ne sont pas censés dispararaître, mais je conseille tout de même d'en conserver une copie dans le projet, au cas ou l'on serait contraint de faire une réinstallation totale.

7. Liens utiles

La suite :
Serveur ESP32 : implémentation (5eme-partie)
Serveur ESP32 : tests automatisés
Serveur ESP32 : tests automatisés (2ème partie)
Serveur ESP32 : implémentation (6eme-partie)

8. Conclusion

Nous sommes prêts à utiliser cette nouvelle partition FAT pour le stockage de nos données.
On peut essayer de jouer avec :
https://github.com/espressif/arduino-esp32/blob/master/libraries/FFat/examples/FFat_Test/FFat_Test.ino


Cordialement
Henri