OSCILLOSCOPE avec sauvegarde.

Sauvegarde de six écrans graphiques en EEPROM :

Logiquement, avant de s’engager dans l’étude d’une nouvelle fonction à inclure dans le MENU de base, il serait logique en préambule d’en vérifier la faisabilité. Pour ce faire, nous devrions commencer par optimiser au maximum le programme P30_PICOLAB_complet.ino de façon à libérer suffisamment de place en mémoire dynamique pour ne pas risquer une collision de PILE. Pour tout vous dévoiler, j’avais très envie de pouvoir sauvegarder dans la mémorise non volatile du microcontrôleur des écrans de l’oscilloscope. Ainsi, plusieurs jours après, quand vous reprenez votre activité ludique d’électronicien, visionner quelques « copies d’écran » s’avère souvent salvateur pour continuer vos travaux en cours et pouvoir observer les différences qui résultent de vos interventions sur le système. J’ai donc dans ce but développé cette possibilité quitte à enlever une ou deux fonctions « marginales » pour pouvoir me faire ce petit plaisir. Ce ne sera pas indispensable si on optimise à outrance le programme.
Si je soulève ici le voile, et commence par développer la nouvelle version de l’oscilloscope, c’est qu’optimiser à outrance ne pourra se faire « en ligne » que si l’on dispose de la version « définitive » du module à remplacer dans PICOLAB. Ce didacticiel va donc nous placer sur des rails pour avancer de manière inexorable en évitant de nombreuses approximations progressives. Surtout n’imaginez pas que la suite représente la chronologie de mes recherches. De nombreuses marches ont été progressivement gravies, avant de pouvoir vous proposer un chemin sur lequel nous allons « avancer sans se retourner ».
Le programme démonstrateur P02_Oscilloscope_avec_MEMOIRE.ino résulte de nombreuses modifications avant d’aboutir à cette version totalement optimisée. Passons à son étude détaillée :

Améliorer la BASE de TEMPS.

Vous avez certainement remarqué que les numérotations des figures font suite à celles du didacticiel sur PICOLAB. Rien de plus normal, ce document n’est qu’un tome de plus pour la saga sur le mesurage. C’est un prolongement direct qui conduira à un laboratoire plus complet. Puisque nous allons reprendre le programme de la fonction oscilloscope, l’occasion est trop belle de lui faire bénéficier d’une petite augmentation de performance. Ce qui limitera le plus l’utilisation de cet item du MENU de base, c’est la « lenteur relative » de la cadence de numérisation. Dans l’étude précédente, la plus grande rapidité est de 2mS par graduation. Pour atteindre cette vitesse on « freine » la saisie de 170µS entre chaque numérisation. Si l’on accepte que la durée entre chaque graduation ne soit pas un nombre entier de mS, on peut engranger les valeurs à la plus grande vitesse possible. Dans cette optique on aboutit à 1,3mS par graduation. Ce n’est pas phénoménal, mais on obtient malgré tout un « étalement » significatif supplémentaire des signaux périodiques. Il serait dommage de ne pas introduire cette modeste amélioration qui ne coute finalement qu’un octet en EEPROM.
Calculons la plus petite valeur possible que l’on pourra adopter pour l’identificateur TBT dont les constantes sont consignées dans le tableau de la base de temps … car ce n’est pas zéro !
Dans le chapitre Table des délais pour la BASE de TEMPS nous avions la formule :

En oubliant la directive de format binaire int() qui n’est utile que pour le compilateur, de cette équation on déduit facilement :
TBT = Valeurs_BT * 1000 – 110.
TBT est alors confié à la procédure delayMicroseconds(TBT); procédure spécifique à l’IDE qui exige une valeur minimale de 3µS pour être fiable. (Cette information se trouve sur Internet quand on examine en détail les méthodes du langage C++ de l’IDE.)
L’équation devient : TBT = Valeurs_BT * 1000 – 110 = 3µS.
On en déduit que Valeurs_BT = (3 + 110 ) / 1000 = 0.113 µS, valeur qui sera consignée dans le premier emplacement de la table des options de la BASE de TEMPS.
Un seul octet de plus doit être intercalé dans l’EEPROM, mais qui oblige à réinscrire la totalité de la table des valeurs de la BASE de TEMPS. Comme c’est un incontournable avant de pouvoir activer le programme P02_Oscilloscope_avec_MEMOIRE.ino optimisé au maximum, il nous faut invoquer P01_Ecriture_Base_Temps_en_EEPROM.ino qui va se charger de cette mission. Nous pouvons à ce stade développer et tester la possibilité de figer en mémoire des « copies d’écran ».

Sauvegarder cinq copies d’écran de l’Oscillogramme.

