Discussion :

[Jay M]

Hervé, j'ai repris le tuto et tes codes pour l'adapter à un DevKit ESP32

JOLI !

[naute]

Salut Fabien .

j'ai repris le tuto et tes codes pour l'adapter à un DevKit ESP32

Je n'ai pas encore utilisé l'ESP32, essentiellement parce que je n'ai pas besoin, dans mon contexte, d'autant de capacités ni de fonctionnalités. Les ESP-01 sont en général suffisants et quand il me faut un peu plus de GPIO, un NodeMCU ou un Nano (en fonction des besoins) fait l'affaire.
Cela dit, la lecture de ton article en relecture m'a donné envie d'essayer, mais dans l'environnement Arduino, et j'en ai donc commandé un. Par contre, comme il vient à dos de pangolin ( ), il va me falloir être patient, ce qui n'est pas un problème.

Les fichiers html, css, js et images sont en mémoire Flash grâce au système de fichiers SPIFFS.

J'utilise également ce procédé dans un petit article en relecture, mais j'utilise le système de fichier LittleFS à la place du SPIFFS car celui-ci semble en fin de vie .

J'ouvrirai une discussion pour détailler tout ça

Comme ça, quand je recevrai mon colis, j'aurai tous les renseignements nécessaires .

Amicalement,
Hervé

[Jay M]

J'utilise également ce procédé dans un petit article en relecture, mais j'utilise le système de fichier LittleFS à la place du SPIFFS car celui-ci semble en fin de vie

effectivement, SPIFFS sera déprécié en faveur de LittleFS.

Passer de SPIFFS à LittleFS est une migration assez facile. Vous remplacez simplement toutes les occurrences de SPIFFS par LittleFS dans votre code.

Cependant pour les projets déjà en production, si vous avez des données en mémoire, la partition sera re-formatée et donc les données perdues. Il n'y a aucune procédure pour transformer un SPIFFS déjà existant en LittleFS ==> faudra prévoir une solution d'extraction/migration.

[naute]

Passer de SPIFFS à LittleFS est une migration assez facile.

Certes, mais :

Vous remplacez simplement toutes les occurrences de SPIFFS par LittleFS dans votre code.

n'est pas tout à fait suffisant. Il faut également remplacer :

Code arduino :

Sélectionner tout - Visualiser dans une fenêtre à part

#include "FS.h"  // Déclaration de SPIFFS

par :

Code arduino :

Sélectionner tout - Visualiser dans une fenêtre à part

#include "LittleFS.h"  // Déclaration de LittleFS

ce qui n'est pas non plus bien compliqué .

[Jay M]

Effectivement !!!

[f-leb]

Merci du tuyau, ma pt'ite contribution est mise à jour

[...] Cette version V0.3 utilise donc le nouveau système LittleFS.
Si vous souhaitez conserver le système SPIFFS, il suffit de mettre en commentaire la ligne suivante dans le fichier HandleWebServer.h :

Code arduino :

Sélectionner tout - Visualiser dans une fenêtre à part

#define USE_LittleFS

