LOCODUINO
Parlons Arduino => Trucs & astuces => Discussion démarrée par: dmskd le avril 20, 2021, 11:00:25 am
-
Bonjour,
Je ne sais pas si c'est le bon forum et la bonne rubrique pour poser ma question, mais je vais peut-être trouver des spécialistes des ESP qui pourront m'aider.
J'ai développé depuis quelques temps une centrale DCC qui utilise un ESP8266 (WEMOS D1 MINI) pour la partie "serveur web" qui permet d'utiliser un PC, une tablette ou un smartphone pour afficher des TCO et commander les trains simplement en se connectant à la centrale.
J'ai essayé de remplacer l'ESP8266 par un ESP32-WROOM (ESP32 NodeMCU) sans rien changer au montage global et en adaptant simplement le programme pour coller avec ce circuit.
Je constate que l'affichage des pages est deux fois plus long, alors que je pensais que l'ESP32 était plus performant que l'ESP8266.
Quelqu'un aurait-il des pistes de recherche pour améliorer la chose ?
Cordialement,
Dominique
-
La vitesse d'exécution dépend déjà de la vitesse d'horloge sélectionnée dans la configuration. Question stupide peut etre mais vous avez bien sélectionné le 240 Mhz ?
La vitesse de votre flash est bien sur 80 Mhz ?
Par ailleurs : comment sont répartis vos traitements sur les deux coeurs du M0 ?
-
Je n'ai fait que reprendre le programme qui tourne sur l'ESP8266 sans rien changer.
Peut-être pouvez-vous m'indiquer où je peux en trouver plus sur ce que vous indiquez.
Quand au traitement ils est très simple, il suffit d'envoyer du code HTML et Javascript au client WiFi.
La prise en compte de la requête est instantanée, la lecture des fichiers sur la carte SD et l'exécution de la commande d'envoi (client.println) est rapide (de 0.05 à 0.15 s selon le taille des fichiers).
Mais entre l'envoi et la fin de l'affichage il se passe de l'ordre de 6 s (au lieu de 3 auparavant) pour la page la plus complexe.
-
Étonnant en effet cette perte de performance.
Vous devriez publier votre code pour que l'on puisse jeter un oeil.
-
Je n'ai fait que reprendre le programme qui tourne sur l'ESP8266 sans rien changer.
Peut-être pouvez-vous m'indiquer où je peux en trouver plus sur ce que vous indiquez.
Quand au traitement ils est très simple, il suffit d'envoyer du code HTML et Javascript au client WiFi.
La prise en compte de la requête est instantanée, la lecture des fichiers sur la carte SD et l'exécution de la commande d'envoi (client.println) est rapide (de 0.05 à 0.15 s selon le taille des fichiers).
Mais entre l'envoi et la fin de l'affichage il se passe de l'ordre de 6 s (au lieu de 3 auparavant) pour la page la plus complexe.
Dans votre IDE arduino, là ou vous configurez le type de processeur (board), quels sont les parametres que vous avez positionné pour votre ESP32 :
- Fréquence CPU : 240 Mhz ?
- Fréquence FLASH : 80 Mhz ?
- Mode flash : DIO ?
- Niveau de debug core : NONE ?
-
Je code dans l'environnement VSCODE/PLATFORMIO.
J'ai vérifié que le la fréquence du cpu est de 240 MHz, pour la féquence Flash, je ne sais pas.
J'ai ajouté dans le fichier platformio.ini "
board_f_flash= 80000000L
mais je n'ai pas encore pu tester.
Vous devriez publier votre code pour que l'on puisse jeter un oeil.
Le code qui traite les fichiers HTML est le suivant, une fois la requête analysée :
webFile1 = SD.open("/top-base.htm");
if (webFile && webFile1) {
int time1 = millis();
String content = "";
while (webFile1.available()) {
content += webFile1.readStringUntil('\n');
}
client.println(content);
content = "";
while (webFile.available()) {
content += webFile.readStringUntil('\n');
}
client.println(content);
content = "";
int time2 = millis();
Serial.println(time2-time1);
webFile.close();
webFile1.close();
Ce code s'exécute en 0.15s max (time2-time1).
Il y a 2 fichiers envoyés, le premier est un fichier qui inclut le code HTML, le Javascript et le CSS commun à toutes les pages, le deuxième la partie spécifique de chaque page.
-
Votre code parle de carte SD, est-ce que les cartes sont identiques entre les 2 montages? Est-ce que l’objet SD n’est qu’en fait l’accès à la flash de l’esp32?
Sinon il faudrait regarder côté réseau wifi. Par exemple, est-ce que votre code force l’adresse MAC? Cela pourrait perturber votre réseau si l’autre 8266 est aussi sous tension?
Combien avez-vous de réseau wifi ou de bornes wifi ?
Pas facile à diagnostiquer ainsi.
-
C'est bien une carte SD qui contient les fichiers, mais la mesure de temps montre que le problème viens après la lecture, au moment de l'envoi vers le client.
C'est surtout la différence de comportement qui ne s'explique pas dans des conditions d'utilisation STRICTEMENT identiques.
Merci de vous êtes intéressé à mon problème.
-
Pourquoi une carte SD alors que l'ESP32 à une mémoire SPIFFS de 4 à 8 Mo ???
Si le programme HTML JavaScrip images est lourd, il faut fonctionner avec des websockets. L'ensemble des fichiers "lourds" est chargé au démarrage, ensuite il n'y a plus que des échanges de data (commandes) quelques octes seulement. C'est le principe par exemple de mon PT : https://www.locoduino.org/spip.php?article257
Par ailleurs, l'ESP32 ne fonctionne pas du tout comme l'ESP8266 et le code (bibliothèques) optimisé pour l'un ne l'est pas forcement pour l'autre.
Ca m'intéresse d'avoir l'ensemble du code en téléchargement pour faire des tests.
-
Pourquoi une carte SD alors que l'ESP32 à une mémoire SPIFFS de 4 à 8 Mo
Pour l'instant je ne fais que tester le remplacement de l'ESP8266 sans rien changer au montage actuel. Je rappelle que ce n'est pas la lecture des fichiers qui pénalise la durée totale de traitement.
Si le programme HTML JavaScrip images est lourd, il faut fonctionner avec des websockets.
Je sais que mon code n'est pas optimisé. J'apprends au fur et à mesure et il y a tant d'autres choses à faire. Mais les 3s d'affichage me satisfaisaient. Passer à 6s est plus ennuyeux.
Par ailleurs, l'ESP32 ne fonctionne pas du tout comme l'ESP8266 et le code (bibliothèques) optimisé pour l'un ne l'est pas forcement pour l'autre.
Dans platformio.ini j'ai défini "platform = espressif32". Peut-être n'est-ce pas suffisant.
Ca m'intéresse d'avoir l'ensemble du code en téléchargement pour faire des tests.
Code ci-joint.
-
Bonjour,
J'ai regardé le code rapidement mais je ne l'ai pas encore testé. Il y a des choses qui ne me paraissent pas aider à un fonctionnement fluide. En tout premier lieu, j'ai vu que le programme (sur le client) interroge le serveur toutes les 3 secondes. Je ne me trompe pas ? Je ne sais pas quel volume de données est alors retourné mais toutes les 3 secondes c'est beaucoup. D'autant que le serveur ferme à chaque fois la connexion quand il a répondu au client obligeant, toutes les 3 secondes à recommencer un couteux processus d'authentification de la requête même si c'est une XMLHttpRequest. Déjà là, il faudrait chercher à gagner en rapidité en laissant simplement les connexions tcp ouvertes ce qui est très simple et ferait j'en suis sûr gagner beaucoup en vitesse de réponse.
Mais plus fondamentalement, ce sont les requêtes régulières clients -> serveur qui sont consommatrices d'où, ce que je disais dans ma réponse précédente, l'intérêt d'utiliser des websockets où c'est le serveur qui "push" vers les clients mais seulement quand il y a des modifications susceptibles de les intéresser.
Par ailleurs, même si cela ne représente pas des volumes très importants, je chercherais à optimiser en chargeant les fichiers json de description dans le localstorage du navigateur (avec une mise à jour au besoin de ces fichiers directement dans le localstorage).
Enfin, après ce premier petit tour dans le programme, je m'interroge quant à savoir s'il n'est pas possible de "déporter" plus de traitements sur le navigateur qui est grandement plus rapide qu'un ESP. Mais là il faudrait regarder plus en détails.
-
Bonjour et merci beaucoup pour ces remarques très constructives.
J'avoue que je ne maîtrise pas complètement le sujet et que l'application que j'ai réussi à développer me satisfaisait pour mon petit réseau. C'est simplement la limitation de l'ESP8266 à 4 clients wifi qui m'a conduit à tester l'ESP32.
Une analyse du comportement avec l'outil de développement de Firefox m'a permis de voir que ce qui prend du temps, c'est le chargement du fichier javascript (440ko) vers le client à l'affichage de la page html : 1s avec ESP8266, 3s avec ESP32. Si je déporte plus de traitement sur le navigateur, je pense que ce fichier va encore grossir.
MAIS, si on charge le javascript AVANT le css, c'est le css qui prend plus de temps, alors qu'il est 10fois plus petit.
Ensuite il n'y a plus vraiment de problème avec les rafraîchissements périodiques dont le traitement est de l'ordre 50ms donc tout à fait raisonnable.
Il va falloir que je prenne du temps pour essayer de ne pas fermer les connexions tout en gérant plusieurs clients et utiliser des websockets. Si vous avez des exemples de code, ça m'aiderait sûrement.
En attendant, encore une fois merci.
-
Il faut chercher à optimiser ce fichier js.
440ko, c’est énorme. Il faudrait extraire le strict nécessaire.
Après Christophe dit vrai, une connexion / déconnexion toutes les 3s sur un microcontroleur avec pour objectif d’avoir plus de 4 clients simultanés ne me semble pas raisonnable. Les websocket et des échanges optimisés est LA solution à mettre en œuvre.
Bon courage,
-
440ko, c’est énorme
Effectivement, mais c'est une erreur de frappe, en réalité c'est seulement 44.
-
Question subsidiaire :
Apparemment la fonction WiFiServer.available() permet de détecter qu'un client envoie des données.
Mais comment savoir si un client est connecté même s'il n'envoie aucune de données ?
-
Si on a un serveur :
WiFiServer server(22); // serveur sur le port 22
alors
WiFiClient client=server.available();
teste si un client est connecté et
if (client.available()) ...
teste si le client a envoyé quelque chose
Pierre
-
Bonsoir Pierre,
C'est ce que je pensais, mais ...
Dans mon programme je fais:
client = server.available()
if(client)
... traitement ...
eh bien on entre dans le bloc if uniquement si un des clients envoie quelque chose, sinon client=0 alors qu'il y en a plusieurs de connectés.
-
Une analyse du comportement avec l'outil de développement de Firefox m'a permis de voir que ce qui prend du temps, c'est le chargement du fichier javascript (440ko) vers le client à l'affichage de la page html : 1s avec ESP8266, 3s avec ESP32. Si je déporte plus de traitement sur le navigateur, je pense que ce fichier va encore grossir.
MAIS, si on charge le javascript AVANT le css, c'est le css qui prend plus de temps, alors qu'il est 10fois plus petit.
Ensuite il n'y a plus vraiment de problème avec les rafraîchissements périodiques dont le traitement est de l'ordre 50ms donc tout à fait raisonnable.
Pour autant, le fichier javascript n’est chargé qu’une seule fois au lancement de l’application sur le navigateur. Cela peut-être sensible au démarrage mais plus après.
Ce qui est vraiment consommateur, ce sont les requête http car il y a un processus de transaction lourd. L’une des pistes pas trop compliquée à mettre en œuvre dans ce projet est de créer un « one page » avec des zones masquées ou apparentes selon les besoins. Le temps de chargement initial est là aussi plus long, mais il n’y a plus à naviguer entre des pages html et donc solliciter le serveur pour cela => bénéfice à l'utilisation. C’est comme cela que sont réalisée toutes les applications aujourd’hui.
-
J’ai bien regardé l’application, il va être compliqué d’introduire l’utilisation des websockets car ça oblige à reprendre tous le code (en js et en C/C++) et il y a déjà eu beaucoup de travail de fait.
Si de plus le temps du rafraichissement périodique ne semble pas te poser de problème, il n’est pas nécessaire de changer ce point.
Par contre, pour le rafraichissement, ce qui peut être fait, qui est très simple avec le code actuel et qui pourra au moins réduire de moitié le temps de réponse des requêtes est effectivement de ne pas fermer les connexions.
Il faut déterminer le nombre de connections maxi que l’on souhaite ne pas dépasser, j’ai compris que c’était 4.
Soit un define (ma préference)
#define MAX_CLIENTS 4
Ou une constante
byte maxClients = 4 ;
Créer un tableau d’instance de WiFiClient
WiFiClient client[MAX_CLIENTS];
Et dans le loop, on créé une boucle et on vérifie que, si un client cherche à se connecter, si ce n’est pas déjà le client courant :
for (byte i = 0; i < MAX_CLIENTS; i++) {
if (!client[i]) {
client[i] = server.available();
}
Si le client n’est pas déjà connecté :
vérifier si la connexion d’un client a déjà été faite ou pas :
else {
if (!client[i].connect(IP, Port)) {
….;
}
Et on incrémente une variable d’état : alreadyConnected[i]
Et
else if (!alreadyConnected[i]) { // ce client n'est pas connecté
….
}
On peut donc de cette manière accepter jusqu’à MAX_CLIENTS qui ne sont jamais fermés, et parfaitement identifiés.
Ensuite pour le client concerné, on vérifie s’il y a une requête :
if (client[i].available()) {
Ca ne nécessite que très peu de modifications du code actuel.
J’ai vu aussi qu’il y avait pas mal de String. C’est une classe couteuse en ressources et je chercherais à substituer des pointeurs de char * ou des tableaux de char[] ce qui revient (à peu près) au même.
-
Bonjour bobyAndCo,
Comme tu peux le voir dans mon code j'avais un peu essayé l'utilisation d'un tableau de clients, mais comme je l'ai dit dans un message précédent, tant que le client n'envoie pas de requête, client.available donne 0 et impossible d'extraire les adresses ip des clients connectés.
Est-ce normal ?
Note que la limitation de 4 clients est due à l'ESP8266.
-
Je pense que tu confonds deux choses :
client[i] = server.available();
et
client[i].available()
Un client peut être connecté : client[i].connect(IP, Port) mais n'avoir envoyé aucune requête client[i].available() ce qui renvoie 0 pour false en booleen !
-
Sinon, je n'ai toujours pas eu le temps de charger le code mais je pense que la partie graphique en svg doit être sympa, j'ai hâte de voir. Dans cette attente, peux-tu envoyer des copies d'écrans ?
-
Bonjour bobyAndCo,
Comme tu peux le voir dans mon code j'avais un peu essayé l'utilisation d'un tableau de clients, mais comme je l'ai dit dans un message précédent, tant que le client n'envoie pas de requête, client.available donne 0 et impossible d'extraire les adresses ip des clients connectés.
Est-ce normal ?
Note que la limitation de 4 clients est due à l'ESP8266.
Ton code est bon (avec quelques compléments comme je le montre plus haut). Mais il ne faut pas fermer la connection comme tu le fais ligne 171 wificlient[i].stop(); // close the connection
-
Je me suis effectivement trompé dans mon message, c'est server.client qui renvoie 0 tant que le client n'envoie pas de requête.
Ci-joint une copie d'écran (tout est encore en développement°.