C’est à mon sens un plus incontestable pour PICOLAB. D’une façon générale, l’EEPROM d’un microcontrôleur est conçue dans ce but. Ce n’est pas de la RAM, car elle est limitée à environ 100000 cycles d’écriture. Mais pouvoir sauvegarder des données sur le long terme, et les conserver quand l’alimentation est coupée, relève de la banalité dans le monde des microcontrôleurs. Station météorologique, dispositifs de comptages industriels, la liste des applications possibles est sans limite. Le besoin est tel que la grande majorité des produits actuels présentent cette faculté. Aborder ce sujet manquait à la généralité de nos études qui se proposaient d’embrasser pratiquement tous les aspects de la programmation des productions AVR.
Rien n’interdit de loger les données de copies d’écran à la suite de la table de la BASE de TEMPS. Rien ne nous assure que le nombre de cinq sera définitif. Passer à quatre libèrerait instantanément plus de 120 octets en EEPROM, avec la possibilité conjointe de libérer autant de place en mémoire dynamique. Pour minimiser les effets boule de neige d’une telle éventualité, le plus simple, et de loin, consiste comme montré sur la Fig.94 à sauvegarder les données en haut de l’EEPROM.
Les valeurs des adresses et la place occupée en mémoire par chaque « écran oscilloscopique » indiquées sur la Fig.94 résultent des études qui suivent et la mise au point du programme démonstrateur.

Analyse de la structure des empreintes.

L’empreinte est le vocable qui sera employé pour désigner l’ensemble des données qui seront stockées dans l’EEPROM et qui permettront de « reconstituer » entièrement l’écran dans l’état qu’il présentait au moment de la « photographie ». La façon dont ces données seront organisées est primordiale, car on doit en outre minimiser la place qu’elles exigeront en mémoire non volatile où chaque octet compte. Notez que le nombre d’empreintes possibles est paramétré par deux constantes NB_Empreintes et ADR_premiere_empreinte. Il sera ainsi très facile éventuellement de le diminuer. Passons à l’étude de l’organisation et de l’architecture adoptées pour les empreintes :
Pour pouvoir reconstituer l’écran, on ne va stocker que le minimum d’informations en EEPROM, quitte à recalculer certains paramètres. Par exemple la valeur efficace relève d’un calcul. Ce dernier est placé dans une procédure indépendante void Calcule_la_moyenne() qui sera invoquée par le programme durant l’exploitation, mais aussi quand on recharge une image d’écran. Le coefficient d’amplification également relève d’un calcul. La procédure
void Calcule_Amplification() sera chargée de cette tâche. Quand on recharge une empreinte, il est logique de penser qu’avoir à l’écran tous les paramètres est nécessaire pour en déduire la période et l’amplitude des variations. Il devient donc inutile de mémoriser l’état du booléen Grille. Le Quadrillage sera systématiquement validé au rechargement d’un graphe. Ainsi les valeurs de la base de temps et de l’amplification seront présentes à l’affichage. La variable booléenne sera forcée à true pour figer l’affichage jusqu’à ce que nous cliquions sur l’un des deux boutons poussoir. Sa valeur n’a donc pas besoin d’être sauvegardée. La structure d’une empreinte représentée sur la Fig.95 montre que les paramètres sont placés en premier et les échantillons ensuite. Ce choix est totalement arbitraire. La courbe pour sa part exige 120 octets, car il faut préserver l’intégralité des échantillons. Les deux premiers paramètres sont des booléens. Ils pourraient se coder chacun sur un BIT, un OCTET pouvant intégrer jusqu’à huit booléens. Cette approche n’est pas rentable dans notre cas, car il n’y a que deux booléens. On gagnerait 5 octets en EEPROM, mais le programme pour les extraire serait plus lourd. Le jeu n’en vaut pas la chandelle, on va pour la circonstance oublier cette idée.

Exploitation des empreintes.

Avant de développer de nombreuses lignes de programme, il faut définir, comme pour l’étude de chaque nouvelle fonction du reste, la stratégie d’exploitation de PICOLAB, sachant que pour l’oscilloscope les deux boutons poussoir FC+ et FC- sont indisponibles étant déjà plus que réquisitionnés. Il nous faut deux boutons de commande de plus.
L’idée pour satisfaire cette nouvelle contrainte consiste à employer A3 pour les sauvegardes par exemple, et A2 pour la restitution des images. Ces deux entrées sont toutes les deux maintenues à l’état « 1 » par une résistance de forçage. A3 par la résistance « de garde » de 22kΩ et A2 par la résistance de 1kΩ pour mesurer les résistances. Un simple fil entre ces entrées et la masse est suffisant pour déclencher les requêtes, mais il sera bien plus agréable de se servir d’un petit adaptateur, un module de « rien du tout » ne comportant que deux boutons poussoir complétant l’ensemble et le module du potentiomètre. La Fig.96 en fournit le schéma électrique. (Je n’ai pas osé qualifier ces quelques « bricoles » d’électronique !) La Fig.97 en donne le dessin du circuit imprimé, et enfin la Fig.98 le présente enfiché sur PICOLAB.

