ENREGISTREUR graphique.

Enregistreur deux voies 40 secondes à 45 jours.

Euphorisante est la perspective de disposer d’un enregistreur qui va consommer un maximum d’octets de programme pour combler le vide scandaleux laissé par toutes les fonctions déjà implantées. À l’instar du TRACEUR GRAPHIQUE X/Y, cette application n’a strictement rien à voir avec la mission d’un générateur de signaux électroniques. Elle profite des possibilités de l’afficheur OLED pour compléter les applications déjà proposées sur PICOLAB. Pouvoir enregistrer
sur de courtes ou de longues périodes deux paramètres reste fort séduisant. Par exemple l’évolution de la température et de la luminosité au cours d’une journée, mesurer l’hygrométrie et la pression atmosphérique durant une semaine, les applications sont légion. Avant de commencer à détailler les subtilités de cette nouvelle fonction qui va allonger la liste du MENU de base, il faut ouvrir une parenthèse relative aux trois dernières fonctions, car elles ont pour particularité, comme montré sur la Fig.96, de commencer par se présenter dans le cadre jaune durant une seconde, puis l’écran d’accueil est affiché même si on ne désire pas l’utiliser. Ce délai d’une seconde est estimé suffisant pour avoir le temps de lire le titre, sans trop pénaliser pour autant la rapidité de déplacement dans le MENU. Pour passer à l’item suivant du MENU ou à son précédent, il faut cliquer de façon classique sur l’une des touches FC+ long ou FC- long.

L’agencement matériel.

Totalement gratuit, l’enregistreur graphique n’impose strictement aucun composant supplémentaire car il va utiliser intégralement l’électronique du traceur X/Y. Pour simplifier son utilisation, au lieu d’être nommées X et Y les deux entrées indépendantes seront nommées Entrée A et Entrée B. La Fig.97 résume les liaisons électriques à effectuer. C’est la fonction ENREGISTREUR qui est disponible sans bourse déliée, mais encore faut-il lui soumettre des signaux issus de

capteur analogiques. Le logiciel n’effectue aucun traitement particulier en aval du convertisseur analogique numérique. Les tensions d’entrée comprises entre 0 et +5V sont traduites en binaire et mémorisées dans des bytes variant de 0 et 255. C’est à l’opérateur de concevoir et de brancher un capteur travaillant dans cette plage de tensions et convertir mentalement la valeur numérique qui sera affichée dans les unités qu’il désire privilégier. Notez que si l’un des capteurs ne génère que des tensions trop faibles ou présentant des niveaux négatifs incompatibles avec le C.A.N. de l’ATmega328, vous avez la possibilité d’utiliser l’amplificateur sommateur disponible dans PICOSYNTHÉ. Comme précisé sur la Fig.97, durant cette fonction le générateur H.F. est mis en veille pour ne pas rayonner inutilement des ondes parasites dans tout le laboratoire, et aussi diminuer la consommation de l’appareil. C’est « du gagne petit », mais dans une campagne de mesure sur le long terme, on peut laisser PICOSYNTHÉ longtemps en fonctionnement permanent.

Les différents modes de visualisation.

Qualité opérationnelles et convivialité d’utilisation vont de paire avec un agencement d’écran « bien pensé ». Il faut concilier l’oxymore résultant d’un maximum d’informations pertinentes visibles avec la plus grande clarté d’interprétation possible. Sous une autre forme, afficher une multitude de données tout en évitant la surcharge. La forme la plus dépouillée ressemble à celle de la Fig.98 qui en entrée de fonction, par défaut, initialise les deux voies avec des valeurs « linéaires », ce qui permet de pouvoir tester l’appareil en disposant d’emblée de deux voies de 120 échantillons. Tout à droite, six petites graduations discrètes situent les niveaux de 0 à +5V. Comme sur le WOBULATEUR le capteur rotatif permet de déplacer latéralement un curseur sur quarante positions. Dans le rectangle jaune sont alors affichées en numérique les valeurs correspondantes sur les deux voies A et B. Le bouton poussoir  FC- court est prévu pour effacer toutes les données. Il faut confirmer avec FC+ court pour ne pas risquer de perdre des heures ou des jours d’enregistrement par erreur de manipulation. Si on valide, l’écran s’efface et le « pointeur » revient à gauche. Les enregistrements seront alors effectués,

