L’utilisateur n’a que faire d’un nombre compris entre zéro et 4093. C’est la valeur de la tension mesurée qui présente directement « le réel ». Aussi, la conversion ayant été effectuée, il faut transposer le résultat en un affichage qui varie entre 0 et VREF pour qu’il soit significatif d’une entité palpable. C’est l’objet du démonstrateur P03_Affichage_sur_ecran.ino.
Puisque la finalité de ce didacticiel réside dans la réalisation d’un petit oscilloscope, il faudra faire usage d’un écran pour le rendre autonome et qu’il ne dépende plus de la présence d’un P.C.
Autant préparer le terrain et mettre en œuvre un afficheur graphique. Comme le but de ce didacticiel est d’appréhender le fonctionnement des oscilloscopes, que la performance n’est pas le critère prioritaire, on va se contenter d’un afficheur peu onéreux, avec pour pénalité le manque de définition. Mon choix s’est porté sur l’écran OLED de de 1,3 Pouces très facile à se procurer à un tarif raisonnable dans le commerce en ligne. Les références sont kyrielles et celui de la Fig.8 monochrome existe en blanc ou en bleu selon la référence approvisionnée. Il est pilotable par I2C avec seulement deux broches de commande qui sont nécessaires pour le gérer. Il présente une de définition 128 x 64 Pixels. Muni d’un contrôleur SSD1306 il est lumineux, donc sans rétro-éclairage. (REMARQUE : Il existe aussi en 0,96 pouces de diagonale. Mais c’est bien celui qui fait 1,3 pouces qui est mis en œuvre ici.) ATTENTION : Certaines références ne sont pas compatibles avec U8glib.h donc vérifier à la commande. Comme tous les composants populaires, on trouve en ligne une bibliothèque pour les rendre directement et facilement utilisables. Dans notre cas on va utiliser la classique U8glib.h qui accompagne ce didacticiel dans le dossier <Bibliothèques>. Également fourni le document Bibliothèque U8glib.pdf à imprimer Recto/Verso pour réaliser un petit livret au format A5 qui résume sur vingt pages les méthodes de U8glib.h.
De la numérisation à l’affichage du réel.
Pour illustrer ce propos, le démonstrateur P03_Affichage_sur_ecran.ino va transformer le petit montage de la Fig.4 éliminant l’un des potentiomètres en un quintuple voltmètre autorisant la mesure précise et simultanée de huit tensions. S’il s’agissait de notre projet définitif il serait dans la logique de prévoir des calibres différents possibles sur chaque entrée. Dans cette phase de nos expérimentations on va se contenter d’un calibre commun de 0 à +5Vcc et contrairement à l’oscilloscope on ne va pas prévoir des sécurités pour les inversions de polarité ou les dépassements dangereux de tension. Si vous voulez vraiment en faire un appareil pour votre laboratoire, il suffira de transposer le schéma d’entrée de l’oscilloscope et de prévoir des atténuateurs pour mesurer des tensions élevées voir d’ajouter un redresseur pour la mesure des tensions alternatives …
Le petit logiciel P03_Affichage_sur_ecran.ino impose donc au préalable d’installer la bibliothèque U8glib.h sur le P.C. et de déclarer cette dernière à l’IDE. Puis, le téléversement provoque l’affichage de l’écran Fig.8 pendant quatre secondes avant de passer à celui de la Fig.9 sur lequel on comprend pourquoi seulement cinq canaux sont utilisés sur les huit potentiels. C’est la définition en hauteur de l’afficheur OLED qui limite ce nombre, encore qu’il est vraiment rare dans nos activités ludiques d’avoir à surveiller autant de tensions simultanément. Il serait possible d’afficher les huit canaux avec la police de caractère de 4 x 6 pixels, mais elle est presque illisible et les caractères manquent forcément d’élégance esthétique.
Faire la moyenne de cent mesures.
Bien qu’avec 12 BITs pour la numérisation il serait possible d’afficher avec une précision du milli- volt sur le plan opérationnel ce n’est pas justifiable, et ce d’autant plus que le quatrième chiffre significatif fluctue sans arrêt. Aussi nous allons nous contenter d’une résolution du centième de volt plus que suffisant dans la pratique. Même dans ces conditions l’affichage manque de stabilité. Aussi, pour éviter des changements permanents de la valeur affichée, il suffit de ralentir la fréquence de rafraichissement. La première idée qui vient à l’esprit consiste à introduire un delay(100) dans void loop(). Le microcontrôleur passe alors la majorité de son temps « à se tourner les pouces ». Aussi il est bien plus astucieux de consommer tu temps pour les numérisations. Pour chaque canal on va calculer la moyenne de cent mesures qui aura pour effet de « lisser le bruit parasite ». Comme entre chaque nouvel affichage il faut réaliser 500 conversions analogiques vers numérique, le temps consommé procure à l’affichage une cadence parfaite et une stabilité remarquable. Dans ces conditions on arrive aisément à ajuster la tension variable injectée par un potentiomètre au centième de volt.
Calibration précise des transpositions numériques.
Dans pratiquement tout logiciel on est incité à utiliser des constantes qui fonction du matériel par exemple doivent être calibrées avec précision. Ces constantes deviennent des paramètres. Quand on est amené à corriger de nombreux paramètres dans un listage bien plus « étalé » que celui du petit démonstrateur, il est fortement recommandé de définir tous les paramètres d’initialisation en tête de programme et si possible de les regrouper. Ainsi, on a une énumération compacte et l’on ne risque pas d’en oublier, et surtout c’est bien plus rapide que d’avoir à chercher de multiples emplacements dans un long listage. Cette façon de faire concerne directement la « programmation avec méthode ». Enfin, pour les retrouver immédiatement, les lignes de paramètres sont repérées en les terminant par //@@@@@@@@@@@@@ ce qui naturellement est fait par discipline dans P03_Affichage_sur_ecran.ino et dans tous les autres programmes.
Sachant que la valeur retournée par la numérisation dépend directement de celle de VREF on doit dans la transposition en tenir compte et faire intervenir un Coef_de_conversion. Dans P03 qu’il faut téléverser, la broche de VREF est reliée directement au +5Vcc délivré par la ligne USB. En théorie, lorsque l’on injecte directement cette tension sur l’une des entrées, la valeur numérisée est de 4093. Observons les deux lignes de programmation suivantes :
La ligne (2) sert dans une boucle de type for à visualiser les cinq lignes, chaque valeur mémorisée dans TAMPON étant sélectionnée par le byte Canal. Multiplier par 0,001 revient à diviser par 1000.
C’est exactement ce que l’on fait avec l’opération float(TAMPON[Canal] * Coef_de_conversion). Étant donné que Coef_de_conversion vaut exactement 0.001 il n’effectue aucune transposition de valeur. Si la CAN donne 4095, l’affichage sera de 4.095V. Avec un voltmètre de précision, la tension fournie par la ligne USB mesurée est de 4,9V. L’affichage arrondi à deux chiffres après la virgule donne 4,09V. On en déduit facilement que Coef_de_conversion doit être égal au rapport : 4,9 / 4,09 = 1,198 divisé par 1000 soit 0,001198. C’est la valeur qui est suggérée dans la ligne . Vous pouvez facilement effectuer la mesure chez vous pour peaufiner ce paramètre.
Un petit dessin pour faire joli ! (SDA sur A4 et SCL sur A5.)
Toujours dans l’optique d’expérimentations ludiques, nous allons exploiter les possibilités graphiques spécifique de l’afficheur OLED utilisé. Vous avez constaté avec le démonstrateur P03 que durant quatre secondes l’écran s’agrémente de la petite salamandre, cette dernière étant mon avatar graphique pour toutes mes prestations sur l’Internet. Cette signature s’insinue partout y compris en filigrane dans les pages de textes qui manquent d’images. Ce petit dessin va vous permettre d’observer dans le listage du logiciel la façon dont on réalise une matrice graphique sur OLED. C’est assez particulier. Pour comprendre la technique, reportez-vous en page 12 et page 13 du petit livret Bibliothèque U8glib.pdf qui accompagne ce tutoriel. (Je vous conseille fortement de l’imprimer et de l’assembler en consultant le document Réaliser un 
petit livret.pdf.) La partie de loin la plus laborieuse consiste à construire la matrice d’octets qui définit la « composition ». Comme je suis très paresseux, je me suis contenté de reprendre ici un dessin figurant sur un autre projet, sauf que j’ai utilisé dans cet exemple la technique de la page 13, mais comme le dessin original était petit, la double grandeur a été appliquée pour que le petit animal occupe la majeure partie de l’écran. Du coup la définition est très grossière, car chaque pixel de l’original devient un carré de quatre points ce que la surcharge en rouge met en évidence. Du coup, montré par quelques exemples en violet sur la Fig.10 le dessin est affecté par de nombreuses « marches d’escalier » qui dégradent singulièrement le contour du sympathique batracien. Pour atténuer cette médiocrité de contours, quelques lignes colorées en jaune sur la Fig.110 ont été ajoutées à l’affichage. Une définition deux fois plus grande aurait été plus belle, les contours plus linéaires. De façon très générale, multiplier par deux toutes les dimensions d’un élément augmente sa surface par quatre. Dans notre cas j’aurais été obligé d’étudier quatre fois plus d’octets, tellement indigeste à faire que franchement le courage m’a manqué ! Ceci dit, ce petit amusement montre dans le listage de P03 comment tracer des cadres avec arrondis et des points et des lignes. Largement de quoi donner libre cours à votre imagination d’artiste …
Reprise de P02_Test_de_VREF.ino pour évaluer la rapidité d’échantillonnage.
C’est précisément la rapidité de mémorisation des échantillons qui conditionne la bande passante d’un oscilloscope. Aussi, pour évaluer la performance possible de notre réalisation, on fait à nouveau appel au démonstrateur P02_Test_de_VREF.ino que l’on doit légèrement modifier. On ouvre l’IDE avec ce programme, et en tête de listage, on transforme la ligne 36 repérée par
//@@@@@@@@@ en remarque car c’est la ligne série qui ralentit au maximum la cadence. On constate au passage que dans le résumé de la programmation méthodique on trouve le conseil :
>>> Les lignes qui doivent facilement se retrouver seront terminées par // @@@@@@@@@@.
Il est respecté dans tous mes logiciels.
Dans ce démonstrateur la fonction int Lire_valeur(byte Canal) a été optimisée, en rapidité on ne peut pas faire mieux. La boucle de base simule l’échantillonnage d’un tampon de 1024 échantillons. Cette zone mémoire est enregistrée à la cadence maximale possible. On branche un fréquencemètre précis sur la sortie D13. Dans ces conditions la fréquence mesurée est de 2582 échantillons par seconde. Pour en faire un oscilloscope, c’est dramatiquement bas.
Changement de stratégie.
Face à ce constat décevant, Il nous faut impérativement changer d’approche, et ce d’autant plus que la performance de 12 BITs est complètement dégradée puisqu’en vertical sur notre petit oscilloscope expérimental on dispose au maximum que de 64 PIXELs. C’est à dire que la finesse de 4093 est divisée par 64 pour satisfaire cette limitation. Du coup les CAN d’Arduino peuvent facilement faire le travail. On économise ainsi l’achat du MCP3208, l’appareil sera plus compact et les circuits imprimés largement plus simples. C’est la raison pour laquelle en bas de la page 2 est précisé :
La suite est ici. 