– C’est un escandale !
– Ha bon, mais pourquoi donc ?
– Tu avais promis dans le chapitre La totale, je te cite : « L’intégralité des divers adaptateurs, convertisseurs, « brancheurs » sont disponibles et
x trouveront leur place dans le coffret de PICOLAB ».
– Et alors ?
– Ben c’est pas juste, on doit encore en faire un de plus, et surtout je n’ai pas prévu sa place dans la boiboite de rangement !
– Et oui, le « Toujours plus » vient encore de frapper …

Signal de synchronisation fourni en externe.

C’est souvent en exploitation, imaginant que notre laboratoire est complètement abouti, que l’on rencontre un « manque ». Les nombreux tests de validation de PICOLAB ont fini par faire émerger un tel « Dommage, ce serait vraiment bien si on pouvait etc ». Remettre en branle le processus de téléversement sur site, se remettre dans le bain nécessite des efforts importants. Aussi, ce n’est à envisager que pour une vraie amélioration. Il arrive relativement souvent, que l’on veuille déclencher un processus externe analysé avec l’oscilloscope, lorsque l’on déclenche sur ce dernier une numérisation. En particulier, la LED d’Arduino est allumée en début de séquence, et éteinte lorsque les 120 mesures sont effectives. Il serait donc possible de se servir du front montant sur cette dernière pour fournir en externe un signal de synchronisation. Sauf que D13 n’est disponible sur aucun connecteur.
Une solution élégante est possible et facile, d’autant plus que l’on va la concrétiser sur le petit module en cours de réalisation. L’entrée analogique A5 n’est reliée à rien quand l’adaptateur pour mesurer des intensités n’est pas branché. Il se trouve que l’ATmega328 permet de s’en servir comme une sortie binaire tout ce qu’il y a de plus ordinaire. C’est la raison pour laquelle sur le schéma de la Fig.96 on note la présence de la LED D reliée à A5. La cathode est réunie à la masse GND par la résistance de charge R. C’est aux bornes de R que sera disponible le signal de synchronisation. La diode électroluminescente D engendre une chute de tension. Il faut choisir dans vos éléments disponibles celle qui présentera la chute de tension la plus faible. Sur le prototype, c’est une LED rouge qui est sélectionnée. Entre la sortie SYNCHRO EXT et la masse on observe un signal variant entre 0 et +3,1V ce qui est généralement suffisant. Si D n’était pas insérée dans le circuit, le signal en sortie présenterait la pleine amplitude de 0 à +5V. Toutefois n’oublions pas que suite à la détection du seuil de synchronisation, le programme doit allumer la LED témoin, ce qui décale un peu la saisie des échantillons. Dans un souci de rigueur (Certainement un peu exagérée.) pour n’avoir qu’une seule sortie binaire à changer d’état, la LED d’Arduino ne sera plus employée pour visualiser le déclenchement de numérisation.

– C’est un escandale !
– Ha bon, encore ?
– Ben oui, car Môamôa je n’ai pas envie de réaliser l’adaptateur, je me contenterai d’établir les contacts à la place des boutons poussoir avec un simple fil, j’en ai plein plein plein des fils !
– Et alors ?
– Ben avec ce programme je n’aurais plus l’information visuelle de la synchrotruc Môamôa !
– Fichtre, mais c’est vrai ça, faut téléphoner au ministre des adaptateurs …

Rassurez-vous, il est hors de question d’engendrer des frustrations. Dans le programme complet c’est l’oscilloscope avec adaptateur P03_Oscillo_MEMOIRE_et_SYN_EXT.ino qui a été intégré. Mais gratuitement vous disposez de P02_Oscilloscope_avec_MEMOIRE.ino qui lui fonctionne avec utilisation de la LED d’Arduino. Il vous suffit de remplacer les deux séquences void Fonction_OSCILLOSCOPE() et void Effectue_une_numerisation() par celles contenues dans P02_Oscilloscope_avec_MEMOIRE.ino pour retrouver l’usage de la LED 13.
Sur la Fig.98 on retrouve PICOLAB toujours sans son couvercle avec en 1 la ligne de programmation. En 2 le module qui permet l’isolement du potentiomètre et la saisie des paramètres. En 3 le petit accessoire pour faciliter la mise en œuvre des Empreintes. Les deux vis visibles en 4 servent de pieds pour annuler tout porte-à-faux. En 5 se trouve le picot sur lequel est disponible le signal de synchronisation avec en 6 la LED témoin de la séquence d’échantillonnage. En 7 passe sous 3 la ligne qui va vers le module potentiométrique alors que 8 et 9 servent respectivement à initier une sauvegarde d’écran et la visualisation des empreintes. En 10 on observe la ligne reliée à GND et à R Ω qui passe sous le module 2. Notez que le souplisseau bleu et le souplisseau rouge permettent de repérer le sens de branchement. Si en entrée de fonction OSCILLOSCOPE il y a passage immédiat à la saisie d’option pour visualiser une copie d’écran, c’est que vous avez inversé le branchement. (Cette erreur est strictement sans risque pour le matériel.) En 11 la languette de sélection des lignes qui sont réunies à la douille jaune 12.

