53) 11/01/2018 : Crash informatique à la NDRMSE (MJD 58129)

Arrivant à l’ouverture de la salle informatique, comme tous les matins depuis quelques semaines, il est manifeste pour moi qu’un incident d’actualité perturbe le personnel. Les ingénieurs logiciel sont tous regroupés à la machine à café, ce qui est rare, les bavardages vont bon train.
– Bonjour les gars, zavez-l’air bien excités ce matin, qu’arrive t’il dans la chaumière ?
– ZARIA a claché cette nuit. L’orage à fichu la foudre sur le complexe.
– Ouais, et directement sur le paratonnerre qui n’a pas suffit.
– Le serveur a un peu trinqué, heureusement qu’il est protégé par des éclateurs à gaz. Les électroneux ont réinitialisé, effectué le rechargement des sauvegardes, ZARIA refonctionne.
– Et alors, où est le prob ?
– Ben hier c’était l’anniversaire de Pierre, on a débauché à 18h, du coup on a oublié d’effectuer la sauvegarde. Normalement c’est automatique, mais pas de bol, ZARIA était en maintenance de niveau quatre, sa ligne de transfert sur le serveur de sauvegarde était provisoirement suspendue.
– Pas tragique, ceci dit la version H est perdue. Heureusement que J inclus toutes ses modifs.

L’histoire se répète.

Phénomène bien connu des historiens, ce n’est pas parce que l’on a décortiqué en détails les guerres passées que l’on peut empêcher des nouvelles. Ce n’est pas parce que l’on sait maintenant pourquoi de grandes civilisations brillantes ont disparues, que l’on décide de ménager la Terre sur laquelle repose notre futur. L’évolution logicielle de JEKERT est un peu à cette image. L’optimisation à outrance du code a conduit à modifier les textes logés en EEPROM. À partir de la version J il faut utiliser P35_Ecrire_les_textes_en_EEPROM.ino pour inscrire les bavardages d’OLED dans la mémoire non volatile du microcontrôleur. Conséquence : Cette version H n’est plus compatible et ses affichages écran sont erronés … tant pis, on oublie et on téléverse J.

Version définitive des textes logés en EEPROM.

Rassurez-vous, c’est l’ultime version qui ne sera plus remise en cause. Quand vous allez téléverser P35_Ecrire_les_textes_en_EEPROM.ino sur la carte NANO Arduino et valider l’affichage sur l’écran du contenu inscrit en EEPROM, vous constaterez que cette fois la totalité de cette ressource matérielle est consommée. Les 1024 octets sont occupés. Hors, le but consiste à décharger le programme des chaînes de caractères qui consomment de la mémoire dynamique. On peut alors affirmer sans grand risque de se tromper que :
• Il n’est plus possible de gagner un seul octet en EEPROM,
• Donc modifier son contenu ne présentera aucun intérêt, saut si l’on désire remplacer un texte par un autre et dans ce cas la substitution devra présenter une taille identique,
• Sauf petite modification locale consistant à remplacer le texte d’un Item, à partir de maintenant les nouvelles chaînes de caractères devront résider dans le programme … au détriment de la mémoire dynamique. IL FAUDRA IMPÉRATIVEMENT MINIMISER les nouveaux textes.
(La version ‘I’ des démonstrateurs n’a jamais été envisagée, le I pouvant être confondu avec le ‘1’.)
Téléversez P35_Ecrire_les_textes_en_EEPROM.ino sur l’ATmega328 et validez le Moniteur de l’IDE pour visualiser le contenu de son EEPROM. Le résultat ressemble à la copie d’écran montré sur la Fig.273 sur laquelle le premier octet de la dernière ligne est « repéré en rose ». Son adresse est 1008. On constate que le dernier caractère est bien en 1023, la mémoire EEPROM du processeur de la raquette est entièrement saturée. On voit aussi que l’on a passé en mémoire non volatile le mot OK de deux caractères ce qui semble un tantinet ridicule. Il faut bien se rendre compte que pour faire afficher un texte, on doit passer deux paramètres à la procédure de service Aff_TEXTE_EEPROM(1008,2). On s’attendrait à ce que la pénalisation en taille du programme rende déraisonnable cette approche informatique. Pourtant, quand on effectue des tests on constate que :
• L’instruction Aff_TEXTE_EEPROM(1008,2) consomme exactement 8 octets dans le programme,
• L’instruction display.print(« OK« ) en exige 10 dans le programme, et surtout diminue la zone de mémoire dynamique de deux emplacements plus le $00 de fin de chaîne.

La suite est ici.

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *