Le programme complet qui fait vivre notre petite réalisation.
Totalisant ce jour 950 lignes comportant généralement plusieurs instructions, le décortiquer intégralement serait stupide. La grande majorité relève d’une programmation banale sans grande originalité. Le listage est amplement saupoudré de commentaires, il se lit presque comme un journal. Les noms utilisés pour les identificateurs sont minutieusement sélectionnée pour contribuer à la lisibilité du total. La capacité d’accueil de l’ATmega est largement consommée puisque le logiciel occupe 82% de l’espace disponible. Avouons qu’une optimisation à outrance n’a pas été jusqu’ici une préoccupation majeure car estimée non indispensable. C’est en réalité la place disponible pour les variables dynamiques qui impose une optimisation poussée pour l’organisation des données.
Organisation des données dynamiques.
Étudié en profondeur dans le didacticiel relatif à la réalisation des appareils de mesures, nous savons qu’une boulimie exagérée en consommation d’espace de mémoire dynamique peut engendrer rapidement une collision entre la PILE et le TAS. Je vous invite fortement à revoir le sujet si vous désirez cerner avec précision les informations qui suivent.
Pour ceux qui se contenteront d’un survol rapide de ce chapitre, contentez-vous de savoir que deux consommateurs de mémoire dynamique sont susceptibles de se goinfrer :
• Les « textes » que l’on insère dans le programme pour les affichages écran.
• Les variables TABLEAUX qui peuvent rapidement se gaver à leur tour.
Le premier remède quand on risque de manquer d’espace entre la PILE et le TAS consiste à placer tous les textes en EEPROM. Tout au moins ceux qui ne changent pas. C’est en général le cas pour la quasi totalité des affichages. C’est exactement la stratégie adoptée dans P10_NANO_METEO.ino.
L’autre « angle d’attaque » consiste à réduire autant que possible la taille des données dynamiques, et en particulier les tableaux. Si ce sont des tableaux de constantes, comme le LOGO par exemple, il faut les loger en EEPROM, comme pour les textes. Si ce sont des tableaux de variables, il faut en minimiser la taille. En particulier les valeurs échantillonnées sont préservées dans trois tableaux.
Traitement des échantillons et de leur mémorisation.
Conceptuellement nous avons trois variables à mémoriser dans un historique. Compte tenu de la définition de l’écran graphique et des dimensions adoptées pour les dessins, nous avons opté pour 120 échantillons par variable. Nous disposons de 2048 octets pour la mémoire dynamique. Les variables globales en consomment déjà 822. Il ne faut pas oublier que le pointeur de PILE va venir consommer copieusement, car il doit loger les adresses de retour lors des appels à procédure, les points de retour quand se produisent des interruptions, ranger les variables passées par valeur etc. Bref, tout ce petit monde vient manifester sa fringale en octets. De rapides estimations ont montré qu’il fallait absolument se montrer prudent pour la taille des espaces affectées à l’historique des données. Décision initiale : Sauvegarder la pression, l’humidité relative et la température sur UN OCTET PAR ÉCHANTILLON. Ce choix initial n’est pas sans conséquence et impose une façon d’enregistrer les valeurs assez particulière. Examinons point par point la structure des données :
Enregistrement de l’humidité relative. On commence par l’hygrométrie car sa sauvegarde et sa récupération sont élémentaires. Les valeurs d’humidité relative qui correspondent à un pourcentage ne peuvent s’échelonner au maximum qu’entre 0 et 100. Pas de signe, la variation est largement dans la fourchette disponible sur un OCTET qui va de 0 à 254. La valeur mesurée sera directement stockée dans le tableau MEMOIRE_HYGROMETRIE[120] à l’emplacement « courant ».
Enregistrement de la température. Bien que les valeurs ne s’étalent pas sur des centaines de degrés, deux difficultés viennent compliquer un peu leur stockage. La première résulte du fait que le capteur fournit ses valeurs au dixième de degré près. Avec une fourchette de possibilit
é sur un OCTET il est impossible de mémoriser avec cette finesse, la donnée devrait passer à un entier et occuper de ce fait une place deux fois plus importante. Par ailleurs l’affichage en numérique dans la zone jaune prendrait deux caractères de plus, les données y seraient exagérément tassées. Comme le dixième de degré ne changera pas grand chose au ressenti et surtout pour le gel éventuel des plantes dans un local hivernal, décision a été prise de n’afficher qu’en degré, mais à l’arrondi au plus approchant. La deuxième difficulté qui pose problème, c’est que l’on désire mesurer des températures négatives jusqu’à -10°C, alors que sur un OCTET on ne peut coder que du positif. En outre, on désire que l’affichage graphique soit facile à interpréter avec cinq niveaux verticaux. D’où la limitation entre -10°C et +40°C. Pour satisfaire ces exigences, les températures seront mémorisées en les majorant de +100. Ainsi quelle que voit la température mesurée, on restera dans des valeurs positives qui sont acceptables sur un OCTET. Notez au passage que seul le graphe va talonner entre -10°C et +40°C, mais les valeurs numériques peuvent potentiellement aller de -100°C à +154°C donc ne seront pas affectées numériquement. L’affichage de la température en revanche sera faussé si on dépasse les 99°C car il est prévu sur deux chiffres significatifs. Ceci dit à moins d’une nouvelle glaciation ou de faire tomber les capteurs dans l’eau bouillante prévue pour le thé, ce risque est exclu.
La séquence qui se charge d’effectuer une mesure et de sa préparation pour le stockage sur un OCTET est listée ci-dessus. On constate en ligne (1) que c’est le capteur de pression qui sera également sollicité pour mesurer la température. La directive char en début d’instruction impose au compilateur d’effectuer des calculs en retournant le résultat sur un OCTET. À la valeur mesurée, cette instruction ajoute la constante 100. Mais ce calcul fait perdre les décimales, car char impose en travail sur huit BITs. La ligne (2) est un commentaire relatif aux deux lignes qui suivent. La ligne (3) a pour objet d’extraire la valeur de la décimale avec deux fois abs qui dans les calculs « élimine le signe ». Enfin, si le chiffre des décimales dépasse cinq, en (4) on incrémente la grandeur affichée ou on la décrémente en fonction du signe de la température. On dispose ainsi d’une valeur arrondie avec un OFFSET de valeur arbitraire 100.
Enregistrement de la pression. La valeur la plus faible jamais enregistrée à l’échelle mondiale avoisine 868hPa qui dépasse de beaucoup la possibilité de codage sur un OCTET si l’on désire afficher la valeur à 1hPa près. Suite à une analyse poussée et à différentes stratégies évaluées lors du développement, il a été décidé de se contenter de sauvegarder la valeur de la pression en relatif par rapport à une référence zéro de 940hPa. L’instruction qui traite la valeur barométrique est élémentaire :
x Pression = (Capteur_BMP085.readPressure() / 100) – 850;
L’appel à la fonction Capteur_BMP085.readPressure() retourne la valeur de la pression en centième d’hectopascals. La division par 100 fournit la valeur entière. On retranche ensuite la constante 850, la transposition 0 à 255 correspondant alors à la fourchette 850hPa à 1104hPa. Cette fourchette de valeurs couvre et dépasse les grandeurs des records jamais enregistrés, donc en affichage numérique NANOMÉTÉO n’a aucune restriction. C’est la présentation graphique qui modère un peu la performance par effet de saturation en haut et en bas du dessin de la courbe de variations.
Il est évident que pour afficher les valeurs numériques à l’écran, les données mémorisées subissent des transformations réciproques, c’est à dire enlever 100 ou ajouter 850 … pas de quoi s’affoler.
Traitement de l’affichage graphique.
Résultant de compromis pas aisés à formuler, les solutions adoptées résultent de plusieurs essais qui avaient pour but d’aboutir à des graphes pas trop plats, éviter des changements d’échelles pour simplifier le logiciel en le cantonnant dans une taille de code raisonnable. Enfin il a été décidé de n’avoir à droite qu’une division en cinq niveaux pour les trois paramètres, en vue de simplifier l’interprétation des graphes par l’utilisateur. C’est ce critère qui limite la plage de variations graphique des températures entre -10°C et +40°C dans la visualisation du cadre bleu. Pour ceux qui habitent des régions très froides, il serait possible de décaler « vers le bas » l’échelle des températures, et les contraindre dans la fourchette allant de -20°C à +30°C. Bref, il vous sera possible à votre guise d’adapter les limites à souhait. Quand les divers choix pour les limites imposées dans la fenêtre graphique ont été adoptés, il restait à transposer les coordonnées verticalement pour tenir compte des caractéristiques de l’écran OLED. Verticalement la dalle de luminophores du cadre bleu réservé au dessin fait quarante cinq PIXELs de haut. De plus, la fonction qui permet de tracer un point présente un axe vertical dirigé du haut vers le bas. Les ordonnées du cadre (Ordonnées : positions en hauteur.) vont de 18 à 63. En fonction de la valeur du paramètre dont on construit la courbe représentative de son historique, il faut transposer entre ces deux limites.
Avec toutes ces valeurs qui s’entrecroisent joyeusement, il devient un peu délicat de s’y retrouver et de comprendre clairement tous les choix effectués. Le mieux encore est de consulter la synthèse proposée en Fig.114 qui résume l’intégralité des éléments relatifs au traitement des pressions. En violet nous avons les valeurs entières que retournera le capteur de pression BMP085, les décimales étant éliminée après réception du dialogue série. En réalité le composant peut numériser entre 300hPa et 1100hPa, mais nous ne descendrons jamais aussi bas. (Sauf si on monte très très très haut en altitude … Wouafff le jeu de mots !)
L’échelle verte donne les valeurs transposées par – 850 pour aboutir au codage sur un OCTET. On observe que la plage de mesure effective déborde largement des records mondiaux jamais enregistrés.
Tracer les variations à pleine échelle aboutirait sur l’écran OLED à des graphes presque sans relief, car dans nos régions les variations restent bien plus faibles. On a donc dans le traitement imposé un effet de dilatation verticale basé sur une valeur moyenne 990hPa. En étalant la plage 940hPa à 1040hPa sur toute la hauteur du rectangle réservé aux historiques, les courbes représentatives de variations présenteront deux fois plus d’amplitude. On retrouve après ce traitement les valeurs coloriées en bleu qui sur la Fig.98 sont rappelées dans la colonne 1. Enfin, en rose sur le dessin, on repère l’ordonnée du haut du cadre en 18 et celle du bas en 63. Pour construire un histogramme, partant de la gauche vers la droite on va tracer sur une verticale le point représentatif correspondant à l’ordre de l’échantillon, et balayer avec un pointeur PTR les 120 valeurs de la gauche vers la droite. C’est la procédure void Trace_un_triplet_de_mesures() qui se charge pour chaque position horizontale de tracer le point figuratif correspondant à la variable représentée. Voici le début de cette procédure qui commence par traiter la pression :
Nous allons voir que finalement, si les choix opérationnels ont exigé de nombreuses tentatives, le traitement final reste très simple. En (1) la variable OCTET reçoit la valeur de l’échantillon correspondant à la position latérale de PTR . Puis, si la valeur déborde par le « bas » de la fenêtre du ZOOM, en (2) on rabote la valeur inférieure à 90. Une valeur de 90 pour l’octet mémorisé représente 940 pour le bas de l’écran graphique. Si le débordement se fait par le haut, en (3) toute valeur supérieure à 190 sera réduite à cette limite. Cette valeur mémorisée de 190 correspond aux 1040 du ZOOM vertical. Puis l’instruction map en (4) effectue une transposition qui inverse le sens d’évolution et en change la plage de variation. Cette instruction est assez magique et nous évite plusieurs lignes qui réaliseraient cette proportionnalité inversée. Le test en (5) permet de décider si ce paramètre doit être visualisé ou non. L’expression (Parametre == 0 && Mode_Ecran == 0) sera vraie si on est en mode HISTORIQUE et que c’est le paramètre pression qui est sélectionné. Pour son compte l’expression (Courbe == 0 && Mode_Ecran == 1) en mode EXPLOITATION alterne les affichages avec la variable Courbe. Enfin si l’un des deux tests donne true, en (6) on trace le point représentatif.