(Les deux systèmes peuvent cohabiter dans l'EDI Arduino. Bien entendu, pour un projet donné, il faudra utiliser l'un ou l'autre).

[Artemus24]

Salut à tous

Un grand à Naute pour son travail !

J'utilise également ce procédé dans un petit article en relecture, mais j'utilise le système de fichier LittleFS à la place du SPIFFS car celui-ci semble en fin de vie.

Qui décrète que telle ou telle bibliothèque est dépréciée ?
Tant qu'elle est disponible au chargement , je ne vois pas pourquoi il faudrait sans abstenir.
Maintenant si c'est un fork, cela n'engage que son nouvel auteur du bien fondé de son travail.

Une remarque au sujet de ce tableau qui l'on trouve dans ce lien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
+------------+----------------+-----------------+
| Filesystem | Read time [ms] | Write time [ms] |
+------------+----------------+-----------------+
|     FAT    |       276      |      14 493     |
|   SPIFFS   |       767      |      65 622     |
|  LITTLEFS  |       916      |      16 200     |
+------------+----------------+-----------------+

A bien comprendre, l'écriture serait plus performante en utilisant LittleFS qu'avec SPIFFS.
Je veux bien, mais si vous passez votre temps à écrire, votre mémoire flash risque de ne pas s'en remettre.
C'est le même genre de remarque que l'on fait avec la raspberry pi, quand on utilise les cartes Micro SD en écriture.

Pour ma part, j'ai aussi développé mon petit projet quand j'ai découvert la version de f-leb.
Au lieu d'écrire et d'envoyer à nouveau la page web, à chaque modification de son contenu, je gère cela en AJAX.
C'est avant tout, le respect de la mémoire de mon NodeMCU ESP32 que j'essaye de préserver au mieux.

Comment faire ?

Coté javascript, j'ai ce programme :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
function getData(reqt)
{
	var ObjetXHR = new XMLHttpRequest();
 
	ObjetXHR.onreadystatechange = function()
	{
		if (this.readyState == 4  && this.status == 200)
		{
			var obj    = JSON.parse(this.response);
			var nodeBt = document.getElementsByTagName("button");
			var nodeSp = document.getElementsByTagName("span");
 
			for (var i=0; i<nodeBt.length; i++)
			{
				nodeBt[i].innerHTML = obj.bt[i];
				nodeBt[i].setAttribute("class",obj.bt[i]);
			}
 
			for (var i=0; i<nodeSp.length; i++)
			{
				nodeSp[i].innerHTML = obj.sp[i];
				nodeSp[i].setAttribute("class",obj.sp[i]);
			}
		}
	}
 
	ObjetXHR.open("GET", reqt , true);
	ObjetXHR.send(null);
}
 
window.onload = function()
{
	var node = document.getElementsByTagName("button");
 
	for (var i=0; i<node.length; i++)
		node[i].onclick = function () { getData("ajax?val="+this.id); }
 
	setInterval(function () {getData("ajax");}, 500);
}

Je n'ai utilisé aucune balise javascript dans le code HTML, hormis celle qui fait référence à "script.js". Tout ce fait dans ce script Javascript.

Toutes les 1/2 secondes, je récupère une chaîne JSON à partir d'une transmission de l'url "/ajax".
La chaîne JSON est en fait deux tableaux, dont le premier concerne la valeur de mes boutons (button) et le second, l'affichage des informations (span).
Pour résoudre ce problème, j'utilise exclusivement les balise "<button>" et "<span>" pour gérer mes deux tableaux.

Quand je modifie l'état d'un de mes boutons, j'envoie juste la valeur du bouton qui a été pressée (/ajax/val=?).
Cette valeur est identifié par son "id". J'aurai pu mettre "value" à la place.

Quant à la chaîne JSON, je ne passe pas par les #include" que je trouve totalement inutile.
En une seule ligne (celle qui est en rouge), je gère la structure de la chaîne JSON et son envoie.
A titre d'exemple, voici comment je gère le handle "/ajax".

Code arduino :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
void handle_ajax(AsyncWebServerRequest *request)
{
	short _val;

	if (request->hasParam("val"))
	{
		AsyncWebParameter *p = request->getParam("val");
		_val = p->value().toInt();
		keys(_val);
	}
	else
	{
		infos();
	}

	request->send(200, "application/json", "{\"bt\":[\"" + _v01 + "\",\"" + _v02 + "\", \"" + _v03 + "\", \"" + _v04 + "\", \"" + _v05 + "\"], \"sp\":[\"" + _v06 + "\", \"" + _v07 + "\", \"" + _v08 + "\", \"" + _v09 + "\"]}");
}

Comme ce sont deux tableaux, leur indiçage se fait en commençant par zéro.
C'est pourquoi en Javascript, la variable "i" parcourt le nombre des balises "<button>" (premier tableau au nombre de cinq éléments) et le nombre des balises "<span>" (second tableau au nombre de quatre éléments).
La position des balises n'a aucune importance dans la page web. Il faut juste respecter l'ordre ainsi que le nombre de balise.

Avec cette astuce, l'écriture se fait à chaque rafraîchissement de la page web et non à chaque transfert de données.

Après cette remarque, j'en vient à ma question : existe-t-il une version LittleFS pour "espressif NodeMCU ESP32" ?
F-leb m'a communiqué le lien vers arduino, que j'ai testé et cela ne fonctionne pas chez moi, ou bin j'ai dû mal faire l'adaptation de mon programme.

@+

[Jay M]

Qui décrète que telle ou telle bibliothèque est dépréciée ?
Tant qu'elle est disponible au chargement , je ne vois pas pourquoi il faudrait sans abstenir.
Maintenant si c'est un fork, cela n'engage que son nouvel auteur du bien fondé de son travail.

jetez un oeil à ce fil de discussion (par Peter Andersson le développeur de la version SPIFFS / Arduino). à la fin (le 6 Sep 2019) il dit

No, not working on it now. My spare time is too sparse for this nowadays. Not saying I'll never return to it though.

Ensuite il y a eu des discussions sur ce qui est mis en standard dans le Arduino core for ESP8266

https://github.com/esp8266/Arduino/issues/7095

@Jason2866 @TD-er maintenance on our side for libs that aren't active is a load we're not willing to have.
To be clear, this issue covers deprecation, not pulling out. Think of it as a "first notice". Worst case for you we deprecate for 2.7.0 and pull out for 3.0.0, so even in that case there is time.

et il propose 3 options

You have three alternatives to pursue, not mutually exclusive:

Find a migration strategy. At top level, there is no difference between the two file systems i. e. same fs class, so api is the same. Then the only question is how to migrate existing spiffs file systems (e. g. copy files somewhere?)
Get the "other repos" to implement and support littlefs
Find maintainers/developers for the spiffs lib. Having the spiffs code reactivate is the one thing that would stop our deprecation.

==> en gros si personne ne veut maintenir ce code, il sera viré de la distribution en 3.0 (on est en 2.7.2) mais rien ne vous empêche de récupérer le code de Peter Andersson est d'essayer de le réinstaller. Il se peut qu'il y ait des incompatibilités cependant puisque les développeurs du Arduino core ne feront rien de particulier pour la tester. (mais rien de particulier pour la casser non plus on peut espérer)

[Artemus24]

Salut Jay M.

Merci pour ces précisions.
Je suppose qu'il s'agit de la communauté Arduino.
Il y a quelque chose dans ces propos que je ne comprends pas, mais quoi ?

Déprécier signifie "Diminuer la valeur de quelque chose".
Cela ne rend pas le logiciel non fonctionnel, même dans dix ans, si je l'utilise sur le même ESP32.
Mais si la question est d'ordre évolutif, en quoi cela pose problème ?
Tant que cela fonctionne, je ne vois pas où se trouve le problème.

J'ai l'impression que la communauté Arduino applique une censure.
Pourquoi déprécier le travail de quelque d'autre ?

Je constate aussi qu'il y a une multitude d'exemples sur le net, en SPIFFS qui vont devoir basculer vers LITTLEFS.
Comme cela ne se fera pas, on aura un gros problème de lisibilité de ces exemples.

==> en gros si personne ne veut maintenir ce code, il sera viré de la distribution en 3.0 (on est en 2.7.2)

Si je comprends bien, 2.7.2 concerne l'ESP8266.
Quand est-il de l'ESP32 (puisque j'utilise espressif NodeMCU ESP32) qui est dans la version 1.0.4 ?

