Retour en S4 dans laquelle les ingénieurs logiciels ont repris le collier. Sur le mur une belle affiche montrant une coupe de la fusée avec tout en haut dans la coiffe la sonde bien lovée force la bonne humeur. Plusieurs articles ont été découpés dans la presse locale. L’autre nuit, le décollage avait un peu paralysé les esprits, car un lancement n’est jamais de la routine. Un petit rien peut tout faire capoter. Quand la puissance est nominale sur tous les moteurs et que l’ordinateur détectant une poussée supérieure au poids de l’ensemble débride la fusée, le sort du lanceur et de sa charge utile est définitivement scellé. On ne peut plus rien faire, il faut impérativement qu’une mise en orbite soit effective. Si ce n’est pas le cas, le projet tombe à l’eau … de mer ! Et encore, faut-il que l’orbite atteinte permette ensuite une éjection vers Mars. On ne peut plus compter sur un sauvetage avec la Navette. Aussi, quand le D.D.O. à confirmé une trajectoire correcte vers la planète rouge, toute l’équipe a poussé un soupir de soulagement et fait éclater sa joie. La mission des « binaires » n’est pas pour autant terminée, il reste encore pas mal de travail sur la planche …
Faire des économies, un leitmotiv souvent entendu aux informations du 20H.
Force est de constater que le programme complet actuel est un peu obèse. Il intègre des fonctions qui sont bien utiles pour les programmeurs, mais dont les techniciens d’exploitation n’ont que faire. Par exemple lister le contenu de l’EEPROM. Franchement, faire afficher tous les octets est spectaculaire. Mais c’est totalement stérile pour s’occuper de JEKERT sur le sol poussiéreux. Aussi, si c’est pour vérifier le contenu de l’EEPROM quand on a modifié le programme pour des adaptations locale, rien n’interdit de téléverser P30, de vérifier à loisir le contenu de la mémoire non volatile puis de reloger le programme d’exploitation. Le nouveau noyau qui servira à dialoguer avec une raquette de pilotage est nommé P30_Programme_COMPLET_T5.ino et contient tous les changements qui vont se voir explicités dans les chapitres qui suivent de ce TOME 5.
Première modification : Avant d’envisager une purge, au contraire on va ajouter une commande car avec tous ces démonstrateur, arrive un moment où on ne sait plus quel est le dernier logiciel téléversé. Alors tant pis pour la boulimie, on ajoute « « * » qui aura pour effet d’indiquer sur le moniteur la version du code objet qui « tourne » actuellement sur la carte Arduino NANO. Cette référence est désignée comme constante dans les lignes //@@@@@@@@@@@@@ et sera modifiée pour chaque nouveau démonstrateur.
GLUPS ! Quand on ajoute la ligne de code qui fait afficher la version … la taille du programme diminue de 14 octets, c’est fabuleux. (La compilation a parfois des effets difficiles à interpréter …) Par contre, dans les variables dynamiques on consomme 14 octets de plus correspondant à la constante chaîne de caractères « Version P30-T5. ». Ce n’est donc pas totalement gratuit.
– Héééé, Totoche, j’ai trouvé un régime que plus tu manges, moins tu pèse !
Supprimer la fonction de listage de la mémoire fait économiser 272 octets. De plus, la commande « z* » redevient disponible. Elle sera donc utilisée pour faire afficher la version du programme.
Reporter la responsabilité sur les autres !
Fausse bonne idée : La technique qui impose un programme préalable s’avère mal pensée. Elle paralyse globalement les manipulations, car on est en permanence agressé par des « !ERR 21!« alors que la commande envoyée est potentiellement sans danger. Par exemple envoyer deux fois de suite « p03* » provoque une erreur, alors que faire avancer deux fois la sonde ne risque pas de provoquer des interférences matérielles internes. Aussi, si l’on passe en revue les divers programmes, il n’y en a que trois ou quatre qui risquent de conduire à des incidents.
CHANGEMENT DE STRATÉGIE : Sur le programme qui anime JEKERT on élimine tous les tests relatifs au programme préalable. Pour les commandes qui potentiellement engendrent un risque, on traitera la vérification sur le programme de la raquette de pilotage.
C’est cette modification qui justifie que sur la Fiche n°28 l’organigramme a été barré en vert.
Cette simplification rend les campagnes de test plus faciles et fait gagner encore 70 octets de programme. Par ailleurs on élimine le tableau des préalables ce qui diminue de 24 emplacements la place occupée en mémoire dynamique. Ces quelques modifications rendent les tests plus simples et font gagner 356 octets pour le programme, c’est loin d’être négligeable.
La suite est ici.
