Tests, validation & difficultés
Tests unitaires par sous-système, tests d'intégration, résultats obtenus et difficultés rencontrées au cours du projet.
Démarche de validation
Un prototype embarqué ne se valide pas d'un seul bloc. La démarche adoptée a consisté à vérifier d'abord chaque sous-système isolément (l'écran, la carte son, le joystick, les boutons, le générateur de son), puis à intégrer l'ensemble et à observer le jeu complet en fonctionnement. Cette progression du composant vers le système permet de localiser rapidement l'origine d'un dysfonctionnement : un défaut détecté tôt, sur un module isolé, coûte bien moins cher à corriger qu'un défaut découvert dans le jeu assemblé. Ce chapitre présente les tests unitaires par sous-système, les tests d'intégration, une synthèse qualitative des résultats, puis un inventaire raisonné des difficultés rencontrées, classées par nature et accompagnées pour chacune de leur cause, de leur conséquence et de la solution appliquée.
Valider chaque brique isolément avant l'intégration permet d'isoler une panne à son module d'origine, là où elle est la moins coûteuse à corriger.
Tests unitaires par sous-système
Écran TFT ILI9488
Le premier test consiste à exécuter l'initialisation ILI9488_Init puis à remplir tout l'écran d'une couleur unie via display_fillScreen. Si le panneau s'allume et affiche un aplat homogène, c'est que la séquence d'init (sleep out, display on, format de pixel 18 bits 0x66) et la liaison SPI fonctionnent. On teste ensuite l'adressage avec display_fillRect pour vérifier que la fenêtre setAddrWindow cible les bonnes colonnes (CASET 0x2A) et lignes (PASET 0x2B) avant l'écriture en mémoire vidéo (RAMWR 0x2C). Enfin, l'affichage de texte par display_printText valide la police 5x7 et l'orientation paysage (setRotation(3), soit 480x320 pixels). Un écran qui resterait blanc ou afficherait du bruit oriente immédiatement vers le câblage SPI (SCK sur RC3, MOSI/SDI sur RC5, CS sur RC0, DC sur RC2, RST sur RC1) ou vers l'alimentation du module.
Carte son
Le module amplificateur à base de LM386 (U1) se teste en injectant un signal connu sur l'entrée J2 (Audio_In), c'est-à-dire la sortie NCO1 du PIC sur RA6 (patte 14). Après mise sous tension par le connecteur J1 et l'interrupteur à glissière SW1, on écoute la présence du son dans le haut-parleur relié à J3 (Audio_out) et on agit sur le potentiomètre RV1 (10 kOhm) pour vérifier que le volume varie de façon continue. On contrôle l'absence de souffle excessif ou d'oscillation parasite, signe que le découplage (C2 100 nF, C3 10 uF, et C4 10 uF sur la broche BYPASS du LM386) et le réseau de Zobel (R2 100 Ohm + C5 47 nF) jouent bien leur rôle de stabilisation.
Joystick analogique
On vérifie d'abord que le convertisseur ADCC (10 bits) renvoie une valeur cohérente sur la plage 0 à 1023 pour chacun des deux axes (axe X sur RC7 / patte 22, axe Y sur RC6 / patte 21). Au repos, les deux axes doivent se situer près du milieu de course. La routine de calibration moyenne plusieurs relevés pour fixer le centre joyCx/joyCy ; on s'assure ensuite que pousser le manche dans une direction fait croître ou décroître la valeur de manière monotone, et que la zone morte JOY_DEADZONE (valeur 32) supprime bien le tremblement au repos.
Boutons poussoirs
Les boutons étant actifs à l'état bas (résistance de tirage pull-up : relâché = 1, appuyé = 0), on vérifie la lecture de chaque entrée : BTN_B (RD6 / patte 29, tir), BTN_C (RD5 / patte 28, jouer/retour/menu) et BTN_D (RD4 / patte 27, réglages). Le bouton BTN_A (RD7 / patte 30) n'est pas utilisé. Le test porte surtout sur la détection de front : un appui ne doit déclencher qu'une seule action, même si le doigt reste posé. On confirme donc qu'un tir part une fois par appui et non en rafale tant que le bouton est maintenu.
Générateur de son NCO1
On valide enfin que la fréquence demandée correspond bien au ton entendu. Le NCO1, dont l'horloge source est FOSC/4 = 8 MHz et l'accumulateur fait 20 bits, produit une fréquence de sortie :
f = (8 000 000 x NCO1INC) / 2^20 = NCO1INC x 7,6294 HzLe code écrit NCO1INC = frequence >> 3, c'est-à-dire une division par 8 (0,125) réalisée par simple décalage de bits, beaucoup plus rapide qu'une vraie division sur un cœur 8 bits. En combinant l'écriture et la formule de sortie, le ton effectivement joué vaut environ frequence x 0,9537, donc très proche de la valeur demandée. L'écart provient du fait que le décalage >>3 (0,125) n'est qu'une approximation du facteur théorique exact 0,1311 ; il reste inaudible à l'oreille : un bip aigu demandé reste un bip aigu.
Tests d'intégration
Une fois chaque brique validée, le jeu complet est assemblé et éprouvé. On vérifie d'abord l'enchaînement des quatre états de la machine (ETAT_MENU, ETAT_REGLAGES, ETAT_JEU, ETAT_GAMEOVER) : depuis le MENU, le bouton REGLAGES (RD4) ouvre l'écran des commandes, le bouton JOUER (RD5) lance la partie après un compte à rebours, et une collision conduit au GAME OVER d'où l'on revient au menu. La jouabilité est évaluée manuellement : rotation du vaisseau à la commande du joystick, départ des projectiles au bouton de tir, surgissement des astéroïdes depuis les bords vers le centre. On observe la fluidité (absence de scintillement, rotation continue à l'œil), la justesse des collisions (un tir bien placé détruit l'octogone, un astéroïde qui atteint le centre provoque la fin de partie) et la mise à jour correcte du score (+10 par astéroïde détruit, affiché dans le bandeau HUD de hauteur HUD_H = 24 pixels).
Résultats obtenus
À l'issue de ces essais, le prototype est jugé fonctionnel : le jeu est jouable de bout en bout, le son est présent et réglable, et l'affichage restitue fidèlement les formes attendues (vaisseau triangulaire au centre, astéroïdes octogonaux, projectiles, HUD). Le tableau ci-dessous synthétise la campagne de tests de manière qualitative, sans chiffre mesuré.
| Élément testé | Méthode | Résultat attendu | Résultat obtenu |
|---|---|---|---|
| Écran : init et remplissage | display_fillScreen couleur unie |
Aplat homogène plein écran | Conforme |
| Écran : texte | display_printText police 5x7 |
Caractères lisibles, bonne orientation | Conforme |
| Carte son : signal | Injection NCO1 sur J2, écoute sur J3 | Son audible, volume réglable par RV1 | Conforme |
| Joystick : lecture ADC | Relevé des axes X/Y (0-1023) | Variation monotone, centre stable | Conforme |
| Joystick : zone morte | Manche au repos | Vaisseau immobile, sans tremblement | Conforme |
| Boutons : front | Appui unique sur B/C/D | Une seule action par appui | Conforme |
| NCO : fréquence | Comparaison ton demandé / entendu | Ton proche de la consigne | Conforme (écart inaudible) |
| Enchaînement des états | Parcours MENU -> JEU -> GAME OVER | Transitions correctes | Conforme |
| Collisions et score | Tirs et impacts en jeu | Destruction (+10) et GAME OVER | Conforme |
L'affichage final, photographié écran allumé, confirme la fidélité du rendu observé au cours des tests.
Difficultés rencontrées
Difficultés mécaniques
Le principal point d'attention a porté sur l'ajustement des supports et l'encombrement : il a fallu loger ensemble la carte du PIC, la carte son (PCB de 45 mm x 45 mm) et l'écran sans contrainte sur les connecteurs. Cause : plusieurs cartes à fixer dans un volume réduit. Conséquence : risque de tension sur les fils et de mauvais maintien mécanique. Solution : adaptation des supports pour répartir les modules et dégager les zones de câblage (côtes exactes à confirmer).
Difficultés électroniques
Le brasage de la carte son, entièrement composée de composants traversants (THT) au fer à souder, a demandé du soin. Cause : nombreuses soudures rapprochées autour du LM386 (boîtier DIP-8) et des connecteurs. Conséquence : risque de pont de soudure et de court-circuit, ainsi que de bruit audio. Solution : contrôle visuel systématique, recherche de courts-circuits et mesure de continuité après brasage ; côté conception, la maîtrise du bruit repose sur le découplage de l'alimentation (C2 100 nF, C3 10 uF) et de la broche BYPASS du LM386 (C4 10 uF), ainsi que sur le réseau de Zobel (R2 100 Ohm + C5 47 nF) qui prévient les oscillations en sortie, le condensateur C6 (220 uF) assurant la liaison vers le haut-parleur.
Difficultés logicielles et d'intégration
Difficultés logicielles
Plusieurs obstacles propres au PIC16F18877 ont orienté l'écriture du code, dont le cœur 8 bits cadencé à Tcy = 125 ns ne dispose d'aucune unité de calcul flottant matérielle.
- Calculs flottants lents : dépourvu de FPU, le PIC16 émule logiciellement
cos,sin,atan2etsqrtf, opérations coûteuses en pleine boucle de jeu. Conséquence : risque de ralentissement et de saccades. Solution : éviter ces fonctions en exploitant directement le vecteur normalisé du joystick, dont les composantes valent déjà (cos, sin) de l'angle visé (shipCos,shipSin), et comparer les distances au carré lors des collisions plutôt que d'extraire une racine carrée. - Clignotement de l'image : tout redessiner à chaque tour faisait scintiller l'affichage. Cause : effacement intégral de l'écran à chaque trame. Solution : ne redessiner que ce qui change (effacer l'ancienne position, déplacer, redessiner), le seuil
ANGLE_REDRAW_DOT(0,9997, soit environ 1,4 degrés) évitant même de retracer le vaisseau lorsqu'il n'a quasiment pas tourné. - Durée maximale de
__delay_ms: cette macro est bornée par la fréquence d'horloge, ce qui interdit les longues temporisations en un seul appel. Solution : découper les attentes (par exemple le compte à rebours) en plusieurs appels successifs plus courts. - Sens des axes du joystick : selon le câblage, un axe pouvait être inversé. Conséquence : commande perçue à l'envers. Solution : prévoir des réglages logiciels (
JOY_X_SIGNpour le signe de l'axe X, et la prise en compte de l'orientation verticale du typeTOP_IS_LOW) afin d'aligner le sens perçu sur le sens attendu sans retoucher le matériel.
Difficultés d'intégration
Relier trois sous-ensembles a imposé un câblage propre. Cause : multiples liaisons (SPI vers l'écran, audio de RA6 vers la carte son, alimentations +5 V). Conséquence : risque de masses flottantes et de mauvais contacts. Solution : soin du câblage, mise en commun rigoureuse des masses (GND partagés entre les cartes) et exploitation du fait que la liaison SPI vers l'écran est à sens unique (PIC vers écran, ligne MISO inutilisée par le programme), ce qui simplifie le raccordement et réduit les sources d'erreur.
Sur un cœur 8 bits sans virgule flottante, la fluidité du jeu repose sur des choix d'algorithmes : vecteur joystick déjà normalisé en (cos, sin), comparaison des distances au carré, et redessin partiel de l'écran plutôt qu'effacement complet à chaque trame.