Presque de la routine, nous allons passer pas mal de temps en salle informatique S4 car écrire les programmes qui seront logés dans l’ordinateur de la sonde va se tailler la part du lion en heures d’ingénieurs spécialisés. Il faut débroussailler la route, avec en permanence l’obsession d’optimiser à outrance le code, car nous savons que c’est le manque de place dans la mémoire qui limitera nos espérances. Du reste, quand l’échéance du décollage commencera à montrer le bout du nez, nous serons peut être obligés de faire un peu de place en effaçant des fonctions bien au point mais estimée « peu utiles ». La configuration « tous les moteurs au neutre » en est un exemple potentiel.
EEPROM or not EEPROM ?
Profiter au mieux la logique électronique disponibles dans l’ATmega328 nous impose de tester l’utilisation de l’EEPROM. Cette approche fait partie de ce qui avait été formulé comme Utiliser toutes les ressources de l’ATmega328. Deux phénomènes contradictoires vont s’opposer. Vouloir utiliser la mémoire non volatile imposera forcément l’appel à une bibliothèque qui va goinfrer sa part d’octets. En revanche, on passera tous les textes en EEPROM ce qui n’aura aucun effet pour l’encombrement du programme, mais économisera de la place en RAM dynamique. Il ne faut surtout pas gaspiller cette dernière car vers la fin des hostilités on risquerait une collision entre la PILE et le TAS. Surtout, il deviendra possible de coder les valeurs d’une configuration dans un tableau d’entiers qui sera lui-même logé en EEPROM. La procédure pourra alors se passer du passage des douze paramètres. On sera certainement gagnant au final … ce qui reste à prouver.
– Jour Tassin, vous avez l’air de bien bonne humeur ce jour julien 58030.
– Exact GC, on a basculé les data en non volatile.
– Et alors ?
– Ben on gagne plus de 900 pillules !
– Neuf cents octets, tant que ça ?
– Et c’est pas tout, en dynamique on en économise pas moins de 50.
– Fabuleux, vous avez fait un sacré bon travail hier.
– Chuis pas le seul, ya Ferrando qui s’est chargé de scribouiller les valeurs dans l’EEPROM.
– C’est parfait, je vais le féliciter de ce pas.
Alors que nous nous déplaçons vers la console du programmeur, Tassin nous interpelle :
– Grand Chef ?
– Oui ?
– Sans compter que maintenant chaque nouvelle config ne coute plus que 12 octets, pas un de plus.
Vous avez déjà tous intuité que le bénéfice tiré de l’utilisation de l’EEPROM pour y loger les données est considérable. Les routines pour pouvoir lire dans la mémoire non volatile n’emploient que soixante octets, fonction int Lire_un_Entier_en_EEPROM(int ADRESSE) comprise. Finalement l’investissement est presque négligeable. En revanche, la procédure de base void CONFIGURER(int PTR_TABLE) se résume maintenant à peu de chose. Une vulgaire boucle, il n’y a plus à lui passer douze paramètres. Le tableau des Butées logicielles a émigré en EEPROM ce qui fait économiser 48 octets en mémoire dynamique. Enfin, configurer se contente maintenant de faire appel à une procédure. On élimine ainsi toutes les routines qui réalisaient chaque configuration.
CONCLUSION : Loger les textes en EEPROM complique substantiellement la programmation car le programme devient bien moins lisible. Il faut en outre ajouter du code ce qui augmente potentiellement la taille du programme. Cette technique ne sera envisagée que si l’espace libre en mémoire dynamique devient critique. Par contre, toutes les données qui consomment assez d’octets pour que ce soit rentable émigreront en EEPROM de l’ATmega328.
Écrire les données en EEPROM.
C’est le prix à payer pour bénéficier de cette évolution majeure du logiciel, mais vous vous en doutiez car rien n’est gratuit ici bas. Pas de panique, comme pour tout ce qui concernera ce projet, systématiquement je vous livrerai les outils « clef en main ». Libre à vous d’en décortiquer en détail le fonctionnement, ou de vous contenter d’exécuter le petit programme, et vogue la galère. Le programme de servitude qui nous servira à loger en EEPROM un maximum de données numériques est nommé P29_Ecriture_des_tableaux_en_EEPROM.ino dans un souci d’originalité. Curieusement, on s’attendrait à ce qu’il soit le n°9 dans l’ordre où sont créés les démonstrateurs. En réalité, vous allez utiliser un « programme outil » qui aura été complété probablement plusieurs fois, car il me semble inévitable qu’au cours des développements logiciels je vais y ajouter d’autres données. Pour le retrouver facilement, car c’est souvent que je risque d’avoir à le compléter, le placer juste avant le dernier programme me facilite la vie. Tout est dit …
Avant de téléverser le code objet dans le calculateur de JEKERT, il vous faut impérativement remplacer les données relatives à mes SG90 par celles personnelles que vous aviez placé dans les programmes précédents. Rassurez-vous, P29_Ecriture_des_tableaux_en_EEPROM.ino est copieusement documenté, avec les séquences du programme bien séparées par des commentaires. Surtout, les lignes de données sont organisées par Jambes facilitant pour vous la mise à jour.
Quand vous avez transposé les données pour qu’elles correspondent à celles de vos moteurs et de leurs Butées logicielles, téléversez le code dans le calculateur de la sonde. Puis, activez le Moniteur de la ligne série USB de l’IDE. L’affichage fonce comme une bête apeurée puis se fige. Mis à part des valeurs qui seront différentes, le haut de la page affichée sur le moniteur vidéo de votre P.C. ressemblera à celle de la Fig.90 pour laquelle la valeur de chaque octet est exprimée en Hexadécimal. Cette base est illisible mais produit des espacements constants, on voit ainsi « les octets » de l’EEPROM bien alignés. Immédiatement on situe les emplacements occupés de ceux inutilisés. Si vous n’avez jamais inscrit quoi que ce soit dans l’EEPROM, au départ tous les octets sont vierges et contiennent que des « 1 » logiques, soit en Hexadécimal la valeur $FF. Si la mémoire avait déjà été plus ou moins gavée de données, le total du listage sera « brouillé » et illisible. C’est la raison pour laquelle l’adresse relative en EEPROM du début de chaque bloc de donnée et précisée en tête du listage. Vous pouvez vérifier que le premier bloc contient 48 octets, et contient la table des Butées logicielles. Puis, chaque bloc suivant fait 24 octets soit les douze entiers relatifs à une configuration. La dernière adresse indiquée correspond au premier octet non utilisé dans la mémoire non volatile. Puis, l’intégralité de la mémoire est listée. Enfin, à la verticale va se « dérouler » une haute colonne de valeurs qui correspondent aux données 
numériques inscrites dans le microcontrôleur. Empilées de la sorte la lecture n’est pas des plus faciles, raison pour laquelle la Fig.91 regroupe les données par douze correspondant aux consignes des diverses configurations. En jaune l’étendue est deux fois plus importante car il s’agit des Butées logicielles. Sans que ce soit d’une facilité déconcertante, la relecture et la vérification des valeurs reste malgré tout relativement aisée. Ce n’est que lorsque vous serez certain d’avoir bien complété l’outil P29_Ecriture_des_tableaux_en_EEPROM.ino avec les bonnes valeurs que vous pourrez passer à l’exploitation de ces données. Il suffit que l’une de ces consignes soit erronée pour risquer de voir un membre de la sonde aller en butée mécanique avec forçage des moteurs : Bouton de panique !
Rassurez-vous, pour mettre au point tous les programmes qui vous sont fournis quand ils ont fait leurs preuves, cet incident est arrivé à plusieurs reprises. Rapidos on coupe l’alimentation de puissance avec le Switch de panique, puis on débranche la fiche banane qui va au +5Vcc de puissance. On débloque alors la petite mécanique qui est coincée. On corrige le programme et l’incident est clos. Bien que ce ne soit pas du tout recommandé d’amener un SG90 en butée mécanique avec forçage, ils sont tout de même conçu pour résister à ces maltraitances, à condition de ne pas exagérer trop souvent. C’est ici que la rigueur d’analyse se montre notre meilleure alliée …
Étant certains que vos données de consigne en EEPROM sont correctes, vous pouvez téléverser le démonstrateur P09_Utilisation_EEPROM.ino qui présente strictement les fonctions qui étaient intégrées dans le programme P07 sauf que le code est réécrit pour exploiter des données logées en EEPROM. Utilisez les informations disponibles par le Moniteur de l’IDE pour vérifier moteur par moteur que les Butées logicielles sont exacte. Puis testez les cinq configurations qui toutes doivent correspondre aux postures obtenues avec P07.
Les portraits de famille.
Dans la salle de réunion S7 c’est la fête. Le planning est respecté, la sonde commence à bouger ses papattes. Pour le moment les essais au sol n’ont pas encore débutés, tous les mouvements sont effectués dans le vide, le bouclier ne quittant pas le berceau. La voir faire gigoter à une rapidité surprenante ses membres est assez fascinant. Tous les personnels autorisés ont été invités à admirer par la grande vitre blindée de S6 la belle machine adopter en des durées très courtes des postures si particulières. Ensuite, les rideaux de « discrétion » ont été refermés, et les personnels réunis en S7. Les bavardages joyeux vont bon train accompagnés comme il se doit par divers comestibles et fluides festifs. En ce qui nous concerne, nous regarderons la petite machine « à travers une galerie de photographies ». Ces images permettront à tous ceux qui le désirent, de mieux situer certains détails que les épures ne révèlent pas forcément. Toutes ces images sont disponibles dans le dossier dédié < Galerie d’Images >. En voici le contenu actuel :
Image 01.jpg : Posture où toutes les articulations sont au « Neutre opérationnel ». Peu utile en exploitation, cette attitude permet de vérifier les déphasages angulaires avec les secteurs gradués lors de l’assemblage des diverses Jambes.
Image 02.jpg : Configuration Décollage. Observez la compacité. Si ce n’est les fils électriques qui ne sont pas encore proprement coiffés, le volume adopté est bien minimalisé.
Image 03.jpg : En vue de dessus c’est encore plus impressionnant. L’écart entre les deux Jambes est vraiment faible. Quand cette posture est déclenchée, voir « foncer » la mécanique et stopper les organes si proches les uns des autres est assez sidérant.
Image 04.jpg : Configuration Atterrissage, les membres sont « escamotés » sur le dessus.
Image 05.jpg : Configuration Stable Raisonnable.
Image 06.jpg : Configuration Hauteur maximale.
Dernière couche avant de quitter le berceau.
Couche logicielle s’entend, mais vous l’aviez compris ! Sans avoir du tout défriché le terrain, ce sera l’objet du prochain chapitre, il est naturel d’imaginer que faire marcher un insecte robotisé n’aura rien d’évident. Se déplacer sur des jambes place infiniment plus haut la barre de la difficulté par rapport au roulage tel qu’il est pratiqué sur la quasi totalité des machines terrestres. Paradoxalement, la nature à multiplié à l’infini les mécanismes biologiques pour marcher, tellement plus complexes, et n’a pourtant jamais réussi à inventer la roue dont la mise en œuvre nous semble si élémentaire. Comme quoi, la nature restera toujours merveilleusement mystérieuse.
Chercher à la copier pour apprendre à se mouvoir à un animal mécanique va nous imposer de décortiquer certains mouvements, à les fragmenter. De multiples expérimentations seront impératives, et pour l’heure je ne suis pas du tout certain d’arriver à un résultat crédible. Définir des positions, des orientations pourrait se faire sur des épures. Concrètement, l’approche expérimentale avec P08_Piloter_au_potentiometre.ino s’avère bien plus rentable, car nous sommes directement branchés sur le réel, compliqué par les faiblesses matérielles que le dessin ne prend pas en compte. Pour ne pas avoir à alterner entre deux démonstrateurs, P10_COMPLET_avec_potentiometre.ino est exactement une copie de P08 dans laquelle le programme « p07*« qui utilise le potentiomètre a été ajouté. C’est le dernier moteur désigné lors d’un « mN…*« qui sera animé.
La suite est ici.