@+

[naute]

Bonjour .

Déprécier signifie "Diminuer la valeur de quelque chose".

Il s'agit surtout d'un problème de traduction : encore un coup des faux amis !

• to deprecate signifie "désapprouver", et dans certains cas "déconseiller" (c'est le cas ici) ;
• to depreciate signifie "déprécier".

Ça ne veut pas dire la même chose .

Donc :

J'ai l'impression que la communauté Arduino applique une censure.
Pourquoi déprécier le travail de quelque d'autre ?

résulte d'un contresens : la communauté Arduino ne dénigre pas SPIFFS, elle "déconseille" simplement son utilisation en raison de grosses incertitudes quant à son avenir. Par conséquent, et par cohérence, elle n'intégrera plus cette bibliothèque. Libre à chacun de l'utiliser.

Je constate aussi qu'il y a une multitude d'exemples sur le net, en SPIFFS qui vont devoir basculer vers LITTLEFS.
Comme cela ne se fera pas, on aura un gros problème de lisibilité de ces exemples.

C'est justement l'une des raisons pour lesquelles, dans mon tuto, j'ai opté pour LittleFS alors que j'utilisais SPIFFS jusqu'à présent. Question de pérennité.

Si je comprends bien, 2.7.2 concerne l'ESP8266.

et uniquement l'ESP8266. Les bibliothèques sont liées à la plateforme.

Quand est-il de l'ESP32 (puisque j'utilise espressif NodeMCU ESP32) qui est dans la version 1.0.4 ?