Dialogue pour enregistrer et faire afficher les empreintes.

Deux boutons poussoir (Ou deux entrées avec fils de contact.) sont dédiés à la gestion des copies d’écran. Il reste à définir la façon dont on va procéder. La technique retenue est issue de l’idée qui consiste à réserver aux deux boutons 8 et 9 l’appel du sous-menu désirée, FC+ et FC- servant ensuite, en standard, à sélectionner l’option désirée. Le bouton poussoir 8 est dédié à la sauvegarde en EEPROM des écrans. Comme il y a « écrasement » de l’empreinte déjà mémorisée, cette option peut être considérée comme dangereuse. C’est la raison pour laquelle le bouton d’appel est rouge et qu’il active une demande de confirmation. (Voir Fig.99 et Fig.100)
Avec FC- il y a abandon et reprise du mode exploitation. Si l’on valide avec FC+, il y a passage au sous menu de sauvegarde. Représenté sur la Fig101 on note qu’il y a dans la « zone jaune » indication du numéro de l’empreinte qui sera modifiée. Ce numéro d’ordre variera entre 1 et 5 on s’en doute, avec recyclage. Nous pourrions nous attendre à ce que ce soit le n°1 qui soit indexé en entrée de l’action de sauvegarde. À l’usage on se rend compte que ce n’est pas idéal. Il est préférable de désigner systématiquement la dernière empreinte visualisée. Ainsi on ne modifie que cette dernière, gardant les autres en réserve pour comparaison. Si on clique sur FC- on peut à convenance changer la cible. Les emplacements varient en augmentant systématiquement avec recyclage de 5 vers 1. FC+ entérine l’action. Si vous avez accepté par erreur une sauvegarde et que vous désirez impérativement conserver les cinq images en réserve, il suffit, arrivé à ce stade du sous menu, de faire … un RESET !
Le matériel est disponible, la stratégie d’utilisation est définie, nous pouvons passer à la programmation. Pour tester les programmes démonstrateurs, vous avez déjà activé en préambule le logiciel « d’imprimerie binaire » P01_Ecriture_Base_Temps_en_EEPROM.ino et inscrit les valeurs de la base de temps en EEPROM.

Architecture logicielle des séquences de stockage.

Fidèle à l’emploi des organigrammes pour expliciter les séquences pertinentes des programmes d’exploitation des copies d’écran, on va minimiser au maximum les longs textes. Tout est exprimé dans le contenus des listages, commencez par les consulter. En particulier les innombrables remarques et commentaires apportent une lumière précise sur certains détails « pointus ». Faites le parallèle avec les organigrammes qui suivent, vous allez ainsi aisément comprendre le fonctionnement du démonstrateur P02_Oscilloscope_avec_MEMOIRE.ino dans ses grandes lignes. La variante P03_Oscillo_MEMOIRE_et_SYN_EXT.ino ne modifie que l’usage de A5 à la place de D13 pour allumer et éteindre la LED témoin du déclenchement de la numérisation.
Inutile comme c’était le cas pour sauvegarder en EEPROM le LOGO et la table des valeurs de la BASE de TEMPS, d’avoir recours à un programme utilitaire que l’on n’active qu’une seule fois. Les empreintes oscilloscopiques sont des variables, et à ce titre c’est le programme utilisateur qui devra se charger de l’inscription en mémoire non volatile. Le but du chapitre qui suit est de décortiquer les structures de traitement affectées à cette mission. L’organigramme de la Fig.102 se passe pratiquement de commentaire. La procédure en (1) attend jusqu’à détection d’un enfoncement puis du relâcher de l’un des deux boutons FC+ ou FC- . Ensuite, le test en (2) détermine la touche qui a été activée. Peu importe que ce soit un clic long ou un clic court. Le RETOUR de cette procédure se fait dans le corps principal de la fonction OSCILLOSCOPE. Il ne faut pas en sortir, raison pour laquelle Clic_long est mis à false. Enfin, n’oublions pas l’instruction Clic_sur_le_BP = false pour acquitter l’appel de la séquence de sauvegarde. Valider en (1) avec la touche FC+ fait passer en (2) au menu de sauvegarde.
En (4) le logiciel pénètre dans une boucle de type « Tant que non touche FC+ faire actions ». La seule façon d’en sortir, c’est de passer par void Ecrit_EMPREINTE_en_EEPROM() qui écrasera l’image actuelle. Si vous désirez la conserver, soit vous changez son numéro d’ordre en (7), soit vous avez recours en (6) au bouton RESET de Boarduino.

