Oui, mais sans while(!Serial) il démare aussi 
.
Ce while(!Serial) est apparu avec le Léonardo (avr 8 bits 16 MHz).
Pour ce micro avr 8 bits 16MHz, le basculement de mode USB pouvait prendre du temps, ce qui reste à confirmer, je n'ai pas d'atmega32U2.
Mais, ceux qui en dispose peuvent faire la manip que je décrit pour les ESP32-C3 que j'ai testé.
J'ai tenté de mettre cette ligne while(!Serial) avec un RP2040 et un ESP32, cela n'a rien résolu.
Je l'ai remplacé par un délai, cela a fonctionné, mais en masquant l'origine du problème.
Dans le programme, en tête de setup() j'ai mis :
void setup(){
Serial.begin(115200);
//while(!Serial); NON NON NON
//delay(2000); NON NON NON
Serial.print("Tu vois que j'imprime sans while(!Serial) !");
..........
}
Mode opératoire :
- Je programme avec une IDE. Une fois le micro programmé je n'utilise plus l'IDE, mais j'utilise un terminal, CuteCom, très simple,
- Je configure le port à écouter et le débit.
- J'ouvre le port sur Cutecom. Le logiciel est prêt pour écouter le port.
- Je fais une RAZ (Reset) du programme sur le micro.
- Le micro redémare.
Dans le terminal, après les informations de boot, je vois s'afficher instantanément :
Tu vois que j'imprime sans while(!Serial) !
Il me semble que c'est la démonstration que ce n'est pas un probleme de stabilisation de l'UART de l'ESP32 puisque je n'ai mis aucune boucle d'attente ni de delais bloquants.
J'ai seulement changé de terminal série.
Mieux avec l'IDE Arduino où il faut préciser le port usb à écouter, si on fait juste un Reset alors que le moniteur est en service cela imprime aussi très vite.
Avec PIO, par défaut le logiciel fait une recherche automatique du port USB, cela prend plus de temps qu'avec le moniteur de l'IDE Arduino.
PIO peut permettre de fixer le port manuellement,, quand j'aurai le temps de rechercher la syntaxe, je ferai la manip.
Je suis persuadé que c'est bien un fonctionnement, somme toute normal, des IDE qui sont des agrégateurs de programmes.
Un seul programme à la fois peut prendre le contrôle de l'USB.
Il faut bien laisser le temps à l'IDE de fermer les Esptools utilisés pour la programmation, et de rouvrir le moniteur, qu'elle a fermé avant de lancer l'opération de programmation.
Si pendant ce temps 'technique" le micro envoie des Serial.print ils sont perdus.
Mon interprétation est que cela ne se voyait pas des micros lents et aussi que l'IDE issue de Wiring, lui même issu de Processing, était plus simple et pouvait être plus rapide que la V2 (c'est une supposition). La vitesse du PC hôte compte aussi.
Avr atmega328p = 8 bits tournant à 16 MHz.
ESP32-C3 = 32 bits tournant à 160 MHz.
J'avais déjà rencontré ce phénomène avec des RP2040.
C'est la répétition avec les ESP32 qui m'a fait approfondir le sujet.
Le meilleur conseil que je peux donner :
Soit :
Pour la phase de mise au point, vous ajoutez un délai de durée compatible avec votre IDE.
Si ce délai ne vous gêne pas en phase de production, vous le laissez, sinon vous le retirez pour la compilation finale.
Soit :
Vous n'ajoutez rien et vous faites un reset immédiatement après les premières écritures sur le moniteur.
Comme le moniteur sera resté actif, vous verrez les premières sorties.
