Étape 7 : Changement de firmware et programmation de l'application

Retour sur Arduino IDE : le choix du cerveau, pas de l'ego

Après l'étape précédente, le constat était clair : notre firmware en C natif fonctionnait, notre chaîne de compilation maison avait du style, et nos scripts .bat avaient officiellement plus de vécu que certains serveurs de production. Mais pour les ECE du bac, il fallait quelque chose de démontrable, maintenable et compréhensible rapidement.

Nous avons donc migré le firmware vers Arduino IDE. Oui, ça fait un petit pincement au coeur quand on quitte les registres manipulés à la main pour retrouver pinMode(), digitalWrite() et analogWrite(). Mais techniquement, le choix est solide : on gagne en lisibilité, en vitesse de développement et en capacité à expliquer le système sans devoir sortir un tableau de conversion binaire au milieu de l'oral.

L'objectif n'était pas de "faire plus simple", mais de rendre le firmware robuste et défendable. Le microcontrôleur reste le même, la logique de commande aussi, mais le code devient plus accessible :

• initialisation claire des entrées et sorties ;
• gestion du module Bluetooth HC-05 via liaison série ;
• commandes moteur centralisées dans des fonctions lisibles ;
• arrêt prioritaire pour éviter qu'une consigne bancale transforme la banquette en ascenseur émotionnel ;
• base prête à recevoir les sécurités et limites mécaniques.

Nouveau protocole : simple, direct, efficace

Nous avons conservé une communication volontairement légère entre l'application et l'ATMEGA328P. Le principe reste le même : l'application envoie un caractère, le firmware l'interprète, puis le pont en H pilote le moteur.

Le firmware écoute donc le port série Bluetooth et réagit à des ordres courts :

if (Serial.available() > 0) {
  char command = Serial.read();

  switch (command) {
    case 'U':
      monterBanquette();
      break;
    case 'D':
      descendreBanquette();
      break;
    case 'S':
      arretMoteur();
      break;
  }
}

Ce n'est pas un protocole digne d'une sonde spatiale, mais pour notre système c'est exactement ce qu'il faut : peu de données, peu de latence, peu de risques de parsing douteux. Le Bluetooth transporte une consigne claire, le firmware exécute, et tout le monde garde son calme, ce qui est déjà une victoire dans un projet STI2D.

Programmation de l'application : enfin une interface pilotable

Côté application, nous avons repris la programmation de l'interface pour obtenir un outil réellement utilisable pendant les tests. L'idée n'est pas de faire une usine à gaz avec quinze menus et trois animations inutiles, mais une interface directe : connexion, commande, retour visuel.

L'écran principal met l'accent sur les actions essentielles : monter, descendre, arrêter. Les boutons doivent être gros, clairs et accessibles, parce qu'un bouton d'arrêt caché dans un sous-menu, c'est peut-être design, mais c'est surtout une très mauvaise idée quand un moteur est en train de tourner.

Nous avons aussi travaillé la séparation entre l'affichage et la logique de communication. L'application ne doit pas seulement être jolie sur une capture d'écran : elle doit envoyer les bonnes commandes au bon moment, gérer l'état de connexion et éviter d'envoyer des ordres contradictoires.

Derrière l'interface : la partie moins glamour mais indispensable

La partie arrière de l'application contient la logique qui fait le lien avec le module Bluetooth. C'est là que l'on prépare les commandes, que l'on vérifie la connexion, et que l'on évite de spammer le microcontrôleur comme si le bouton avait été confié à quelqu'un sous caféine industrielle.

Techniquement, cette couche doit rester simple et fiable :

• une fonction par commande (monter, descendre, stop) ;
• un envoi série propre vers le HC-05 ;
• une gestion des erreurs de connexion ;
• aucune commande moteur si l'application n'est pas connectée ;
• un arrêt disponible à tout moment.

Cette séparation nous permet de tester l'application plus proprement. Si un bouton ne déclenche pas la bonne action, on sait où regarder. Si la commande part mais que le moteur ne bouge pas, on bascule côté firmware ou électronique. Bref, on évite la grande tradition du "ça marche pas" sans savoir si le problème vient du code, du Bluetooth, du pont en H, de la batterie, ou d'une soudure qui a décidé de vivre sa propre vie.

Tests croisés : application, Bluetooth, firmware, moteur

Une fois les deux parties prêtes, nous avons procédé par validation progressive. D'abord l'application seule, puis l'envoi des caractères Bluetooth, ensuite la réception côté microcontrôleur, et enfin le pilotage réel du pont en H.

Cette méthode évite de tout brancher d'un coup et de découvrir que rien ne marche, ce qui est certes spectaculaire, mais moyennement productif. Chaque étage a été isolé :

1. l'application génère la bonne commande ;
2. le module HC-05 transmet correctement ;
3. l'ATMEGA328P lit le caractère reçu ;
4. le firmware appelle la bonne fonction moteur ;
5. le pont en H applique la tension dans le bon sens ;
6. le bouton stop coupe immédiatement la commande.

Le résultat est nettement plus propre : le projet devient pilotable, explicable et testable. Le changement de firmware n'a donc pas été un recul technique, mais une adaptation stratégique. On garde le sérieux de l'architecture, on réduit les points de friction, et on arrive avec une solution qui se défend devant un jury sans nécessiter trois incantations en assembleur.

Bilan de l'étape

Cette étape marque un vrai verrouillage logiciel du projet. Le firmware est revenu sur une base Arduino plus adaptée au contexte scolaire, l'application possède une interface exploitable, et la communication Bluetooth reprend une forme simple mais efficace.

Prochaine cible : fiabiliser les tests complets avec l'électronique finale, vérifier les comportements limites, et s'assurer que la banquette obéit à l'application avec la discipline d'un système embarqué bien élevé. Ou au moins mieux qu'un PC de développement en fin de vie.