Télécharger un fichier provenant d'un serveur ESP32

Bonjour à toutes et à tous,

En préambule, vous avez dû constater au travers d'autres posts que je suis ce qu'on appellera un "beginner" pour ce qui est de l'utilisation du WiFi et autres fonctions WEB.

A terme, mon idée est de réaliser un routeur photovoltaïque.

Dans cet appareil, une des fonctions consiste à envoyer des fichiers de données (que j'enregistre au fur et à mesure qu'elles arrivent dans une carte SD) vers un smartphone ou un PC.

C'est cette fonction qui m'intéresse ici. Mon idée est de transférer ces fichiers *.txt ou *.csv (qui ne sont jamais que des fichiers texte.

j'ai trouvé ce petit exemple qui devrait me le permettre :

#include "WiFi.h"
#include "SPIFFS.h"
#include "ESPAsyncWebServer.h"
 
  
const char* ssid = "yourNetworkName";
const char* password =  "yourNetworkPass";
  
AsyncWebServer server(80);
  
void setup(){
  Serial.begin(115200);
  
  if(!SPIFFS.begin()){
        Serial.println("An Error has occurred while mounting SPIFFS");
        return;
  }
  
  WiFi.begin(ssid, password);
  
  while (WiFi.status() != WL_CONNECTED) {
    delay(1000);
    Serial.println("Connecting to WiFi..");
  }
  
  Serial.println(WiFi.localIP());
  
  server.on("/download", HTTP_GET, [](AsyncWebServerRequest *request){
    request->send(SPIFFS, "/file.html", "text/html", true);
  });
   
  server.on("/interpret", HTTP_GET, [](AsyncWebServerRequest *request){
    request->send(SPIFFS, "/file.html", "text/html", false);
  });
  
  server.begin();
}
  
void loop(){}

Cela appelle plusieurs questions :

1 - Cela ne compile pas avec les erreurs suivantes :

e:\Arduino\libraries\ESPAsyncWebServer\src\WebAuthentication.cpp: In function 'bool getMD5(uint8_t*, uint16_t, char*)':
e:\Arduino\libraries\ESPAsyncWebServer\src\WebAuthentication.cpp:74:3: error: 'mbedtls_md5_starts_ret' was not declared in this scope; did you mean 'mbedtls_md5_starts'?
   74 |   mbedtls_md5_starts_ret(&_ctx);
      |   ^~~~~~~~~~~~~~~~~~~~~~
      |   mbedtls_md5_starts
e:\Arduino\libraries\ESPAsyncWebServer\src\WebAuthentication.cpp:75:3: error: 'mbedtls_md5_update_ret' was not declared in this scope; did you mean 'mbedtls_md5_update'?
   75 |   mbedtls_md5_update_ret(&_ctx, data, len);
      |   ^~~~~~~~~~~~~~~~~~~~~~
      |   mbedtls_md5_update
e:\Arduino\libraries\ESPAsyncWebServer\src\WebAuthentication.cpp:76:3: error: 'mbedtls_md5_finish_ret' was not declared in this scope; did you mean 'mbedtls_md5_finish'?
   76 |   mbedtls_md5_finish_ret(&_ctx, _buf);
      |   ^~~~~~~~~~~~~~~~~~~~~~
      |   mbedtls_md5_finish
Plusieurs bibliothèque trouvées pour "AsyncTCP.h"
  Utilisé: E:\Arduino\libraries\AsyncTCP
  Non utilisé: E:\Arduino\libraries\Async_TCP
exit status 1

Compilation error: exit status 1

J'ai oublié des bibliothèques, autres ? Que faire ?

2 - De ce que je comprends de ce sketch, la mémoire SPIFFS est utilisée comme intermédiaire. Est-ce que c'est fait automatiquement par la fonction send(SPIFFS, "/file.html", "text/html", false); Que doivent valoir les deuxième et troisième paramètres de cette fonction si mon fichier s'appelle par exemple mesDonnées.csv ?

3 - Par ailleurs, sur la vie du routeur, j'aurai à transférer plusieurs milliers de fichiers différents. Est-ce que la mémoire SPIFFS est faite pour ce genre de chose ?

Donnez-moi simplement des pistes. J'essaierai de me débrouiller.

Cordialement.

Pierre.

Je crains que non ...
Cf. Sauvegarder sur la mémoire Flash SPIFFS d'un ESP32 - § Considérations sur la durée de vie

SPIFFS est une des solutions pour loger un système de fichiers dans de la mémoire Flash, technologie de mémoire qui est relativement limitée en nombre d'effacements (plus limitée que la technologie EEPROM)

La doc du µC ou de la mémoire Flash SPI associée indique le nombre de cycles d'effacements (par secteurs nécessairement )

ex La mémoire Flash SPI 25Q32 SPI de Winbond souvent associée aux ESP32 est annoncée pour
image

C'est l'effacement qui est limitant , pas systématiquement l'écriture et encore moins la lecture d'une case mémoire

Mieux : SPIFFS intègre un peu de 'wear levelling' = gestion de répartition des écritures en cases mémoires afin de réduire le recours aux effacements de secteurs .
bémol : SPIFFS n'est plus maintenu depuis juillet 2017

Vois si tu peux le remplacer par LittleFS , maintenu et contenant un 'Wear levelling' un peu plus efficace que celui de SPIFFS

-> Avec SPIFFS, ou mieux, son successeur LIttleFS et leur 'wear levelling' le transfert de 'plusieurs milliers de fichiers différents pourrait passer ...... si la mémoire flash utilisée est annoncée avec > 100.000 cycles d'effacement de secteurs comme la Flash SPI 25Q32

SPIFFS ou LittleFS commenceront par 'étaler' les écritures dans la mémoire, occuper progressivement tous les secteurs avant de commencer à en effacer pour créer une zone vierge où l'écriture d'un ou plusieurs octets est possible

Quelles est la taille moyenne (en octets) des fichiers ?

Je n'en sais rien précisément actuellement. Disons 4 flottants sur 5 octets plus l'heure - la date pouvant être dans le nom du fichier - ça peut faire des données de 32 octets. Avec quelle répétition ? Si une minute, ça fait 2 ko / h. Après, je peux m'adapter aux spécificités de la mémoire. Faire des petits fichiers ou un gros .

Cordialement.

Pierre.

A la louche , sans tenir compte de tout....et si je ne me trompe pas ....

En supposant :
-que tes données occupent chacune 32 octets (nom de fichier inclus ?)
-que tu alloues à SPIFFS le quart de la mémoire Flash SPI (1Mosur 4 Mo)

tu peux écrire 128 données de 32 bits pour remplir un secteur (4kB)
tu disposes pour tes données en SPIFFS de 256 secteurs sur les 1024 de la mémoire W25Q32

tu peux loger 128 'données' dans un secteur (4096 octets)
tu disposes pour SPIFFS de 256 secteurs sur les 1024 (choix de partitionnement)
tu peux donc situer approximativement le nombre d'enregistrements de données qui occuperont la totalité des secteurs .....sans qu'un premier effacement de secteur ait été nécessaire -> 32768
Ave la cadence tu auras une idée du temps écoulé

Interviennent ensuite les effacements nécessaires pour libérer un à un des secteurs et les rendre 'inscriptibles'

Avec 100 000 effacements de secteurs garantis.......

Si je comprends bien, en utilisant 1 Mo de mémoire Flash, je peux y écrire 256 secteurs de 4096 octets.

Une fois tout rempli, je peux donc tout effacer et recommencer 100000 fois. Ce qui fait que, dans la durée, je peux écrire l'équivalent de 1 Mo x 100000.

Si je ramène ça à mon exploitation où j'envisage d'écrire 64 fois par heure des paquets de 32 octets, soit 2048 octets à l'heure, je pourrai faire fonctionner mon système :
1000000 x 100000 / 2048 = 48828125 heures, soit 5573 années

Ça ne devrait pas trop me poser de problème !

Maintenant, est-ce que c'est à moi de gérer ce processus ou bien y a-t-il un "wear leveling" inclus dans l'ESP32 ou dans la bibliothèque SPIFFS ou LittleFS ?

Par ailleurs, j'ai vu qu'on pouvait être en mode "Append" pour l'écriture. Mais y a-t-il des méthodes qui permettent de lire directement dans un gros fichier les données qui se trouvent à une position donnée, par exemple du 259143 ème octet au 265489 ème octet.

Cordialement.

Pierre.

pas dans l'ESP32 mais dans les deux bibliothèque , c''est indiqué dans leurs docs.
LitteFS en fait un peu plus en évitant par exemples des secteurs repérés défectueux

impossible , Windbond ne garantit que 20 années de conservation des données par ses SPI Flash

De plus Je ne suis pas certain de tout bien comprendre dans la doc des Flash SPI et le fonctionnement détaillé du wear leveling (= nivellement de l'usure) de SPIFFS et LittleFS
:exclamation:Une confirmation/infirmation par une personne bien informée serait la bienvenue !

A mon âge, même 20 ans seraient inespérés :wink:

Cordialement.

Pierre.

Il y a une solution ici :

Bonjour

À propos du wear-levelling sur ESP32

Voir aussi :

En résumé, le wear-levelling se fait au niveau de la partition concernée => juste en dessous du système de gestion de fichiers.

Cordialement.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.