s’enchainant à une cadence qui sera imposée par un délai consigné manuellement à votre guise. On verra les points s’inscrire sur l’écran, comme montré sur la Fig.99 X de la gauche vers la droite. Quand la mémoire sera pleine, chaque nouvelle masure provoquera le décalage vers la gauche (Voir la Fig.99 Y) de la totalité des enregistrements et continuera à placer à la fin les deux dernières données. On conserve ainsi en permanence la mémoire des 119 derniers échantillonnages, le total pouvant représenter entre trente six secondes environ et plus de quarante cinq jours. En appuyant sur le bouton central du capteur rotatif, on passe de la Fig 98 à la visualisation de la Fig.100 sur laquelle on surcharge avec les quatre lignes pointillées. Un clic de plus sur ce bouton et sont alors affichés la valeur du délai entre deux échantillonnages, (Voir la Fig.101) et dans le rectangle jaune la durée totale qui en résulte

exprimée en nombre de jours présenté avec une décimale. Comme cette page d’informations suspend la mesure sur les entrées, le logiciel prévient en bas de l’écran avec le message  incitant à cliquer sans trop tarder sur l’un des deux boutons poussoir FC+ court ou FC- court. Surtout, n’hésitez pas à téléverser P34_ENREGISTREUR_graphique.ino pour tester ces divers modes de visualisation. Quand on sort de la page des données numériques, l’écran devient tout noir. C’est le mode veille à utiliser quand l’enregistreur va fonctionner durant plusieurs jours. Autant économiser l’énergie électrique, et surtout les pixels bleus et jaunes du vaillant rectangle lumineux. Pour sortir du mode veille, il faut cliquer sur le bouton central du capteur rotatif qui ramène à l’écran l’affichage le plus épuré sur lequel figureront l’intégralité des échantillons, y compris naturellement ceux qui ont été mémorisés quand l’affichage était tout noir.

La journée et la semaine.

Bien que dans la pratique nous pourrons consigner des durées quelconques entre deux mesure d’échantillons comprises entre zéro et 8H 59′ 59 », souvent on aimerait bien que la « largeur » totale d’un écran soit calibrée pour représenter soit une journée entière, soit une semaine. Ce n’est vraiment pas compliqué, il suffit de consigner la bonne valeur pour le temps qui s’écoulera entre deux couples de mesures. Le calcul simpliste de la valeur à consigner est :

Un journée = 24H = 86400S  = 86400S / 120 soit 720S par échantillon = 0H 12min 0S à consigner.
Une semaine = 86400S x 7 = 604800S / 120 soit 5040S par échantillon = 1H 24min 0S à consigner.

Rien de bien compliqué.
Pour améliorer dans ces deux cas particuliers l’interprétation du graphe et tout particulièrement la largeur qui représente le temps écoulé, on pourrait envisager de tracer des repères verticaux pointillés à intervalles réguliers. Cette option n’a pas été retenue car elle surcharge exagérément le visuel. Par contre, et c’est le cas pour la Fig.100, quand la durée totale représente exactement une journée, l’écran est divisé en 12 intervalles représentant chacun 2H. Il est alors facile d’évaluer l’échantillon sous l’INDEX ancien de 7 heures 30′ environ. Du reste, quand on ouvre la fonction depuis le MENU de base, c’est l’écran Fig.102 qui sera affiché, (Avec le curseur tout à gauche.) car par défaut l’intervalle de temps entre les couples de mesures est choisi pour un total de 24H. Quand c’est exactement une semaine qu’il faut pour remplir les 120 échantillons, l’écran est alors divisé en sept intervalles chaque élément correspondant à une journée. Par exemple sur la Fig.103 on fait afficher les valeurs anciennes d’environ une demi-journée soit approximativement -12h.

