Sauf que, comme l'OP, j'ai déjà rencontré le cas où même avec un délai de plusieurs secondes cela ne fonctionne toujours pas dans setup() alors que cela fonctionne juste après dans loop().
Je ne peux pas donner la référence exacte de la puce, c'était il y a un an ou deux.
Soyons clair : le temps dans la fonction setup() ne dure pas des dizaines de millisecondes.
Pourquoi cela fonctionne dans loop qui vient quelques millisecondes après le démarrage du micro et que cela ne fonctionnerait qu'avec un delai qui se compte en secondes dans setup() ?
Pourquoi en inversant l'ordre d'écriture de setup et loop cela fonctionne ?
Cela ne me parait ni limpide, ni cohérent
J'ai jeté un œil sur le fichier main.cpp pour ESP32, origine platformIO, mais comme il a été écrit par Espressif, sous IDE Arduino il doit être copie conforme.
Ce n'est pas anormal je n'y ai rien compris, Freertos me largue complètement.
Mais j'ai quand même vu qu'il y a déjà des délais et déjà un certain nombre de Serial.begin().
Je serais intéressé par quelques explications, niveau neuneu soyons réaliste, qui justifient que malgré les Serial.begin() et les delay() de main.cpp, qui est le véritable fichier transmis au compilateur, il faille encore ajouter des delais.
Il semble qu'on puisse se passer du duo setup / loop et écrire soi-même son main(). Ca vaudrait le coup de tester.
Je m'inspire de ceci (auteur Nick Gammon, une pointure !) :
On pourrait tester un truc similaire :
D'abord créer un fichier ino vide, ayant le nom du code d'origine (donc celui du répertoire dans lequel se trouve ce code)
Ensuite, créer un deuxième onglet dans l'IDE et l'appeler test.cpp par exemple.
Ecrire dans cet onglet le code suivant :
#include <Arduino.h>
int main ()
{
Serial.begin (9600); // 115200 serait préférable à 9600
Serial.println ("Just checking if it properly works");
Serial.flush (); // let serial printing finish
while (1) {
delay (1000);
Serial.println ("loop");
}
} // end of main
Et tester le tout.
Je navigue à vue, il y a 99% de chance que ça ne fonctionne pas mieux...
carte : Lolin32 Lite, (ESP32 'première génération')
IDE 2.3.3 , Core ESP32 3.0.7
le message 'Just checking....." issu de setup() apparait bien après chaque Reset manuel,
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:4604
ho 0 tail 12 room 4
load:0x40078000,len:15488
load:0x40080400,len:4
load:0x40080404,len:3180
entry 0x400805b8
Just checking if it properly works
loop
Ce message issu du setup() n'apparait jamais après le Reset automatique de fin de flashage
le message 'loop' , issu de loop() est précédé de données reçues à un débit autre que celui définit dans setup()
Je n'ai vraiment aucune explication à des problèmes qui me semblent bien spécifique à Arduino. Je débute avec l'ESP32 (du reste la même que @fasstoch utilise bien que ce soit une AE) et je n'ai aucune expérience des OS real time. Tous les retours que je vois semblent me confirmer que j'ai bien fait d'utiliser VSCode plutôt qu' Arduino. Fonctionne du premier coup en Wifi, pourtant à une quinzaine de mètres de la box, mais c'est vrai que ce n'est qu'un début
Non, je me suis peut-être fait mal comprendre mais mes tests sont faits avec platformIO.
Je suppose, sans prendre de risque, que l'équipe arduino ne met pas son nez dans le framework Espressif, elle a déjà bien assez à faire avec ses propres cartes.
Reset et Reset : La dernière remarque d'@al1fch obscurcie encore un peu plus l'affaire.
Cela laisse à penser que l'ensemble du micro n'est pas concerné par un reset manuel.
En fait je suis convaincu qu'il faudrait poser la question à Espressif.
L'anglais je pourrai faire un effort (oui @J-M-L tu as bien lu ) mais le niveau technique est bien trop élevé pour moi.
Oui j'ai testé avec 9600 et 115200, le comportement est pareil.
Je pense que les tests précédent étaient suffisant en inversant loop et Setup mais le résultat de ce dernier code, ne renvoie que :
Just checking if it properly works
Ce qui me semble ok du coup.
Je confirme avoir déjà testé avec des delay de malade et que ca changeait rien ...
===> par contre le truc bizarre !? Voire limite a péter un câble ^^ c'est que j'ai retesté mon script en post 3 avec un delay 1000 avant le Println et maintenant ca passe
Alors que je suis formel ca passait pas avant ! Comme si ca avait débloqué entre temps ...
Bon après, j'avoue que vous m'avez un peu perdu dans les posts suivants ^^
VSCode ?
Je leur ai envoyé un mail ... je vous dit s'ils me répondent
Sinon j'ai hésité un paquet de fois a tout convertir dans du python mais bon je connais pas vraiment le langage, ni les plateforme ... vous pensez que je devrais faire ca !?
Le bug se produit aussi avec platformIO !
Et aussi avec d’autres concepteurs de cartes.
Et aussi avec 115200, je n’utilise jamais 9600.
Espérons qu’Espressif repondra, ce doit quand même être un problème connu.
Je l’ai rencontré il y a environ 1 an, 1 an et demi avec des cartes ESP32-C3 de provenance Al1thinker. Donc des micros riscV et non pas tensilica/cadence.
Je n’en avais pas fait cas, ce n’était pas bloquant, la sortie moniteur dans le setup étant juste là pour signaler le départ du programme.
Cela signifie qu’il ne faut pas se polariser sur la carte particulière de @fasstoch.
Constatez vous comme moi le bug au premier Reset après flashage , pas aux Resets manuels par la suite ?
si oui ça pourrait être un bug au niveau du 'passage de relais' du premier UART entre le bootloader et le code utilisateur
Au passage je constate désormais chez moi (Linux, IDE 2.3.3) un délai d'environ 5s entre
-l'apparition dans la console message 'leaving...Hard Resetting via RTS pin ..."
-l'apparition de la fenêtre 'Téléversement fait"
Ce qui est tout à fait normal car platformIO fait une émulation Arduino (terme exact?) avec un setup et une loop.
VisualStudioCode
Je ne constate aucune différence entre reset manuel et reset après flashage. La commande de reset est physiquement la même sur la carte AZdelivery le problème ne peut être que soft
Que ce soit platformIO et VSCode ou l'IDE arduino, il me semble que les deux utilisent le même "core" Arduino et les deux outils supportent les mêmes bibliothèques Arduino.
Les deux utilisent GCC pour la compilation, mais PlatformIO permet une personnalisation plus fine des options de compilation grâce à un fichier platformio.ini et à des options de configuration plus granulaires.
A moins d'une optimisation abusive, je ne pense pas que la différence vienne de l'environnement de développement.
Comportement différent chez moi le bug, ne se produisant qu'après le premier Reset après flashage qui est dans mon cas un Reset automatique et non manuel .
Bien entendu tous les Resets matériels passent au final par la même broche (broche EN des modules WROOM, broche CHIP_PU pour le cpu ESP32 qui est sous le capot)
Le premier à une particularité : il correspond à la libération du premier UART par le bootlader au profit du code utilisateur.
Quand j'aurai un moment je mettrai l'analyseur logique sur la sortie TX pour voir ce qui s'y passe 'pour de vrai'
Je n'utilise pas platformIo, je n'ai donc pas les problèmes qui semblent propres à "Arduino"
Le reset de la carte AZdelivery étant simplement de faire chuter la tension d'alimentation si la commande est effective le reset fonctionne obligatoirement
Vous m'avez mis le doute avec votre histoire, ne me souvenant pas avoir rencontré ce problème je viens de faire l'essai sur 2 cartes équipées d'ESP32: une carte MH et LIVE équipée d'un module Espressif ESP32-WROOM-32 et une carte TTGO-T4 sans module Espressif avec un ESP32.
Dans les 2 cas, le code donné plus haut fonctionne correctement dans l'IDE et je vois bien "Just checking if it properly works" après un reset hard ou soft pour autant que le delay(1000) est placé avant le println() dans setup(). Et l'ordre setup() loop() n'a absolument aucune influence.
Hors de l'IDE, avec minicom si je débranche et que je rebranche la carte quelques fois le println() du setup() est raté cela est dû au temps que l'OS + minicom mettent pour retrouver le périphérique virtuel. Si je monte le delay() à 3 secondes j'ai bien tous les messages qui s'affichent.
A noter quand même, qu' actuellement, je n'utilise pas la dernière version du package ESP32 d'Espressif car pour recompiler une ancienne application qui utilise une librairie non maintenue j'ai dû rétrograder ma version du package à la 2.0.17
Il m'a déjà été répondu sur ce forum que la notion de setup et loop est ancienne.
On sait qu'arduino est une copie (non amicale) de Wiring et que Wiring lui-même est basé (amicalement) sur processing.
Mais même processing n'aurait pas inventé ce concept de setup et loop, ce concept serait plus ancien.
Par contre oui c'est normal que le bug se produise aussi bien sur IDE arduino et sur IDE platformIO puisque dans les deux cas le code a été écrit et fourni par Espressif.
Ma "petite" expérience en développement de circuit intégré me fait plutôt penser à l'existence d'effets de bord indésirables et non identifiés.
A force de proclamer qu'il ne faut pas réinventer la roue, on empile les bibliothèques et les rustines dans les bibliothèques.
Dès qu'il y a un souci, cela devient incompréhensible.
J'ai vécu une expérience équivalente d'empilage de bibliothèques et de rustines, mais en électronique. En donnant un grand coup de balai, les performances demandées ont été obtenues.
Si cela se passe en électronique, il n'y a pas de raison que cela ne se passe pas en programmation.
Ce concept paraît bien pratique pour débuter ou pour une utilisation ponctuelle mais ne présente aucun intérêt dès que l'on commence à comprendre la programmation.
Espressif crée en priorité ses propres bibliothèques pour ses micros. Essayer d'amener les utilisateurs Arduino à utiliser Espressif est commercial.
Je suis bien du même avis, utiliser cet empilage avec Arduino pour débuter mais après supprimer cet empilage pour utiliser directement la bibliothèque ESP me paraît une évidence même si @fdufnews passe à travers les problèmes
Je ne suis pas tout à fait d'accord.
Il est depuis longtemps utilisé d'avoir un "main", qui appel une fonction d'initialisation et une fonction corps, en plus de l'analyse des paramètres d'entrées.
Donc aucun intérêt est très discutable, même si rien n'empêche le développeur de le faire lui même.
Moi je trouve cela plutôt utile.
#include <Arduino.h>
uint16_t n ;
void setup() {
Serial.begin(115200);
Serial.println("Bonjour, le setup est en cours d'exécution !");
}
void loop() {
Serial.print("Rang dans la Loop = ");Serial.println(n);
n++;
delay(1000);
}
Je confirme le défaut.
Compilation/flashage OK
Avec ce code [1] Dans tous les cas le passage "loop = 0" s'affiche.
Le message dans setup ne s'affiche qu'après un reset manuel, jamais avec celui qui suit le flashage..
La sortie moniteur fonctionne bien au premier passage dans la fonction loop.
[1] voir plus loin le bémol si on inverse l'ordre setup et loop.
USB testée :
Le comportement est le même que ce soit sur l'USB/UART CH340. → dev/ttyUSB0
ou USB native → /dev/ttyACM0
Dans ce dernier cas, les options supplémentaires de platformio.ini sont :
Dernières manips.
J'ai inversé setup et loop.
Nouveau comportement anormal. Je précise manip recommencée et vérifiée plusieurs fois.
pas d'amélioration comme constatée avec l'IDE arduino par @fasstoch
L'information du rang de passage dans loop que j'ai ajouté montre que le premier affichage de loop = rang peut-être "aléatoirement" 0, 1, 2 ou 3.
Je n'ai jamais obtenu plus de 3.
Essais suite avec un ESP32-S3
Comportement quasi identique.
Et si le bug n'était pas plutôt celui des IDE qui mettent trop de temps à basculer d'un mode d'affichage à un autre ?
Et si cela dépendait de la rapidité du PC ?
Ce qui me fait dire cela c'est qu'avec l'ESP32-S3, quoi que je fasse je n'arrive pas voir le message du setup même après un reset manuel.
Le micro étant plus rapide que la version C3 cela peut être cohérent.
Changement d'outil, je prends CuteCom et là, je peux voir tous les messages.
Je conclurais que l'on s'est fait abuser par ce qui sautait au visage, alors que le problème est ailleurs.
Il n'empêche que sur l'inversion setup loop il reste un doute.
Il n'empêche que sur le délai de plusieurs secondes totalement inefficace après un Serial.begin() dans setup(), il reste un doute.
test complémentaire montrant comment le ou les premiers println() qui suivent un reset auto après flashage peuvent apparaître ou pas selon la durée du delay qui précède
void setup() {
Serial.begin(115200);
delay(3000);
}
void loop() {
for (int i = 1; i < 6; i++) {
Serial.println(i);
delay(1000);
}
while (1);
}
sortie sur terminal de l'IDE 2.3.3
����������������������3
4
5
on constate d'abord que les messages du boot ne sortent pas au débit attendu
puis
delay(3000) -> les deux premiers println() sont 'mangés'
delay(4000) -> le premier println() est 'mangé'
delay(5000) OK
) mais le niveau technique est bien trop élevé pour moi.
