je pense qu'il faut explorer de ce côté là
68tjs indique , si je comprends bien, que le bug se manifeste également avec VSCode+PlarformIO
Là le Terminal de l'IDE est hors de cause
certes
Je mets en cause le principe même des multifenêtres des IDEs.
Il faut du temps à l'affichage pour passer de l'état console de programmation à l'état console de sortie.
Les micros étant maintenant très rapides avec leur fréquence horloge de plus de 100 MHz, il se peut, c'est mon hypothèse, que l'envoi se fait bien dans le setup mais qu'il n'y a rien en face pour le recevoir.
Quand on fait un reset manuel, l'IDE est déjà positionnée correctement, elle n'a pas besoin de commuter.
Aux réserves que j'ai faites, comme l'inversion entre setup/loop ou les délais monstrueux qui paraissent inefficaces et qu'il faudrait lever, je pense qu'on s'est fait berner par les apparences.
@al1fch Peut-être que tu sais faire :
Avec une carte à double prise USB, programmer sur une voie et écrire sur l'autre voie qui sera connectée en permanence sur un simple terminal minicom ou cutecom.
J'ai tenté le coup.
Mais je patauge, il faudrait trouver les ordres pour imposer le port ACMx pour la programation et USBy pour la sortie série.
Le fournisseur m'a répondu ... plutôt décevant !
Il m'invite a regarder dans le forum de leur Facebook 
--> Même minable comme réponse. Moi qui "boycott" Facebook, j'irai pas voir la bas ^^
Bon en tout cas, je ne pensais pas faire autant le buzz avec ce sujet ^^
Quoi qu'il en soit, il y a un contournement grâce à votre aide, je m'en contenterai pour l'instant.
Encore merci à tous !
Bonsoir @68tjs
Sous la main une seule carte à deux connecteurs USB : une 'AI-C3' avec un module ESP32-C3 MIni d'Espressif
IDE 2.3.3 , carte sélectionnée ESP32C3 Dev Module , port sélectionné /dev/ttyACM0 (pour le flashage)
CDC on Boot Déselectionné (car on ne veut pas utiliser l'USB natif dans notre code= après le Boot)
Le bootloader, lui, sait gérer par lui même tous les ports série qui se présentent, USB natif inclus.
Dans cette configuration faute d'USB natif activé pour le code ,Serial est logiquement associé à /dev/ttyUSB0
IDE : port dev/tty/ACM0 sélectionné juste pour les flashages
COOLTERM connecté à /dev/ttyUSB0 @115000 bauds,
Dans le code les sorties d'infos se font par Serial.println() pour aller à CoolTerm sans déconnection durant les flashages 
Et la conclusion est ?
Qu'il n'y a toujours pas d'impression après la flashage du programme ?
Hier dans mes essais avec la S3 l'USB /UART apparaissait (à l'écran) comme ACM1 et non pas USB0 : erreur d'affichage ?
J'avais l'impression que l'impression dans le setup fonctionnait juste après le flashage.
Quant à la C3 il y avait un refus de la prise en compte.
Je recommencerai mes tests dès que possible sur les IDEs PIO et Arduino 2.x.x.
Dans tous les cas, c'est perturbant, mais ce n'est pas bloquant.
ayant constaté (#40) que le bug survenait lors de la première impression après flashage ,
que cette impression soit demandée dans setup() ou dans loop() ,
le test d'hier soir m'a paru concluant j'en referai un en jouant avec setup()
1, 2 ,3 : c'est dans loop.
Ça a toujours fonctionné.
Quid du message dans setup qui devrait être imprimé sur l'écran ?
C'est lui qui ne s'imprimait pas.
Non, cf post #40 , une ou plusieurs impressions disparaissent ,setup() hors de cause
On s'est focalisés sur setup() mais si la ou les premières impressions sont dans loop() et non setup() le bug est là pour celles qui interviennent trop trop tôt après le flashage.
tout est question de timing, setup() n'y est pour rien dans l'affaire.
On l'a mis en cause car on lui demandait de faire une impression 'prématurée' au vu du bug
Edit : si tu fais comme moi, que tu reprends des messages déjà publiés pour les compléter, cela ne va pas aller, cela m'est réservé 
----------------------------------------------------------------------------------------
Je ne vais tout reprendre depuis le début, je reste sur ce que j'ai compris et également sur ce que j'ai constaté.
-
après flashage pas d'impression dans setup, quelle que soit la valeur du délai.
Mais impression est parfaitement possible dans loop.
Perso, c'est ce que j'avais constaté il y a plus d'un an, comme cela imprimait dans loop ce n'était pas bloquant, j'avais ignoré le bug
. -
Une "astuce" d'inversion de l'ordre d'écriture permettrait d'imprimer à partir de setup. Là, nous sommes nombreux à ne pas comprendre.
-
Tu signales que cela ne se produit qu'après le flashage. Il n'y a aucune anomalie après un reset manuel.
-
Perso, j'ai du mal à trouver une cohérence entre les différentes constatations. C'est pour cela que je pense à un "piège visuel", qui fonctionne super bien.
-
Comme cela ne se passe qu'après la phase de programmation et pas en service normal, ce n'est ni bloquant ni même gênant. C'est parfaitement gérable. C'est juste que je pense qu'on est un certain nombre qui aimeraient bien comprendre.
Là où j'en suis, c'est lever le doute : c'est un vrai bug ou c'est un défaut inhérent aux principes de fonctionnement des IDEs, .......... ou les deux.
-dans ton bilan intègres-tu les résultats du #40 ?
-point 4 : je ne suis pas totalement débarrassé de la même impression.
-je ferai mes tests pour les points 1 et 2
-OK pour continuer à chercher une explication intégrant tous les symptômes
Le souci c’est que l’IDE a besoin d’utiliser (via une ligne de commande) la liaison série pour flasher le code puis la carte reboote et entre temps il faut que la commande de chargement ait fermé le port série, que l’IDE ait repris la main pour donner le port série à un autre process qui écoute cette ligne série et qui affiche les résultats dans cette console.
On pourrait incriminer le temps de bascule mais un delay() Dans le setup n’y change rien si j’ai bien compris le résumé… il se pourrait donc que le HAL de l ‘UART soit paresseux (lazy) et effectue dans un tâche de fond la configuration du port série (énumération ?) et qu’il fasse cela soit au premier print, soit en fin de setup ? (La tâche a peut être une priorité faible et n’est pas activée assez tôt ?)
Je suis sur mon iPhone - je ne peux pas creuser le sujet. J’essayerai de regarder de ce côté là ce soir ou demain
Ben non, je l'avais strappé.
Un test à l'instant avec une carte Lolin32Lite remet en cause ce point qui paraissait acquis.
SI l'impression demandée dans loop() est précédée d'un delay() d'au moins 5s le message apparaît bien dans le terminal de l'IDE mais précédé d'un message de boot à un débit anormal ( autre que celui venant après un Reset autre qu'automatique en fin de flashage)
����������������������loop
1
2
3
4
5
Code
void setup() {
Serial.begin(115200);
delay(5000);
Serial.println("loop");
}
void loop() {
for (int i = 1; i < 6; i++) {
Serial.println(i);
delay(1000);
}
while (1);
}
perso je n'ai pas pu reproduire le souci mais je suis encore sous le core 2.x d'espressif
faites vous les tests en 3.x ?
oui core 3.x d'Espressif pour moi , retour temporaire en 2.x uniquement pour des besoins particuliers
OS : Ubuntu 24.04 LTS
IDE 2.3.3
Bonjour,
Par hasard ce matin j'ai trouvé dans mes tiroirs le même module que @fasstoch de la marque AZ-Delivery. J'ai fait des tests et il me semble que mes observations sont les mêmes que celles d' @al1fch mais je reprends les points de @68tjs pour faire un bilan :
1/ après flashage pas d'impression dans le setup, quelle que soit la valeur du délai. Mais l'impression est parfaitement possible dans la loop. Je confirme ;
2/ Une "astuce " d'inversion de l'ordre d'écriture permettrait d'imprimer à partir de setup. C'est FAUX en ce qui me concerne ;
3/ . Cela ne se produit qu'après le flashage. Il n'y a aucune anomalie après un reset manuel. Je confirme que c'est bien le seul cas où ça fonctionne et J'ajoute que si je ferme le moniteur série et que je le réouvre le problème se produit également ;
4/ Si je teste sur une nano33 BLE, c'est le même problème avec en plus aucune impression dans le setup après un reset manuel sauf après un téléversement du code suivant ou un reset manuel avec ce même code :
void loop (void)
{
delay (1000);
Serial.println ("loop");
}
void setup (void)
{
Serial.begin (115200);
while (! Serial);
Serial.println("Just checking if it properly works");
}
Enfin je note que si j'essaye d'obtenir des infos sur la carte de @fasstoch : L'IDE m'indique que le port USB est natif et donc pas d'infos (contrairement à la nano33 BLE) :
Avec ce code et en reset manuel :
Voilà.
Bonne journée.
PS : Mac Sonoma 14.6.1 - Arduino IDE 1.8.19 - ESP32 EXPRESSIF 3.1.0 RC3
Bonjour @philippe86220
et avec un delay(5000) ou davantage ?