Un programme est toujours perfectible.
Maladie qui frappe grand nombre de programmeurs dans le loisir logiciel, le « toujours plus » sévit avec une âpreté militaire. Le matériel est définitivement figé, le logiciel téléversé pour la dernière fois. OUF, cette fois c’est fini, plus question de modifier quoi que ce soit. On ne va quand même pas se laisser dominer par ce petit lutin malicieux nommé programmation.
– NON MAIS ALORS !
Avec autorité on range tous les outils, on clique sur l’icone qui va endormir l’ordinateur et l’on peut enfin passer à autre chose. (Aller arroser les planplantes par exemple.)
x
– NON, NON et NON, plus de programmation !
x
Cette volonté d’acier n’a d’égal que l’épais blindage d’un blockhaus invulnérable.
x
– Et, Totoche, elle est si mignonne la petite grenouille du bocal météorologique.
– J’ai dit NON ! NON c’est NON haaaa mais alors !
x
Cette fois c’est bien terminé. C’est la fin de la route, il n’y a plus de rails face à nous. Et puis le temps passe, et le mur de l’Atlantique se désagrège lentement. Bientôt seuls quelques panneaux pour les touristes signaleront que juste en face, il y a bien longtemps, existait une forteresse inviolable. La programmation c’est un peu ça, sauf que l’inébranlable résolution s’effrite généralement plus rapidement que le béton. Et PAFFFffff, on craque et le P.C. reprend vie.
Préambule au « toujours plus ».
Difficile quand on a planché pendant des lustres sur un logiciel, et que l’on manipule avec satisfaction le nouveau joujou, de ne pas avoir inexorablement de nouvelles idées. Et les « dommage que », et autres « si j’y avais pensé avant » se bousculent. Il faut bien à un moment où à un autre décider que l’instant est venu de considérer notre objet comme totalement abouti. Le dernier programme complet qui intègre toutes les petites modifications d’amélioration frise les 1095 lignes de source. Sa taille présente une masse pondérale de 28122 OCTETS soit 91% de l’espace disponible. Il est grand temps de se calmer, surtout que la prudence incite à conserver un peu de place pour corriger des éventuelles erreurs. Il ne reste plus que 3 OCTETS de disponibles en EEPROM. Coté rentabilité on n’a pas fait dans la dentelle. Pour vous faciliter la vie, il ne vous sera pas nécessaire de reprendre le contenu de l’EEPROM sauf si vous voulez remplacer la Salamandre par la gentille petite grenouille. Tous les textes sont déjà en place. Voyons maintenant ce qui a été transmutationné.
Sauvegarder en EEPROM l’option alarme SONORE.
Commencer par cette broutille coule de source. Sans trop gamberger, on triture quelques lignes de code en plus et le tour est joué. On démontre ainsi, sans y passer des nuits blanches à broyer du noir, qu’il est facile d’améliorer l’existant. C’est un peu de l’hypocrisie, car pousser un Arduinaute à venir titiller les muses du logiciel, c’est un peu comme expliquer à un Écolo invétéré que ce n’est pas citoyen de balancer la fiole vide de filtre solaire en matière thermoplastique sur la magnifique plage de sable fin, d’algues en train de sécher et de plaques de pétrole brut solidifiées.
C’est le croquis P11_Complet_version_plus.ino qui va se prendre de plein fouet les petites modifications explicitées dans ce chapitre. Dudule va finir par gagner, il l’aura sa petite grenouille. Du coup, tous les programmes relatifs aux perfectionnements apportés à P10_NANO_METEO.ino sont logés dans le dossier qui répond au nom étrange de <Grenouille>.
Sauvegarder en EEPROM toutes les options.
Finalement, il a été décidé de sauvegarder systématiquement en EEPROM toutes les configurations résultant d’options diverses. Leur nombre va augmenter avec les petits perfectionnements, mais effectuer une écriture en EEPROM et une restitution sur RESET n’exige que peu de code. C’est le développement de chaque option qui consomme, car il faut un texte de présentation, éventuellement donner un rappel de la valeur actuelle. Quand le menu de l’option est en place et ses effets correctement émulés, deux échanges en EEPROM représentent un travail dérisoire. Par ailleurs, chaque option doit sauvegarder un booléen. Ce dernier ne consommera qu’un seul octet, pas de quoi dramatiser. Par exemple, actuellement on sauvegarde l’option des Lignes de pointillés et on la restitution sur RESET. Ainsi, si se produit une coupure secteur on retrouve l’intégralité du contexte sans avoir à reprogrammer l’appareil. Profitant de cette mutation, dans la version définitive du logiciel, si l’option des repères de niveaux est validée, on affiche les Lignes de pointillés dans les graphes des trois Modes écran. (Quand on aime, on aime partout …)
Sécurité météo à 45 jours.
Initialement, la séquence qui gère l’arrivée à 45 jours avait été copiée sur le programme source de PICOSYNTHÉ. On se contentait de générer des BIPs et un affichage qui incite l’utilisateur à faire un RESET pour réinitialiser le compteur interne au microcontrôleur. La fonction météo avec sentinelle change toutefois les conséquences potentielles. En effet, supposons que c’est l’hiver, il fait très froid et vous partez fêter Noël en famille pendant une semaine. Vous avez autre choses à penser qu’à la station météo qui discrètement et fidèlement gère le chauffage de votre petite serre. À peine parti de la maison : BIP BIP BIP BIP et plus personne pour s’en rendre compte. La température va baisser si l’interface est au repos et les plantes vont geler. Si l’interface de puissance est active, le radiateur va fonctionner en permanence jusqu’à votre retour. Bref, c’est la CATA !
Facile à parer ce problème : Il suffit dans la boucle infinie qui incite à faire un RESET de continuer à s’occuper de la sentinelle. La boucle infinie void Comptage_maximum() qui est activée quand on arrive au terme des possibilités du compteur électronique est la suivante :
En (1) on commence par indiquer que pour le moment aucun bouton poussoir n’a été activé.
Puis en (2) on utilise while (true), et comme la condition est toujours vraie, le microcontrôleur est définitivement prisonnier de cette boucle infinie comprise entre les deux délimiteurs { } et dont on ne peut sortir que sur un RESET. Les lignes (3) effacent l’écran puis présentent la page de la Fig.115 sur l’afficheur OLED. Pui, en (4) on génère un BIP et on allume les deux LED qui sont en vis à vis des deux boutons poussoir du clavier pour inciter l’opérateur à utiliser l’une des deux touches de fonction. Au bout d’une seconde en (5) on éteint les deux LEDs. Puis en (6) l’afficheur est forcé à « tout noir ». En (7) on mesure les trois paramètres, mais seule la Temperature sera prise en compte dans cette séquence de programme. La première ligne (8) commence par comparer la température mesurée à celle du seuil consignée dans T_MINI_autorisee. On doit enlever 100 car Mesurer_les_trois_parametres() ajoute cette constante pour coder sur un OCTET toujours positif. Si on est en dessous du seuil la sortie Sentinelle (LED Rouge.) est activée. Dans le cas contraire la consigne repasse au repos. Puis la deuxième ligne (8) s’achève par une temporisation de 3,5 secondes. Ainsi on a un BIP toutes les 4,5 secondes. L’écran est noir une majorité du temps avec un rapport cyclique de 22% toujours dans le but d’économiser ses luminophores. En (9) le programme « regarde si l’un des deux B.P. est activé. Si OUI, en (10), comme sur la Fig.94 il y a passage au sous-programme qui demande si l’on désire sauvegarder en EEPROM. La sortie du sous-programme fait reboucler en ligne (2) et si c’est la touche FC+ qui a été actionnée, les paramètres actuels sont inscrits en EEPROM.
Interroger sur l’écart qui nous sépare des 45 jours.
Considéré comme un paramètre important pour l’utilisateur, il faut pouvoir en consulter la valeur actuelle à tout moment quand on le désire. Ajouter une fonction qui affiche le nombre de jours écoulés depuis le dernier RESET ainsi que la durée restante jusqu’à la limite maximale de 45 jours n’est pas du tout compliqué. Nous sommes dans du traitement banal. La difficulté par contre réside dans les protocoles d’exploitation, car le nombre de boutons disponibles est vraiment limité. On désire de plus rester dans des manipulations qui ne s’écartent pas trop de la philosophie générale d’ouverture des menus d’options. 
Il semble logique de disposer de cette possibilité en mode VEILLE. De temps en temps, l’opérateur passe en revue les divers paramètres de « maintenance préventive » ou ceux relatifs à l’exploitation. Comme le mode VEILLE n’est pas logiquement celui où l’on va modifier la valeur de l’Intervalle ou celle du seuil de température sentinelle, FC+ long et FC- long peuvent être réaffectées. Consulter l’écart à 45 Jours est assez marginal et sans conséquences. C’est donc FC- long qui servira à ouvrir la fenêtre contextuelle de cette option. (FC+ long sert à l’option de sauvegarde automatique dont il est question dans le chapitre qui suit.) Le contenu de l’écran représenté sur la photographie de la Fig.116 se passe aisément de tout commentaire. Le retour à l’écran tout noir se fait librement avec FC+ ou FC- long ou court.
Option de Sauvegarde Automatique des échantillons.
Comme tout automatisme, l’imposer irait forcément à l’encontre de la convivialité. Imaginons que se trouve en EEPROM un historique particulier que vous désirez conserver un certain temps. Par exemple le dernier PROFIL de promenade que vous voulez montrer à des amis, (Voir plus avant de quoi il retourne.) ou une variation de pression barométrique assez peu courante dans vos anales locales. Dans ce cas, il faut pouvoir inhiber la fonction de sauvegarde automatique. À contrario, si votre préférence va sur l’utilisation permanente de NANOMÉTÉO en mode VEILLE, l’historique sur la période écoulée revêt à vos yeux de l’importance, surtout si vous avez configuré l’appareil pour une longue durée d’échantillonnage. Si une coupure secteur se produit, vous risquez de perdre plusieurs jours ou semaines d’enregistrements. La sauvegarde automatique est alors la parade à sélectionner. Si cette option est validée, une sauvegarde dans l’EEPROM des 120 échantillons pour les trois variables est déclenchée toutes les heures.
x
– Quoi, mais téfou Totoche, à ce régime tu vas griller l’EEPROM !
– T’a raison Dudule, en principe on ne peut y réinscrire des données que 100000 fois.
– Du coup il va faloir changer la carte NANO vachement souvent.
– Ben oui Dudule, une fois tous les 11 ans et cinq mois environ.
– Elle va nous coûter un bras ta NANOgrenouille !
– Ben oui Dudule, à environ quatre euros par carte NANO on en aura pour 36 centimes par an.
x
x (100000 / 24 / 365 = 11,41 ans … faut faire des économies !)
Comme précisé dans le chapitre précédent, c’est FC+ long qui servira à ouvrir la fenêtre contextuelle de cette option quand on se trouve en mode VEILLE. L’affichage indique alors l’état ACTUEL de la consigne qui se trouve en mémoire. Bien comprendre qu’en fonction du bouton poussoir actionné pour sortir, le paramètre sera réinscrit en RAM et en EEPROM. Donc bien faire attension au moment de quitter en cliquant sur la bonne touche du petit clavier.
Traces points ou histogrammes type « surface ».
Pour la modique somme de 170 octets de programme et de deux emplacements en mémoire dynamique, nous allons bénéficier d’une petite gâterie supplémentaire, à savoir deux présentations possibles pour les graphes historiques. En réalité, c’est pour le tracé du PROFIL de promenade en fonction 
altimètre que cette idée a émergé des profondeurs barométriques. Comme c’est un petit plus esthétique, autant le généraliser à tous les écrans graphiques. Naturellement, l’opérateur aura le choix entre chaque type de représentation, la variable consignée étant sauvegardée en EEPROM et restituée sur un RESET.
Trêve de publicité, l’option est vendue. Pour comprendre la différence entre les deux modes de représentation, considérons la Fig.118 qu’il faut comparer aux Fig.104 et Fig.106 car il s’agit des mêmes historiques, sauf qu’ici on est en représentation « surface ». Au lieu de tracer le point figuratif en hauteur, on relie verticalement tous les luminophores entre l’ordonnée zéro et la valeur au point considéré. Il importe dans ce mode de représentation de bien situer la référence zéro. Par exemple sur la Fig.118 A le zéro se trouve tout en bas au bord inférieur du cadre. Les barres verticales partent donc du bas jusqu’au pixel figuratif de la valeur de l’échantillon. Par contre, en B nous savons que le zéro pour les températures se trouve à la deuxième graduation en hauteur. Les lignes de « remplissage partent donc de cette horizontale. Si les températures deviennent négatives, les traits seront tracés entre la référence zéro et en dessous pour l’amplitude de la température.
Quand en mode VEILLE on sollicite FC- court il y a affichage temporaire des données du moment. Si vous sortez de cette page d’informations avec FC+ court ou long comme suggéré par la LED verte qui clignote rapidement, il y a retour banal à l’écran noir. Par contre, si vous quittez l’affichage graphique avec FC- court ou long il y a ouverture d’une page contextuelle pour définir cette option, avec affichage du texte Graphes pleins ?. Vous avez compris que répondre avec FC+ validera l’option, alors que FC- imposera la représentation « filaire ». Si l’option des lignes pointillées horizontales pour définir les quatre niveaux intermédiaires est active, elle reste valide. Toutefois, les barres verticales du graphe de « surface » les masquent si elles traversent ces niveaux.
NOTE : Un autre petit perfectionnement est ajouté en mode VEILLE. Maintenant, chaque appui sur FC- en ouvrant la fenêtre graphique temporaire fait changer la nature de la donnée qui est visualisée. Ainsi on peut en trois ouvertures et fermetures successives visualiser les trois histogrammes. Ce n’est qu’une amélioration mineure, mais elle montre à quel point on peut à l’usage d’un appareil quelconque lui trouver de multiples personnalisations.
Enregistreur du PROFIL d’une promenade.
Cerise sur le gâteau, c’est l’option qui fait vendre. C’est aussi indispensable que les super rétroviseurs obus profilés pour des vitesses supersoniques sur une automobile. Totalement inutiles, c’est le genre de détail qui peut faire craquer et entrer chez le concessionnaire. La fonction PROFIL appartient à ce genre d’extravagances, et sera d’autant plus déraisonnable qu’elle va se gloutonner pratiquement 1500 octets pour le code qui l’émule. (Menus et affichages compris !) Au diable l’avarice, dans le loisir on fait souvent des folies, la vie est belle, les oiseaux font cuicui et nous on va se cogner des montées et des descentes uniquement pour engranger du profil. Bref, un petit délire et ce d’autant plus irrationnel que l’on va « mettre le paquet » pour que ce soit beau !
L‘idée concerne l’altimètre pour promeneur, elle consiste à enregistrer les hauteurs durant la ballade à des intervalles réguliers. Ainsi, à la demande, on peut faire afficher l’évolution des dénivelés en fonction du temps. On obtient de la sorte le PROFIL des montées et des descentes parcourues par le marcheur au cours de sa sortie. C’est du reste ce type de représentation qui a fait émerger l’idée des deux modes de représentation : Le filaire et le graphe de type « surface ».
Définir la durée entre deux échantillonnages.
Avant de présenter les écrans d’affichage du PROFIL de la promenade, il me semble utile d’aborder la procédure opérationnelle qui permet de définir la durée entre la saisie de deux échantillons. Attention, ce n’est pas la valeur de l’altitude qui est mémorisée, mais le dénivelé. C’est à dire la différe
nce d’altitude entre la référence de départ et celle du moment. Par rapport à la référence zéro au moment du départ, on peut indifféremment monter ou descendre. Nous aurons ainsi, aussi bien des hauteurs positives que négatives. La représentation du profil devra bien visualiser cette référence zéro correspondant au début de la sortie pédestre.
Étant en fonction ALTIMÈTRE, nous savons que FC+ long fait revenir au fonctionnement en centrale météorologique. Pour son compte, maintenant FC- long ouvre le menu Fig.119 A qui permet de saisir la durée qui devra s’écouler entre deux enregistrements de hauteur. Il serait possible comme pour la centrale météorologique de consigner directement ce délai. Ce n’est toutefois pas idéal, car ce que désire au final l’utilisateur, c’est d’obtenir un graphe qui pour la largeur de l’écran couvrira avec les 120 échantillons l’intégralité du parcours. Généralement, le promeneur a une idée assez précise de la durée de sa sortie. C’est donc cette dernière qui sera consignée en heures et minutes. Pour alléger le protocole de saisie, les secondes ne sont pas demandées. Quand on valide la valeur des minutes, on obtient l’écran B qui n’est pas sans rappeler celui de la Fig.99 car on se doute que c’est une procédure commune qui est invoquée pour saisir des durées. Les secondes sont forcées à zéro par le logiciel. Notez que la plus grande durée possible pour la sortie pédestre sera de 8H 59 Min … ce qui est déjà pas mal. Dans le cadre jaune est affichée la durée calculée de l’intervalle. La valeur maximale arrondie au dixième de minute sera de : ((8 x 60) + 59 ) / 120 = 4,49 arrondi à 4,5. Donc la valeur dans le texte jaune sera toujours indiquée avec trois caractères dont un point décimal entre les deux chiffres significatifs.
ATTENTION : Quand on consigne l’altitude de départ (Ref zéro) en cliquant sur FC- court, il y a remise à zéro du graphe, donc effacement du PROFIL. C’est la raison pour laquelle, maintenant le programme demande confirmation en affichant le message 
.
Soulignons au passage une autre petite sucrerie informatique. Au prix injustifié d’un gaspillage d’OCTETs, divers textes ont maintenant des accentués comme montré sur l’exemple de la Fig.120 dans l’encadré rouge.
Sauvegarde en EEPROM et restitution du PROFIL.
Compte tenu de la relative faible dépense en octets qu’exigent ces deux fonctions, il aurait été bien dommage de ne pas pouvoir immortaliser notre fabuleuse sortie au Mont Blanc pour rendre jaloux les copains. L’inverseur à bascule est disponible, il est choisi pour pouvoir faire appel à ces deux fonctions. Dans l’affichage courant des données d’altitude ou en mode veille l’inverseur génère un BIP d’erreur. C’est uniquement en mode Affichage du PROFIL que basculé à gauche on ouvre le menu pour l’option de rechargement avec possibilité d’accepter ou de refuser. Basculé à droite, si on valide en sortant, le PROFIL actuel sera « sculpté » en EEPROM.
Supposons que la promenade corresponde à environ trois heures de marche. Il est prévu un petit repas d’environ une heure, voir plus. Enregistrer durant tout ce temps « d’immobilité » engendrera un palier horizontal sur le graphe pas très porteur d’informations. Ce n’est pas génial. Une fonction qui figerait les enregistrements à la demande a été testée, mais elle conduisait à une débauche d’OCTETs avec un rapport qualité prix trop défavorable. L’idée a donc été abandonnée.
Présentation graphique du PROFIL.
Activé avec le codeur rotatif, le graphe présente plusieurs échelles en hauteur. L’apparence sera directement fonction de l’option de tracé type points ou « graphes pleins » mémorisée dans la fonction station météo, cette variable étant sauvegardée en EEPROM et rétablie sur un RESET. Considérons la Fig.121 relative à un PROFIL qui est en cours d’enregistrement. La promenade a commencé à -20m en X. Actuellement on « marche » en Y et la hauteur relative actuelle est d’environ 70m. Sur les trois graphes l’échelle sature vers le haut. Toute la zone Z à gauche de X vaut zéro puisque les enregistrements ont été effacés lors de la saisie de Ref zéro. Quel que soit le mode de représentation, surface en A ou filaire en B, la Reférence zéro est repérée en R par une ligne horizontale pointillée située à deux niveaux en hauteur sur le graphe. La sortie de la représentation type PROFIL se fait librement avec FC+ ou FC- long ou court. Durant ce mode d’utilisation de l’altimètre, quand on tourne le codeur rotatif, on change la plage « verticale » des valeurs de dénivelé. La différence de hauteur entre deux graduations de niveaux est indiquée en bas à droite. (Sur la Fig.121 dans l’encadré vert.) On peut ainsi librement changer l’amplification de représentation, mais la ligne de référence est immuable dans le cadre, il y aura en permanence un rapport 2/5 et 3/5 respectivement pour les descentes et les montées avec effet de saturation sur les deux bords bas et haut de la zone bleue. En A et B on tronque la représentation à +30m. En C avec une déviation de 5m par graduation, la coupure hors cadre se produit à +15m. (Correspondances par les traits violets ajoutés aux photographies.)
Actuellement, j’ai
estimé que cinq coefficients d’amplification sont bien suffisants, à savoir : 5, 10, 50, 100 et 500 mètres par graduation. L’usage peut nous donner l’envie d’en ajouter d’autres. Par exemple une grande sensibilité de 2m par graduation, un intermédiaire de 20m/Grd ou pourquoi pas un 1000m/Grd ? Il sera facile dans les instructions switch (Parametre) de la procédure void Affiche_le_denivele() d’ajouter autant de coefficients que l’on veut … mais attention à la boulimie en octets ! Comme on peut le constater sur les Fig.122 à Fig.126, plus l’amplitude verticale est importante, plus le diagramme manquera de relief. Toutes ces photographies correspondent à la même balade représentée à des amplifications différentes. Par exemple les deux affichages Fig.122 et Fig.123 sont analogues, le premier est de type diagramme surface, le deuxième est en représentation filaire. Sur les Fig.124 et Fig.125 la pente « se tasse » car on passe à 100m par graduation.
Subtilité de présentation qui participe « aux gaspillages d’octets, le texte qui indique l’échelle des niveaux en bas et à droite de l’écran est de longueur variable pour empiéter le moins possible sur le graphe car il masque ce dernier. C’est du luxe j’en conviens. Enfin, sur la Fig.126 le diagramme est tout raplapla car la hauteur totale va de -1000m à +1500m.
TRICHERIE inavouable : Non les amis, je n’ai pas effectué cette marche. Du reste on pourrait se demander comment on est passé de zéro relatif à -20m en un intervalle de temps nul. Une montée permanente aussi régulière n’est pas réaliste, car d’une part il est peu courant d’avoir une pente aussi linéaire, d’autres part un marcheur qui cadence à ce point son rythme est un « pro » de l’escalade. Ce graphe résulte d’une génération automatique lors des tests. Pour avoir des courbes plus variées, je vous invite fortement à aller au grand air profiter du soleil et d’emporter avec vous le beau joujou tout neuf …
Cette dénonciation anonyme sur ma sombre fourberie m’incite en outre à une transition facile :
Trucs et astuces de programmation.
Gouffre à temps insondable, la programmation peut arriver à des temps de développement irréalistes si l’on ne contourne pas certains délais temporels particulièrement consommateurs. Ce chapitre va dévoiler certaines petites astuces simples pour gagner un temps considérable. Elles ne sont pas spécifiques à cette application et peuvent se généraliser à tout projet. Vous avez un premier exemple dans le chapitre précédent pour lequel, la construction artificielle d’un profil a été générée dans une boucle qui calculait les nouvelles hauteurs par incrémentation.
Imaginez que pour tester la boucle infinie qui s’anime à 45 jours après le RESET il m’a fallu environ une cinquantaine d’essais. Si chaque fois on avait attendu 45 jours il aurait fallu six ans rien que pour cette séquence. Pour la mettre au point il suffit de l’invoquer inconditionnellement en tête de la boucle de base. Quand la séquence est bien au point, on enlève cette instruction surabondante et provisoire. Puis, pour vérifier le déclenchement, on transforme
if (millis() > 3900000000) Comptage_maximum(); // Message d’alerte à 45,14 jours.
en if (millis() > 5000) Comptage_maximum();
qui va déclencher le processus cinq secondes après le RESET.
D’une façon générale, il faut en cours de développement « sauter » toutes les séquences qui impliquent de nombreuses manipulations et aller directement aux procédures en cours d’élaboration.
Par exemple dans void setup() on ajoute les deux instructions « roses » :
Arrivé en (1) le programme a affiché la version et le LOGO. Normalement en (3) il attend de notre part un clic sur le clavier pour passer à la suite. Pour ne pas avoir chaque fois à effectuer cette manipulation, les lignes (2) et (4) font oublier cette instruction en passant directement en (5).
Certains programmeurs, dont je fais partie, s’interdisent le goto dans les programmes car ils rendent les logiciels confus et délicat à interpréter. Toutefois, utilisés très provisoirement comme ici, cette instruction bannie reste logique et bienvenue. Autre astuce importante : Le nombre de lignes de code qui sont ainsi disséminées un peu partout dans le listage source peut devenir important. Quand tout est au point, il faut les effacer. Pour que cette opération de purge soit aisée et rapide :
• Chaque ligne de mise au point ne contient QUE du code surabondant pour pouvoir l’effacer entièrement sans avoir à se préoccuper de son contenu.
x (Ainsi il n’y a pas de risque de perte d’instructions utiles.)
• Chaque ligne de mise au point se termine par une remarque //xxxxxxxxxx. Quand on veut éliminer toutes ces instructions parasites sans en oublier, il
x suffit de confier ce texte au mode recherche.
Dans un ordre d’idée tout à fait semblable, le développement des affichages graphiques constitue une tâche longue et fastidieuse. Il faut tester les résultats aussi bien en utilisation Altimètre qu’en fonction station météorologique. Pour ne pas avoir à titiller chaque fois l’inverseur à bascule et d’avoir à confirmer, il suffit de commencer void loop() par une instruction du genre :
x Procedure_ALTITUDE(); //xxxxxxxxxx.
Autre boulimie temporelle : Obtenir un historique pour travailler les présentations d’écran. C’est long et fastidieux. Il faut imposer un délai entre échantillons d’une seconde. Puis attendre à chaque fois 120 échantillons soit deux minutes à ronger son frein et prendre des boutons sur le visage. INFERNAL ! Pour nous épargner cette corvée, dans la procédure d’initialisations void setup() se trouve une séquence de cinq lignes de code surabondant. Elles sont bien délimitées au début en (1) et à la fin en (6) par deux remarques de mise en évidence globale. Quand les séquences sont au point il vaut mieux transformer ces lignes de source en remarques, ainsi par la suite si l’on veut reprendre le logiciel elles seront disponibles. Notez la remarque //xxxxxxxxxx pour respecter la discipline détaillée ci-avant.
La ligne (2) va créer rapidement 120 échantillons sur les trois variables. Pour avoir des valeurs quelconques, on se contente de « pomper » 120 valeurs dans la zone EEPROM du LOGO. En (3) on recopie celles du début, en (4) on lit cinquante emplacements plus loin, et en (5) on décale de cent emplacements par rapport au début de l’EEPROM. Par cet artifice nous obtenons trois historiques distincts, ce qui permet d’observer des différences quand on change de variable visualisée. Comme ces valeurs ne sont plus filtrées comme le sont celles issues des mesures météorologiques, nous avons des débordements vers le haut y compris dans le cadre jaune. C’est sans inconvénient pour tester les lignes pointillées, les types de graphes « surfaces » ou « lignes » etc.
Évidemment, il ne s’agit que de quelques exemples pour illustrer le propos, et vous en trouverez bien d’autres. Globalement, l’approche consiste à « sauter » toutes les séquences laborieuses qui demandent de nombreuses interventions du programmeur, et d’éluder par « simulation » toutes celles qui consomment par nature beaucoup de temps. Dernière suggestion lors des mises au point : Tester la place disponible entre la PILE et le TAS, surtout si le logiciel développé implique la création de tableaux. C’est la raison pour laquelle, dans tous mes « gros croquis », se trouvent les deux blocs dans void setup() délimités par des //@@@@@@@@. Vous pouvez être certains qu’avant de considérer un programme comme bon pour le service, je valide les lignes de ces deux séquences et en étudie avec attention le résultat. Pour NANOMÉTÉO le verdict annonce 183 octets de disponibles ce qui normalement est suffisant. Du reste notre croquis fonctionne correctement.
