Bilan, perspectives & conclusion

La SAE avait pour ambition de couvrir l'intégralité de la chaîne de conception d'un système embarqué, depuis l'idée jusqu'au prototype démontrable. À ce titre, le projet a effectivement mobilisé un large éventail de compétences techniques, complémentaires les unes des autres.

La conception mécanique a été menée sous SolidWorks, pour modéliser le support et l'enveloppe destinés à accueillir l'écran, la manette et la carte son, et pour vérifier la cohérence dimensionnelle de l'assemblage (cotes exactes à confirmer). La conception électronique s'est appuyée sur KiCad 9 : tracé du schéma de la carte son autour de l'amplificateur LM386, routage du circuit imprimé double face de 45 mm × 45 mm en composants traversants (THT), puis génération des fichiers de fabrication (Gerbers : couches cuivre F_Cu et B_Cu, masques de soudure, sérigraphie, perçages PTH et NPTH).

La réalisation et le brasage du PCB ont prolongé naturellement cette phase : à la réception du circuit nu, le binôme a brasé au fer à souder les composants traversants, effectué un contrôle visuel des soudures, recherché d'éventuels courts-circuits et mesuré la continuité des pistes. Le développement embarqué a été conduit sous MPLAB X IDE avec le compilateur XC8 et l'outil MCC (MPLAB Code Configurator), depuis la configuration des périphériques du PIC16F18877 - convertisseur ADCC, bus SPI1 (MSSP1) et oscillateur numériquement commandé NCO1 - jusqu'à l'écriture de la logique de jeu, du moteur de rendu graphique et de la génération sonore.

Enfin, le câblage et l'intégration ont relié physiquement l'ensemble - écran ILI9488, manette à base de PIC, carte son et alimentation - et la validation expérimentale a consisté à éprouver la jouabilité réelle, à corriger les défauts observés et à confirmer que matériel et logiciel coopèrent de façon fiable. Cette diversité de compétences, exercée sur un même objet cohérent, constitue sans doute l'apport le plus précieux du projet.

S'il fallait retenir une seule idée directrice de ce projet, ce serait celle-ci : tout le logiciel a été pensé pour tirer le meilleur parti d'un microcontrôleur modeste. Le PIC16F18877 ne possède aucune unité de calcul en virgule flottante matérielle ; chaque opération sur des réels (cosinus, sinus, racine carrée) est émulée par logiciel et donc coûteuse en cycles. Trois stratégies, déclinées tout au long du rapport, en découlent directement.

Éviter le flottant en cours de jeu

Plutôt que de calculer l'orientation du vaisseau par des fonctions trigonométriques, le programme exploite le fait que le vecteur normalisé du joystick vaut déjà (cos, sin). On dispose ainsi gratuitement du couple shipCos, shipSin sans appeler atan2, cos ni sin. De même, le demi-angle arrière du vaisseau est figé sous forme de constantes précalculées (COS245 = −0,7705 et SIN245 = 0,6374, soit le cosinus et le sinus de 2,45 rad), ce qui évite tout calcul trigonométrique répété à l'affichage. Cette approche illustre une règle d'or de l'embarqué : déplacer le calcul du temps réel vers le temps de compilation.

Ne redessiner que ce qui change

Le moteur de rendu n'efface jamais l'écran entier à chaque image. Il applique le principe effacer / déplacer / redessiner : un objet est repeint en noir à son ancienne position, puis dessiné à sa nouvelle position. Le seuil ANGLE_REDRAW_DOT = 0,9997 (un produit scalaire correspondant à un écart d'environ 1,4°) évite même de redessiner le vaisseau tant que son orientation n'a pas suffisamment varié. On économise ainsi un grand nombre d'écritures coûteuses sur le bus SPI, où chaque pixel coûte trois octets (couleur 18 bits).

Comparer les distances au carré

Pour la détection des collisions, comparer une distance à une somme de rayons exigerait une racine carrée. En élevant les deux membres au carré, on remplace cette opération coûteuse par de simples multiplications, sans rien perdre en exactitude - l'équivalence d ≤ r ⇔ d² ≤ r² étant rigoureusement vraie pour des grandeurs positives. Concrètement, le test d'impact ne s'écrit pas avec sqrtf mais sous la forme suivante :

float dx = ax - bx;
float dy = ay - by;
float r  = AST_RADIUS + BULLET_RADIUS;
if (dx*dx + dy*dy <= r*r) {
    /* collision : asteroide touche */
}

Ligne par ligne : dx et dy calculent l'écart de coordonnées entre les deux objets (par exemple un astéroïde et un projectile) ; r est la somme des deux rayons, c'est-à-dire la distance en dessous de laquelle les deux disques se chevauchent ; enfin le test compare le carré de la distance dx*dx + dy*dy au carré du seuil r*r. On n'extrait jamais la racine carrée : trois multiplications et une comparaison suffisent. Ce compromis entre exactitude géométrique et coût de calcul résume à lui seul l'esprit du projet.

On retrouve la même philosophie côté son : le NCO1, dont l'accumulateur 20 bits est cadencé par FOSC/4 = 8 MHz, délivre une fréquence f = (8 000 000 × NCO1INC) / 2²⁰ ≈ NCO1INC × 7,6294 Hz. Pour fixer un ton, le code écrit NCO1INC = frequence >> 3, c'est-à-dire une division par 8 réalisée par simple décalage de bits. Le facteur exact serait 0,1311, mais 1/8 = 0,125 en est une excellente approximation, instantanée pour le processeur - un nouvel exemple où l'on préfère un décalage entier à une multiplication flottante.

Au terme de cette SAE, Emma Grosmaire et Dorian Sausse retiennent une expérience particulièrement formatrice. Le projet a eu le mérite de relier entre elles des compétences souvent abordées séparément en formation : la conception mécanique sous SolidWorks, l'électronique analogique (la carte son à LM386), la fabrication d'un circuit imprimé et la programmation embarquée se sont ici rejointes au service d'un même objectif concret et motivant. Contraints par les limites d'un microcontrôleur 8 bits dépourvu de calcul flottant matériel, ils ont compris de façon tangible pourquoi certaines optimisations - éviter le flottant, ne redessiner que l'essentiel, raisonner sur des distances au carré - ne sont pas de simples astuces mais des réflexes d'ingénieur.

Le travail en binôme a également constitué un apprentissage en soi : répartition des tâches selon les affinités, mise en commun régulière des avancées, partage des phases d'intégration et de test, et résolution conjointe des difficultés rencontrées. Voir le prototype fonctionner - un vaisseau qui pivote au centre de l'écran, des projectiles qui détruisent les astéroïdes, un score qui grimpe de dix en dix et un son qui accompagne l'action - a procuré une réelle satisfaction, à la hauteur de l'investissement consenti.