Remarquez au passage deux petits détails de programmation. L’ordre N de l’empreinte en cours de traitement sera désigné dans le logiciel par QRG_ETALON. C’est une technique non mentionnée dans le chapitre abordant les techniques pour minimiser au maximum la taille mémoire occupée par les variables. Quand dans une séquence un identificateur de type idoine est disponible, on l’utilise comme « variable superposée ». Le programme y perd un peu en lisibilité, raison pour laquelle il est sage dans un tel cas de figure, de le mentionner en remarque dans le SOURCE.
Dans la séquence, N va varier entre 0 et 4 et non entre 1 et 5. Donc en (8) l’instruction display.print(QRG_ETALON + 1); sert à rétablir l’affichage attendu. Cette transposition permet alors le calcul correct :
INDEX = ADR_premiere_empreinte + (QRG_ETALON * 125); du pointeur qui dans l’EEPROM sera chargé de se positionner au début de l’EMPREINTE en cours de traitement. Ce mécanisme est montré sur la Fig.104 en supposant que c’est l’empreinte n°4 qui est traitée en affichage et en sauvegarde. La constante paramétrée ADR_premiere_empreinte pointe Img 1 à l’adresse relative 399. Multipliant par zéro la taille 125, nous aurons bien un premier déplacement nul. Comme on traite Img 4, QRG_ETALON vaut 3. Le calcul effectué fait bien pointer INDEX à l’adresse relative 774 qui constitue le premier octet d’Img 4. La Fig.105 présente la séquence qui va inscrire les 125 octets de l’EMPREINTE en mémoire EEPROM. Cette dernière est d’une simplicité déconcertante puisqu’elle ne fait que cent vingt cinq fois écrire un OCTET à l’adresse relative pointée par l’identificateur INDEX. La première étape en (9), par le calcul explicité sur la Fig.104, positionne le pointeur sur la première cellule à modifier. La suite est triviale ou presque. On écrit directement les deux premiers booléens qui chacun vont « gaspiller » un OCTET. Puis vient le tour du byte Ordre_BT en (10). Il importe de remarquer que chaque écriture d’un OCTET en EEPROM est immédiatement suivie d’une incrémentation d’INDEX pour pointer la prochaine cellule à modifier. Comme effectuer l’écriture en EEPROM d’un OCTET immédiatement suivie de l’incrémentation du pointeur INDEX se retrouve souvent dans le programme, il devient tout à fait rentable de créer une procédure avec passage du paramètre octet. Rien que pour la fonction OSCILLOSCOPE on réduit de 110 octets la taille du logiciel ce qui est considérable.
La variable Seuil-SYN est codée sur deux OCTETs, car c’est un int. On ne peut pas l’inscrire directement en EEPROM. Un int étant construit avec deux OCTETs consécutifs, il suffit de les envoyer l’un après l’autre. Pour « récupérer » les huit BITs de poids faible, on se contente de forcer à « 0 » les huit BITs de poids forts avec l’instruction :
x OCTET = (Seuil-SYN & 255).
Pour mémoire, l’opérateur logique ET sert à forcer à « 0 » des BITs quand dans le masque logique associé ils sont initialisés à « 0 ». Pour extraire les huit BITs de poids forts, on va effectuer huit décalages à droite avec le traitement (Seuil-SYN >> 8). La combinaison des poids forts se retrouve en poids faibles et l’on remplace les poids forts par huit « 0 ». Manipulation logique assez classique en vérité !

Architecture logicielle des séquences de rechargement.

Rigoureusement analogue à la séquence de sauvegarde, la procédure de rechargement d’une copie d’écran débute par une séquence réciproque dans laquelle l’écriture d’un octet en EEPROM est remplacée par la lecture de ce dernier. On commence par pointer avec INDEX le premier OCTET de l’empreinte, puis par une séquence de 125 lectures successives on replace tout ce petit monde au bon endroit dans les cellules des variables du programme. Seule petite différence, le rechargement s’achève par l’appel des deux procédures de calcul void Calcule_la_moyenne() et void Calcule_Amplification() pour « reconstituer entièrement l’image ». Exactement comme pour l’écriture en EEPROM, on peut envisager une procédure qui récupère un OCTET et incrémente le pointeur INDEX. Différence notable par rapport à l’écriture, ici on construit une FONCTION qui retourne un résultat. Une FONCTION est déclarée comme un identificateur typé, et il n’y a plus le mot void qui la précède. Pour la circonstance on déclare byte Lire_un_OCTET_en_EEPROM() car la valeur retournée sera de type byte. Quand l’incrémentation suit le return qui termine la fonction, cette dernière n’est pas effective. La fonction commence donc par augmenter la valeur d’INDEX. Puis, pour lire la cellule EEPROM , INDEX-1 restitue la bonne adresse sans pour autant modifier le contenu de la variable INDEX. Passer la lecture des cellules en une fonction fait encore gagner 124 octets dans le programme. On comprend ici en quoi ne pas se contenter d’une écriture « immédiate », mais chercher à optimiser du code peut aboutir à des économies parfois substantielles d’OCTETs.