Ici, je suis moins sûr de moi car je n'ai pas encore utilisé l'ESP-32, mais au vu des exemples fournis dans l'EDI Arduino, le système de fichier LittleFS ne "semble pas" (prudence) encore porté "officiellement" sur cette plateforme. Cela dit, le système SPIFFS fonctionne très bien et continuera à fonctionner comme actuellement, du moins jusqu'à la mise à jour fatidique du gestionnaire dans laquelle cette bibliothèque sera supprimée, et je ne vois pas ce qui pourrait empêcher de l'utiliser. On peut toujours garder une version de l'EDI dans laquelle on conserverait des fonctionnalités non maintenues mais que l'on souhaite toujours utiliser.
De toute manière, il y a fort à parier que la suppression du support du SPIFFS sur cette plateforme n'interviendra pas avant que le support officiel de LittleFS ne soit opérationnel. À partir de là, la migration sera facile.

Je veux bien, mais si vous passez votre temps à écrire, votre mémoire flash risque de ne pas s'en remettre.

Techniquement, mis à part pendant la période de développement et pour les éventuelles mises à jour, je n'écris qu'une fois dans la mémoire flash. Les fichiers ne sont pas modifiés par le sketch, et sont simplement lus à chaque connexion. Ma mémoire flash n'est donc pas vraiment stressée.

Amicalement,
naute

[Jay M]

Sur l’ESP32 il y a des fonctions au niveau OS qui gèrent les file systems

Il y a FarFS qui permet d’avoir une interface unifiée entre stockage interne ou externe et on peut déclarer des partitions

Cf Storage API => https://docs.espressif.com/projects/...age/index.html

[Artemus24]

Salut à tous

Par conséquent, et par cohérence, elle n'intégrera plus cette bibliothèque. Libre à chacun de l'utiliser.

Les bibliothèques sont liées à la plateforme.

Je crois avoir compris ce que je ne comprenais pas.
Il s'agit de conserver ou pas cette bibliothèque dans le noyau de la plateforme utiliséee et non d'éradiquer la bibliothèque par elle-même.
On peut continuer à se servir de cette bibliothèque, même si elle n'intègre plus officiellement le noyau de la plateforme utilisée.

Si c'est ça, je comprends mieux le problème.

Une même bibliothèque ne fonctionne pas sur toutes les plateformes.
Ce qui veut dire, qu'il existe autant de versions de la même bibliothèque qu'il existe de plateforme. Bonjour la maintenance !
Du coup, LITTLEFS a exactement le même problème, tant qu'une âme charitable fera la maintenance.

Et si je comprends le bordel ambiant, il y a autant de versions (par exemple FS : file system) qu'il y a de gens qui s'y intéresse.
Combien de déclinaisons a-t-on de FS ? SPIFFS, LITTLEFS, FatFS, ...

Question de pérennité.

Pérennité à propos de quoi ? De la mémoire flash ou de la bibliothèque ?

le système de fichier LittleFS ne "semble pas" (prudence) encore porté "officiellement" sur cette plateforme.

Actuellement, dans espressif ESP32, il n'y a pas LITTLEFS. J'ai dû l'installer, avec l'aide de f-leb.