Les protocoles de la saisie des intervalles de temps.

Comprenez-bien qu’il s’agit de définir le délai qui sera imposé entre la capture d’une paire de mesures, et non la durée correspondant à toute la largeur du graphe qui elle correspond à cent vingt fois cette valeur. Concrètement, c’est l’intervalle de temps qui séparera deux pixels voisins en largeur sur l’écran graphique. Une première approche avait consisté à définir cette durée en secondes, mais des délais important à initialiser conduisent à des calculs très indigestes. Aussi, le plus naturel quand on consigne une durée, c’est de la définir en heures, minutes et secondes.

La touche FC+ court ouvre la page de la Fig.104 qui invite à saisir le nombre d’heures. C’est la procédure de saisie générale qui s’appliquera de façon presque banale dans cette application. La seule différence, c’est que l’on peut vouloir un nombre nul et pas le minimum 1 qu’impose cette routine en faisant un BIP. Si vous voulez annuler la valeur actuelle sur la ligne VAL, il suffit de cliquer sur FC- court. Il impose toujours un 1 sur la ligne du bas, mais force un zéro sur celle du haut. La valeur ne s’affiche pas, tant qu’elle sera nulle, la ligne VAL restera noire. Inutile de vous escrimer sur FC+ court car 0 x beaucoup fait toujours zéro ! C’est en tournant le capteur rotatif que les valeurs changeront sur le chiffre des unités. Si ce dernier est différent de zéro, FC+ court reprend naturellement son rôle de multiplicateur par dix. FC+ long sauvegarde la valeur indiquée et passe à l’écran de la Fig.105 pour préciser les minutes.

Quand on valide la valeur affichée avec FC+ long, si la ligne de VAL est noire, la valeur consignée sera 0. La troisième action sur FC+ long enchaine la saisie des secondes. Vous remarquerez que l’on désire zéro, le total représentant l’intervalle entre deux échantillonnages pour une largeur d’écran à exactement  une semaine. La sortie du menu des options se fait avec l’écran de la Fig.107 qui résume les trois valeurs et calcule dans le rectangle jaune la durée totale de la « largeur d’écran ». On devine sans trop se tordre les méninges que dans l’exemple choisi on obtient exactement sept jours soit … une semaine !
Si vous avez soumis trois valeurs nulles, la rapidité de numérisation est maximale, mais en aucun cas infinie. Chaque mesure d’une paire d’échantillons s’accompagne d’un rafraichissement de l’écran qui exige environ 455mS. La plus grande cadence dans ces conditions ressemble à deux changements par seconde. Quand l’écran est en veille, la cadence ne change pas, car il y a un display.clear(); suivi d’une instruction display.update(); qui ralentissent pratiquement autant le processeur. L’écran de veille ne devient réellement pertinent que pour des délais d’enregistrements importants dépassant généralement les trente minutes, l’inconvénient d’un enregistrement « ralenti » comme ici à 0,5S n’est assurément que théorique.

Le mouvement perpétuel est impossible.

Aspect incontournable à toute procédure de saisie d’information, le sous-menu des options de l’enregistreur doit impérativement se charger de filtrer les valeurs soumises par l’opérateur pour écarter celles qui ne sont pas acceptables sur le plan de la logique ou celui qui résulte des « faiblesses informatiques ». La fonction ENREGISTREUR va bénéficier d’une telle censure pour garantir à l’utilisateur un fonctionnement fiable. Le premier traitement est relatif à la logique et à nos habitudes à raisonner [durée temporelle] dans un système sexagésimal limité à 24 heures.