Toujours dans le chapitre « On optimalise l’optimisation », positionner le pointeur INDEX sur le début de l’empreinte revient à faire exactement la même chose en écriture et en lecture. Il devient évident de passer ce traitement cloné de chez « Dupliqueàmord » dans une procédure telle que Positionne_INDEX_sur_Empreinte(), ce qui réduit encore le code de 14 octets : La moisson est bonne, on va pouvoir revendre des emplacements réservés si ça continue.
Quand le démonstrateur a montré le bienfondé de toutes les modifications, et que sauvegarder des écrans et les restituer est devenu une réalité, rapidement une faiblesse opérative s’est imposée : Une image étant présente à l’écran : Laquelle ? Quand on sauvegarde, en situation de travail banal, on note souvent les circonstances ayant produit les graphes mémorisés et leur ordre. Quand on visionne, surtout si les graphes se ressemblent, il devient impossible de savoir quelle est la donnée visualisée. La solution est simple : Afficher le numéro d’ordre sur l’écran, si c’est une empreinte qui est visualisée. La présentation retenue, mise en évidence dans les médaillons rouges des Fig.106 et 107, résulte de diverses tentatives pour trouver la meilleure présentation. Cette information qui vient surcharger l’écran ne doit pas trop empiéter sur le dessin de la trace. Comme c’est sur la gauche que l’on peut observer la conséquence du seuil de synchronisation choisi associé au sens du front de déclenchement, l’expérience à montré que situer en bas et à droite cette donnée était le meilleur compromis. Le chiffre utilisé est de taille minimale. Pour le mettre en évidence on utilise un affichage inversé. Pour minimiser sa présence, il est placé à des coordonnées qui utilisent la grille pour compléter le fond d’écran illuminé. Ainsi ce caractère ne masque en tout et pour tout que la moitié d’un carreau de la grille. Enfin, ayant estimé que visionner une empreinte n’est pas « destructeur d’informations », c’est la raison pour laquelle une confirmation n’est pas mise en œuvre pour cette option.

Un « jeu d’essais » pour les EMPREINTES.

Tester une séquence ou un module logiciel comportant plusieurs variables impose de construire un « JEU D’ESSAI ». La technique consiste à élaborer une combinatoire qui permet de vérifier tous les cas possibles. Il vaut mieux s’arranger à ne pas avoir trop de cas à explorer. Une telle combinatoire judicieuse est nommée « JEU D’ESSAIS » dans le monde informatique. Vous vous doutez qu’avant de voir fonctionner parfaitement les sauvegardes et les rechargements d’images, de nombreux échecs ont fait émerger d’innombrables petites erreurs de logique ou de codage. Chaque « campagne d’essais » était soutenue par un jeu d’essais visant à effectuer la vérification en un minimum de temps. Lors de l’élaboration initiale de l’OSCILLOSCOPE, je me contentais d’injecter en E un signal sinusoïdal fourni par un petit transformateur secteur, avec superposition de tension continue pour rester dans la marge 0 à +5V du CAN. En revanche, pour développer la sauvegarde des écrans, j’ai mis à contribution un petit générateur B.F. sur lequel il est possible à convenance de choisir l’amplitude de l’onde, la valeur d’une composante continue, et surtout la forme. C’est très utile quand on recharge des images enregistrées, car on voit immédiatement si la trace présente la forme attendue. Le tableau donné ci-dessous liste le mon jeu d’essais. Pour obtenir des amplifications x2 et x4 il faut injecter en E un signal de faible amplitude. Pour pouvoir déclencher la numérisation, on doit en conséquence imposer un Seuil de SYNchronisation adapté. Pour les gains x2 et x4 il est logique de trouver des valeurs de franchissement faibles. Les tensions imposées sont systématiquement différentes. Enfin, l’éventail des paramètres B.T. couvre globalement la plage des options possibles.

Comme vous le constatez, toutes ces photographies ont été réalisées avec la version bicolore de l’afficheur OLED. Elles subissent la petite coupure d’une ligne de « non pixels » entre la zone orange et la zone bleue quand on est en format DOUBLE. J’avoue qu’en ce qui me concerne, je trouve que la couleur apporte beaucoup dans l’agrément d’utilisation de PICOLAB. J’accepte donc très volontiers ce petit inconvénient. Quand une image est restituée sur l’écran, par défaut il y a validation de la grille pour faire afficher les paramètres de son enregistrement. On peut toutefois librement modifier les options et, comme montré sur la Fig.111 relative à l’empreinte n°1, masquer cette dernière pour avoir la trace seule à l’écran. Attention lors de cette manipulation à ne pas invalider la synchronisation, car en sortie du menu des paramètres, l’image serait perdue. Ceci étant précisé, si ça vous arrive il suffit de la recharger à partir de l’EEPROM. La Fig.111 montre bien la petite « cassure » qui résulte de la « ligne morte ».