Cela fait un mois que je découvre l'ESP32. Je suis en retard vis-à-vis de vos connaissances sur les micro-contrôleurs.
Hormis l'ESP32, je possède plusieurs raspberry pi et un bus pirate.

Comment se nomme le langage qui est utilisé dans l'ESP32 ? Je suppose l'arduino aussi.
Est-ce LUA ? Ca ressemble à du 'C' mais ce n'est pas du 'C'.

@+

[f-leb]

@Artemus, on s'égare un peu du sujet initial de naute qui utilise un (bon vieil) Arduino UNO avec un shield Ethernet dans son article...

Si tu as des questions sur l'ESP32, le système de fichier SPIFFS, LittleFS ou autres, tu devrais ouvrir de nouvelles discussions. Le lecteur s'y retrouvera plus facilement

[Artemus24]

Salut f-leb.

@Artemus, on s'égare un peu du sujet initial de naute ...

Pas tant que cela. Pourquoi ces reproches ?

Naute a abordé la dépréciation de SPIFFS et il y a plusieurs messages consacrés à ce sujet.
Et toi-même, tu as abordé l'ESP32 :

Hervé, j'ai repris le tuto et tes codes pour l'adapter à un DevKit ESP32

Je n'ai fait que poursuivre sur ces discussions. En quoi suis-je hors-sujet ? Parce que je n'ai pas d'arduino ?

Oui, le sujet de Naute est fort intéressant et je le félicite à nouveau pour son travail.

Inversement, dans plusieurs de mes sujets personne ne me répond.

@+

[Jay M]

Il s'agit de conserver ou pas cette bibliothèque dans le noyau de la plateforme utiliséee et non d'éradiquer la bibliothèque par elle-même.
On peut continuer à se servir de cette bibliothèque, même si elle n'intègre plus officiellement le noyau de la plateforme utilisée.

Si c'est ça, je comprends mieux le problème.

c'est exactement ça. Avec le risque que la bibliothèque devienne incompatible avec les évolutions du noyau de la plateforme puisqu'elle n'est plus maintenue. (le code de SPIFFS a des bugs connus déjà) aujourd'hui et qui ne sont pas corrigés donc au mieux ça reste en l'état au pire...).

si littlefs n'était plus maintenu (cf son design - il n'y a que peu de participants) alors il y aurait le même souci.

Une même bibliothèque ne fonctionne pas sur toutes les plateformes.

ça dépend de son niveau d'abstraction. par exemple une bibliothèque qui utilise digitalRead() et millis() pour gérer un bouton est programmée à un niveau d'abstraction qui fait que du moment que millis() et digitalRead() sont fonctionnels sur la nouvelle plateforme alors elle est aussi fonctionnelle. Mais si les APIs que vous utilisez sont spécifiques à l'OS sous jacent (dans le cas des ESP) ou à des fonctions matérielles (un timer, un second port série hardware, ...) alors c'est moins portable en effet et dans l'idéal c'est à la bibliothèque de faire l'effort de cacher cette complexité pour offrir une API uniforme sur plusieurs plateformes.

Et si je comprends le <beep> ambiant, il y a autant de versions (par exemple FS : file system) qu'il y a de gens qui s'y intéresse.
Combien de déclinaisons a-t-on de FS ? SPIFFS, LITTLEFS, FatFS, ...

Oui et non. Mais c'est un monde (assez) libre, si vous voulez créer un file système, rien ne vous en empêche.. Ensuite le succès dépend de nombreux facteurs, si votre bibliothèque est très visible et intégrée en standard dans la distribution Arduino par exemple alors elle devient un peu la solution de base et il faut que les autres bibliothèques soient vraiment bien meilleures pour s'imposer.

Comment se nomme le langage qui est utilisé dans l'ESP32 ? Je suppose l'arduino aussi.
Est-ce LUA ? Ca ressemble à du 'C' mais ce n'est pas du 'C'.

Le "Arduino core for the ESP32" est programmé en C++ tout comme ce qu'on fait généralement dans l'IDE.

[Artemus24]

Salut Jay M.

Merci pour toutes ses précisions.

@+