Filtrage « logique » des données » :
La procédure de saisie fournit des entiers positifs ou nuls, donc pas de vérification à effectuer sur ces deux critères impératifs. Pour les minutes et les secondes il suffit de limiter les valeurs possibles  à l’amplitude du système sexagésimal. Minutes et secondes seront donc « rabotées » à 59 si vous avez consigné par mégarde des valeurs supérieures.

Filtrage pour « protéger le programme » :
Théoriquement rien n’interdit pour les heures d’utiliser la fourchette maximale de 60.000.000 tolérée par la procédure. Dans ce cas nous aurions un échantillonnage tous les 694 jours. La largeur totale de l’écran serait alors balayé en 231 années … l’économiseur d’écran sera indispensable !

D’une façon plus pragmatique, quand on ne sonde que toutes les 30 minutes, c’est déjà que l’on n’est pas vraiment pressé. À l’extrême limite du raisonnable, et uniquement pour faire un « compte juste », on pourrait envisager de n’effectuer un échantillonnage qu’une seule fois par jour. (La largeur de l’écran imposerait quatre mois pour un tracé complet.) Et bien ce ne sera pas possible dans l’état actuel du logiciel. Nous allons voir que la plus grande période possible est limitée à quarante cinq jours. Estimant qu’en l’état, cette application est largement suffisante, le « mouvement » perpétuel exigerait de revoir notablement la gestion du temps, le coût est estimé non « rentable ». Si PICOSYNTHÉ devenait une centrale météo par exemple, faire un RESET sur demande tous les quarante jours a été considéré comme tout à fait acceptable, vu que notre appareil reste avant tout un générateur de signaux qui n’est utilisé que très ponctuellement en enregistreur de données. Le nombre maximal d’heures accepté en saisie sera de huit : Une justification s’impose.

Chronométrer avec la fonction millis().

Faisant partie des ressources internes de l’ATmega328, un compteur particulier incluant 32 BITs est incrémenté immuablement à chaque milliseconde. Sur un RESET, ce dernier est remis à zéro. En consultant le contenu de ce compteur, on obtient très simplement la durée temporelle qui s’est écoulée depuis le démarrage d’Arduino ou depuis de dernier RESET. Si vous effectuez deux lectures de la valeur de ce compteur au cours d’un programme, la dernière moins la première permet de calculer avec précision le temps écoulé entre ces deux interrogations. La fonction millis() fournie par l’IDE retourne la valeur actuelle de ce compteur sous la forme d’un unsigned long. Générer des temporisations avec précision sans monopoliser le processeur dans des boucles d’attente revient à coder un traitement élémentaire. Voyons le principe de ce type de chronométrage.
La Fig.108 représente une boucle de programme durant laquelle on désire effectuer un traitement à intervalle régulier. Dans cet exemple, c’est la valeur contenue dans DELAI qui représente le temps qui doit s’écouler entre deux actions. Pour le début D d’un chronométrage, on commence par mettre la valeur actuelle de millis() plus celle de DELAI dans une variable de type unsigned long dont l’identificateur est Instant_de_fin_du_chronometrage. Le chronométrage est déclenché, le temps qui s’écoule depuis ce jalon est colorié en violet pastel sur le dessin. Puis on oublie somptueusement ces entités pour se consacrer à toutes les opérations incluses dans la boucle en cours d’exécution. Quand l’intégralité du travail a été effectué, on va entamer un nouveau cycle. La première instruction consiste à réaliser la comparaison C. Tant que millis() reste inférieur à Instant_de_fin_du_chronometrage c’est que la temporisation souhaitée n’est pas encore concrétisée. Dès que millis() dépasse cette valeur, c’est que DELAI est effectif et F marque la fin du chronométrage. « On recommence » traduit une nouvelle séquence de chronométrage. Immédiatement on réarme un chronométrage en réitérant l’opération D. Puis, le temps étant maintenant correctement pris en compte, on effectue le traitement particulier qui ponctue chaque intervalle de temps. La boucle peut ensuite reprendre sa ritournelle. Décrire un tel processus est en réalité plus délicat, que de le mettre en œuvre  dans un croquis. En voici la preuve :
Dans le logiciel, nous désirons effectuer un échantillonnage à intervalles réguliers, ces derniers étant définis par l’opérateur en Heures, Minutes et Secondes. Ces entités sont purement conventionnelles, le langage C++ ne sait même pas qu’elles existent. La seule entité que ce langage peut manipuler sous forme d’entiers, ce sont les secondes. (Et leurs sous multiples milli et micro.) Les consignes de l’opérateur sont transposées dans la variable Delai_entre_Enregistrements :