Analyse différée des oscillogrammes.

Analogue à la Fig.111, la photographie de la Fig.112 est obtenue à partir de la copie d’écran n°5 quand la grille n’est plus affichée. On reconnait bien un signal en « escalier » comportant huit niveaux. Interprétons les informations disponibles : Cette trace est obtenue avec un coefficient d’amplification x2. Donc chaque graduation verticale représente une tension de +2,5V / 2 = 0,5V. L’amplitude de ce signal fait quatre graduations, il varie donc entre 0 et +2V environ. Chaque « marche » fait 2 / 7 = 0,28V. Le déclenchement s’est produit en A au moment de la cinquième marche soit 5 x 0,28 = 1,4V ce qui est cohérent avec l’information de SYNchronisation. La base de temps fait 90mS. Une croissance complète exige environ 5,6 graduations. La période de ce signal avoisine donc les 504mS soit une fréquence calculée de 1,98 Hz et l’on retrouve les 2Hz programmés sur le générateur ayant fourni ce signal. On observe que plusieurs niveaux en médaillons rouges tels que B, C et D semblent « instables ». En observant à la loupe, chaque marche fluctue d’un pixel. L’extrait des valeurs numériques enregistrées pour l’image n°5 et donné en Fig.114 montre que la marche numérisée à 028 est constante. La suivante varie entre 043 et 044. Le pas suivant varie à son tour entre 057 et 058. Enfin le début du pas suivant adopte des valeurs qui oscillent entre 073 et 074. Ces variations numériques constatées sont parfaitement normales. D’une part un CAN est toujours à plus ou moins une unité. D’autres part la saisie des valeurs sur E se fait à la volée. Une seule mesure est réalisée par échantillon. Il n’y a donc aucun lissage pour effectuer une moyenne sur plusieurs saisies et ainsi éliminer les

parasites et « le bruit ». Dans ces conditions, n’être victime que d’une variation de 1 prouve que le générateur B.F. était en basse impédance sur le signal fourni, rendant ce dernier peu sensible aux parasites.

Copier n’est pas jouer !

– C’est un escandale !
– Encore ? Mauvaise journée manifestement ! Mais quelle est l’origine de ta misère ?
– Ben môamôa je n’ai pas de génératogénimachin pour me faice ces belles traces. C’est toujours les mêmes qui en profitent,
xceux qui ont du super matos !
– C’est pas grave, contentes-toi de la sinusoïde, tu as bien un transfo quelconque pour la générer ?
– Ben oui que j’ai un transformateur. Mais tu l’as écrit toi même, que des sinus c’est pas génial.
– OK, je vais en parler au ministre des basses fréquences.

Effectivement, il a un peu raison notre « rouspéteur de service ». Disposer d’une copie des images montrées dans ce document pourrait rendre service à beaucoup d’entre-vous. Pour pouvoir satisfaire ce désir, le programme P04_Inscrire_5_empreintes_en_EEPROM.ino gratuit et en promotion, permet de cloner mes cinq empreintes dans l’EEPROM de votre ATmega328 quand vous l’activez. N’oubliez pas après de téléverser à nouveau P03_Oscillo_MEMOIRE_et_SYN_EXT.ino pour les visualiser. Vous pourrez ainsi observer ces exemples de formes d’ondes, comparer ce que montre l’écran avec les valeurs consignées dans le tableau du jeu d’essais etc.
Si vous consultez P04_Inscrire_5_empreintes_en_EEPROM.ino vous constaterez qu’il fonctionne exactement comme le petit utilitaire qui inscrivait le LOGO en EEPROM. Octet par octet il puise les 625 valeurs dans une grande table de bytes … que j’ai dû fournir un à un à l’IDE … Quelle galère !
Initialement je les avais écrits comme montré sur la Fig.115 c’est à dire avec trois chiffres. Mais le compilateur interprétait ces données commençant par des zéros « comme codées » en Octal et générait une foule d’erreurs. Il a fallu remplacer tous les zéros en tête par des espaces. Gnarf gnarf gnarf !

Écrire une table de 625 valeurs dans un programme source est long et laborieux, mais encore faut-il disposer de ces informations qui ont été générées automatiquement par le programme de sauvegarde des écrans. Pour aller « voir » le contenu de l’EEPROM, il suffit de créer un logiciel outil de plus. Pour vous permettre à votre tour de « visionner » le contenu de l’EEPROM de vos microcontrôleurs ATmega328, vous avez à votre disposition deux petits utilitaires :

• P05_Visualiser_EEPROM_en_DECIMAL.ino qui liste le contenu des 1024 octets en décimal,
• P06_Visualiser_EEPROM_en_HEXADECIMAL.ino qui divulgue ce contenu en HEXAdécimal.

