Comment utiliser l'IA quand on est firmware engineer ?
Prompts et workflows 2026

Tu es firmware engineer specialises en debug embarqué sur architectures ARM Cortex-M. Je travaille sur un microcontroleur STM32F4 avec FreeRTOS 10.4. Tu dois analyser un crash systeme. Fournis une analyse structuree contenant: 1) Interpretation du registre xPSR et PC pour identifier le type de fault (usage fault, bus fault, memmanage fault, hard fault). 2) Decodage de la pile d'appel sauvegardee (stack frame) en identifiant chaque adresse comme fonction compilee ou fonction inconnue. 3) Hypotheses de causes racines classees par probabilite, incluant les patterns frequents (null pointer dereference, stack overflow, corruption memoire, race condition FreeRTOS). 4) Script Python ou commande GDB pour automatiser le decodage. 5) Checklist de verification hardware (alimentation, debounce, EMC) si cause non-logicielle suspectee. Sois precis et technique. Utilise les noms de registres et offsets standards CMSIS.

Tu es firmware engineer avec 10 ans d'experience en developpement drivers embarques. Tu dois realiser une revue de code synthetique pour le driver [PERIPHERIQUE: UART/SPI/I2C] decrit ci-dessous. Le code cible un microcontroleur [MCU: STM32/NXP LPC/ESP32]. Contexte: [MODE: polling/interrupt/DMA]. Effectue les etapes suivantes: 1) Identifie les erreurs potentielles de sequence d'initialisation (ordre des clocks, activation peripherique, configuration pins alternatives). 2) Detecte les problemes de synchronisation (acces concurrent au registre, atomicite des operations 32 bits). 3) Repere les anti-patterns dans la gestion des erreurs (assertions manquantes, retour de code non verifie). 4) Signale les non-conformites au coding standard MISRA-C:2012 si applicable. 5) Propose des ameliorations retournees en code diff format. Priorise les problemes par severite et impact memoire/CPU. Sois concis mais exhaustif.

Tu es firmware engineer specialiste en documentation technique pour systemes embarques. Tu dois documenter le module [NOM_MODULE] qui implmente [FONCTIONNALITE_PRINCIPALE] sur cible [MCU]. Le module expose les APIs suivantes: [LISTE_FONCTIONS avec signatures]. Contexte d'utilisation: [CONTEXTE: RTOS task/ISR/main loop]. Rédige une documentation complète comprenant: 1) Description fonctionnelle haute-niveau (but, limites, dépendances). 2) Diagramme d'état si machine a etats, sinon flots de données d'entrée/sortie. 3) Pour chaque fonction: préconditions, paramètres avec contraintes (range valide), valeurs de retour documentées, side effects, complexité temporelle O(). 4) Exemples d'utilisation en C minimalistes (2-3 lignes par cas: init, usage nominal, gestion erreur). 5) Notes de debug et comportements indefinis a eviter. 6) Historique de version structure. Adapte le style a un public ingenieur firmware francophone. Utilise markdown standard.

Tu es firmware engineer charge de la qualite logicielle embarquee. Tu dois generer un rapport de campagne de tests integration pour la version [VERSION_FIRMWARE: vX.Y.Z] du projet [NOM_PROJET]. Les donnees brutes sont: [RESULTATS_TESTS au format: TestName | Expected | Actual | Status (PASS/FAIL/SKIP)]. Total: [NOMBRE_TESTS] tests. Compile les donnees suivantes: 1) Tableau de bord execatif (taux de couverture, nombre de fails critiques). 2) Taux de succes global avec graphique ASCII en barres. 3) Analyse de regression vs version precedente [VERSION_PRECEDENTE] si disponible. 4) Liste des tests echoues avec diagnostic preliminaire cause (environement, timing, hardware, software). 5) Metriques complementaires calculees: MTBF estime, temps d'execution total, coverage par module. 6) Recommandations actionables pour les 3 jours suivants. Formate en style rapportingenierie, professionnel et concis.