ESP32-C3 Super Mini bloqué, la vraie cause

C'est possible........ou pas.
Je ne fais que constater, mes connaissances théoriques en la matière étant insuffisantes.
Mais j'ai une certaine expérience dans l'analyse de ce qui se voit et de ce qui cause.

Sans débrancher quoi que ce soit, c'est très clair.
Si je lance un téléchargement avec l'IDE Arduino sans while ni délai.

  1. je perds les premiers serial.print de setup.
    Je n'ai jamais rien perdu dans loop.
    Ce n'est pas parce que je n'ai rien perdu dans loop que quelqu'un d'autre, avec un autre matériel, n'en perdra pas.

  2. Si, sans rien changer à l'IDE après une programmation, je fais un reset, au redémarage du micro je n'ai jamais perdu un message que ce soit avec le moniteur Arduino ou celui de Vscode.

  3. Si je prend l'IDE Arduino et si je déconnecte une carte et que je la reconnecte, l'IDE arduino avec sa configuration manuelle met peu de temps à la reconnaitre, c'est assez subjectif.

  4. Si je fais pareil avec PIO et sa recherche automatique, l'IDE met beaucoup plus de temps pour reconnaitre la carte. Cette fois, c'est du comparé.

  5. Si, toujours sans déconnecter quoi que ce soit, je ferme le moniteur de l'IDE et que j'ouvre un terminal, si je reset la carte je n'ai jamais rien perdu pendant le redémarrage.

Maintenant une ligne while(!serial) ne peut pas faire de mal même si je n'ai jamais vu son efficacité et donc son utilité.
Cela me parait être une vieillerie apparue avec le Léonardo et que l'on traine, comme souvent les vieilleries trainent dans la sphère arduino.

Tout évolue, tout s'améliore, les systèmes d'expliotations aussi.

En résumé, la perte des premiers Serial.print() se constate aussi bien avec l'Ide Arduino que plateformIO. Il n'y a pas de pertes des premiers Serial.print si l'IDE est en situation stable.

Quand un micro est en production, on ne le connecte pas à une IDE.
Au premier démarrage d'un micro en production, ou si on fait un Reset, on ne perd pas de message.

Ajouter une temporisation pour la phase de développement est du confort qui n'est pas pénalisant en production.
Donc en soit cela ne me gêne pas. Mais la cause des pertes de messages n'est pas l'absence de while(!serial); puisque sans cette ligne on ne perd pas de message en situation stable de l'IDE.

Dans Linux si j'ouvre un terminal et que je fais sans IDE en service et sans carte connectée :
$ls /dev/tty*
je ne vois pas apparaitre de ttyUSBx (ch340) ou de ACMx (USB natif).

Dès que connecte une carte à un port USB, je vois apparaitre
ttyUSB0 ou ttyACM0
Je vois que l'énumeration est automatique et instantanée.
Peut-être que Windows a besoin de cet artifice :grinning_face:

Pour revenir au sujet, le titre est faux et induit des débutants en erreur.

@gero33 ne savait pas que l'ESP32 n'active pas automatiquement l'USB natif, il faut le lui demander dans les directives des IDE.