Le premier m’a servi à avoir une liste des valeurs à loger dans l’utilitaire de « clonage ». Le deuxième est plus général, en particulier il permet de « travailler » en binaire, parfois c’est bien utile.
Pour clore ce chapitre, l’écriture de la table des valeurs est paginée pour différencier dans le tableau chaque images. Pour analyse, la Fig.115 montre la fin du listage que produit sur la ligne série USB l’utilitaire P05_Visualiser_EEPROM_en_DECIMAL.ino avec dans l’encadré rouge la dernière empreinte. En jaune nous avons la zone extraite sur la Fig.114 et en vert les deux premier booléen. Comme ils sont à « 1 » on en déduit que DOUBLE et Front_montant sont à true. En bleu l’ordre de la base de temps est 17, donc la dix huitième valeur dans la table de la base de temps : C’est bien l’avant dernière valeur pour 90mS. Pour le SEUIL on a 5 / 1023 * 251 = 1,23V qui est arrondi à 1.2 sur l’écran OLED.

Utilisation d’une Entrée Analogique en Sortie Binaire.

Cette faculté présentée par les six entrées analogiques A0 à A5 n’est pas forcément connue « du grand public », façon de traduire le fait que l’on rencontre assez peu de logiciels sur Internet qui y font appel. Pourtant, quand le besoin de capteurs analogiques est faible, alors que simultanément la demande en sorties est forte, utiliser ces broches en sorties binaires enrichi considérablement la combinatoire possible. Dans notre cas, ce n’est pas une pénurie de sorties qui motive cet usage de la broche A5, mais sa disponibilité « géographique » sur un connecteur particulier.

Initialiser l’une des six broches A0 à A5 en sortie binaire, puis la faire changer d’état est absolument élémentaire, la procédure est strictement identique à celle des autres broches binaires. Dans l’IDE, les quatorze sorties binaires sont désignées de D0 à D13 par conventions, certaines étant dédiées sur la carte à des branchements ou des utilisations spécifiques : LED d’Arduino, TX, RX, les interruptions …

De façon cohérente et homogène, les broches A0 à A5 étant par le programmeur considérées comme des liaisons binaires, elles seront alors désignées tout simplement par la suite ordonnée D14 à D19 :

x      >>>>>>> D14 fait référence à la broche habituellement identifiée par A0,
x      >>>>>>>  D15 fait allusion à la suivante A1,
                               …
x      >>>>>>>  D19 désigne la broche conventionnellement repérée par A5.

Nous disposons de tous les éléments pour commenter la nouvelle mouture de l’oscilloscope dans laquelle on traite les empreintes et qui fournit sur D19 un signal de synchronisation externe. L’ordinogramme de la Fig.116 présente la fonction dans son ensemble. Les deux procédures (1) et (2) sont explicitées en détail dans le chapitre Architecture logicielle des séquences de stockage, inutile d’en rajouter une couche.

Analysons maintenant la procédure de numérisation. Étalée sur la Fig.117 elle commence par tester le booléen Synchronisation. S’il est à vrai, en (4) il y aura attente jusqu’à ce que les conditions de seuil et de sens de transition soient satisfaites. Durant cette phase d’attente qui peut durer de manière infinie si les conditions ne sont jamais satisfaites, (Pas de signal en E ou les limites ne variations ne franchissent jamais le seuil.) l’écran ne change plus, il reste figé.
Pour avertir l’opérateur que l’appareil est en attente de déclenchement, en (5) il y a effacement la l’ancienne trace. Pour minimiser la durée d’exécution de la boucle de saisie et de stockage des valeurs échantillonnées, les calculs préliminaires sont effectués en (6) et en (7). La séquence se met alors à analyser les événements qui se produisent sur l’entrée E. Dès que le signal franchit le seuil ET dans le sens de variation consigné, il y a déclenchement le la numérisation proprement dite. La sortie D19 est forcée au niveau +5V et la boucle de 120 mesures est engagée. Puis, la broche D19 est repassée à l’état bas. Le créneau de synchronisation externe présente une durée qui sera fonction de la valeur adoptée pour la base de temps. Cette durée peut varier entre les extrêmes de 0,013S (B.T. = 1.3mS) et une secondes. (Pour la base de temps la plus grande de 100mS par graduation.) C’est donc le front montant du signal de synchronisation fourni en externe qui sera significatif d’un début de mesurage.

NOTE : Pour que le déclenchement puisse se faire alors que le signal extérieur est « muet » car il attend le front montant sur la broche D19, il faut configurer les options en consigne en NON synchronisation. Du reste pour tester l’utilisation de la broche SYN EXT, faites l’expérience élémentaire suivante : De la sortie SYN EXT branchez une résistance de 22kΩ allant à l’entrée E. Ajoutez un condensateur de 10nF par exemple entre la borne E et GND et vous obtenez (Fig.118) la belle courbe de charge classique d’un condensateur.

>>> Page suivante.