Delai_entre_Enregistrements = (unsigned long) (3600 * Heures) + (60 * Minutes) + Secondes;

Cette dernière contient la durée à chronométrer exprimée en secondes. Notez au passage la directive (unsigned long) qui impose au programme de transformer le résultat de la multiplication dans le type attendu pour  la variable de réception.

Considérons maintenant la séquence de notre démonstrateur qui prend en charge ce délai :
Le chronométrage a déjà été initié, c’est à dire que Instant_de_fin_du_chronometrage a reçu la valeur du « jalon » millis() + Delai.
En ligne (1) on vérifie si millis n’a pas dépassé Instant_de_fin_du_chronometrage. La comparaison est très rapide, et si elle est négative, la boucle poursuit son train train. Si la comparaison est positive, immédiatement on réarme en (2) et (3) un nouveau chronométrage. Notez au passage la transposition de type imposée par (unsigned long). La valeur de Delai_entre_Enregistrements est multipliée par 1000 car nous avons défini ce dernier en secondes, alors que millis() travaille en mS. Enfin, en  (4) on effectue l’échantillonnage, qui s’accompagne d’un affichage écran si « NON veille ».

Les limites de la fonction millis().

Dans le pire des cas, Delai vient de s’écouler juste après la comparaison . La boucle doit effectuer ses instructions banales avant une nouvelle vérification. Rassurez-vous, une mesure précise de la boucle actuelle montre qu’elle est parcourue en 250µS maximum. La perte de précision sera d’une milliseconde, pas davantage. Alors si Delai dépasse une minute … on ne va pas chipoter !
La limite critique vient du fait que le compteur matériel va passer automatiquement à zéro quand il aura atteint la saturation binaire de 4294967295 pour la valeur sur 32 BITs. Un calcul élémentaire 4294967295 divisé par  86400000 donne 49,71 jours.
Quand cet incident se produit, la variable Instant_de_fin_du_chronometrage contient une valeur très grande, bien plus grande que celle de Delai car on a accumulé un très grand nombre de fois son contenu. Le prochain échantillonnage sera effectué dans une durée incohérente très élevée. Aussi, pour simplifier le programme, on commence par limiter les heures à huit. La durée maximale de mesurage dans ces conditions est :
(8H 59‘ 59 ») x 120 = ((8 x 3600) + (59 x 60) + 59) x 120 = 3887880 secondes soit environ une durée de 45 jours. Pour ménager une sécurité de comportement du programme, la ligne d’instruction

if (millis() > 3900000000) Comptage_maximum(); // Message d’alerte à 45,14 jours.

surveille le débordement du compteur. Arrivé à cette valeur qui reste bien inférieure à son maximum possible de 4294967295 par mesure de sécurité, l’écran s’efface et affiche : 45 J MAXI : RESET !
En sortant de ce message d’alerte, la courbe est affichée pour éventuellement relever les données. Ensuite, vous effectuez un RESET et réentrez les valeurs souhaitées pour le Delai. Ce n’est pas idéal, mais n’oublions pas que la fonction ENREGISTREUR reste très marginale pour un générateur de signaux.

>>> Page suivante.