L’invention des structures moléculaires désignées par le vocable « cristaux liquides » constitue une révolution dans le domaine de l’affichage, au moins aussi importante que celle de l’électroluminescence. Et pourtant, aux yeux du grand public cette découverte capitale est passée totalement inaperçue, un peu comme si c’était aussi élémentaire que de découvrir l’eau chaude !
En revanche, ce silence médiatique a été largement compensé par une infinité d’applications générant une profusion de produits commerciaux de toutes tailles et de formats infiniment variés. Il n’est pas question dans ce document d’effectuer une synthèse exhaustive sur le sujet, nous allons nous limiter aux plus populaires de ces composants :
Les afficheurs alphanumériques au format de deux lignes sur lesquelles on peut écrire seize caractères. Le terme écrire est volontaire, pour souligner le fait que nous n’aborderons pas ici les afficheurs graphiques, polychromes ou tactiles. L’approche la plus technique consisterait à se procurer la documentation relative au composant utilisé, à en étudier dans le détail toutes les informations, puis effectuer des liaisons filaires respectant la notice d’application, et enfin à générer sur les sorties binaires du microcontrôleur les signaux valides correspondant aux consignes désirées. C’est parfaitement faisable, rien de démentiel en la matière. Mais comme tout composant omniprésent dans le monde des micros automatismes, ces afficheurs ont donné lieu à des bibliothèques de programmes dédiées qui nous fournissent des fonctions bien adaptées et très commodes à mettre en œuvre. Il serait stupide de vouloir redécouvrir le monde, surtout dans le cadre d’un loisir. Nous allons donc aller directement au but. (On trouve souvent le mot « library ».)
Une bibliothèque de programme est un ensemble de procédures et de fonctions écrites en langage C et que l’on amène dans notre logiciel pour pouvoir en bénéficier à convenance. En réalité, la « librairy » est écrite en C, mais on se contente de la déclarer par une directive de type #include <NomBibliothèque.h>. Le compilateur sur cette information amène en mémoire de programme le code objet des fonctions spécifique et « note » les adresses des procédures en relation avec leurs identificateurs. Ce protocole évite de surcharger inutilement notre listage SOURCE qui ne contiendra que ce que nous produisons. On y gagne singulièrement en clarté. Naturellement chacun peut se créer une bibliothèque, mais vu tout ce qui existe actuellement sur Internet il est peu probable que nous y trouvions avantage. Lorsque la bibliothèque est écrite, il faut la placer dans un dossier dédié et la « présenter » à l’IDE pour qu’il en prenne acte et sache où la trouver. Pour les afficheurs à cristaux liquides qui nous concernent, il existe plusieurs « librairy » en ligne, mais nous allons utiliser LiquidCrystal.h qui est native dans l’IDE. D’une part nous n’avons rien à aller chercher sur Internet, d’autres part comme cette bibliothèque fait partie intégrante de l’IDE il n’y a pas à la lui « présenter », on peut utiliser directement ses MÉTHODES. (Méthode est le terme utilisé dans l’IDE pour désigner une procédure ou une fonction incluse dans une librairy.) En réalité, le système de développement de programmes pour l’ATmega dispose par défaut d’une variété étonnante de bibliothèques gérant les domaines les plus empruntés de la programmation de petits automatismes.
(Moteurs CC ou pas à pas, ligne série, usage de l’EEPROM, servomoteurs, afficheurs en tous genres …)
FAISONS CONNAISSANCE AVEC LiquidCrystal.h :
Parcourant la page précédente, nous avons cerné la logique des bibliothèques spécialisées dans l’utilisation d’un périphérique particulier. Nous avons appris qu’une fois la « librairy » soumise à l’IDE, il suffit de la déclarer par une directive en tête de programme pour pouvoir en utiliser à convenance les fonctions et 
les procédures. Pour expérimenter les fondamentaux de la mise en œuvre d’un afficheur LCD, chargeons P02_Version_LCD_vide.ino qui nous fournit un noyau de base pour développer des applications intégrant ce type de visualisation.
L’organigramme de la Fig.7 décrit l’architecture de ce petit programme et va nous permettre d’analyser en détail les instructions particulières et ce que fait le logiciel quand il les rencontre. On peut noter au passage que cette trame se retrouve plus ou moins dans tous les croquis. En tout premier, on trouve les directives qui, mis à part les inclusions de bibliothèques ne génèrent pas de code mais informent le compilateur de la valeur de certains éléments.
En (1) on demande d’inclure les fonctions de la bibliothèque LiquidCrystal.h. Naturellement on pourrait en invoquer plusieurs. En (2) on trouve l’instruction LiquidCrystal lcd(2, 3, 4, 6, 7, 8, 9) qui « construit » l’entité que nous identifions par lcd. Pour comprendre cette instruction, je vous invite fortement à prendre en main la fiche nommée Méthodes de la bibliothèque LiquidCrystal.h et vous en déduirez que dans la suite, lcd représentera un afficheur à cristaux liquides dont les E/S sont listées dans un ordre strict.
Comme il n’y a que sept valeurs on en déduit que l’afficheur sera piloté sur quatre fils de données. C’est la fonction de LiquidCrystal.h qui va automatiquement conditionner D2, D3… D8 et D9 en entrée ou en sortie. (Quatre fils de données et trois fils de contrôle.)
Puis, en (3) des déclarations classiques comme un nombre d’options, le nombre de mesures etc. En (4) on définit les matrices de nos petits dessins binaires. Le chapitre ci-dessous « UTILISATION DES CARACTÈRES PERSONNALISÉS » vous explique le principe de génération des caractères personnalisés. On ne fait à ce stade que préciser où seront les « noirs » et les « blanc ». Mais ces informations binaires ne sont pas encore dans l’afficheur. Notez que ces définitions doivent se trouver avant void setup(). Puis dans la séquence d’initialisations on trouve en (5) les classiques configurations d’E/S qui conditionnent les broches du microcontrôleur par exemple.
Avec en (6) l’instruction lcd.begin(16,2) qui doit précéder toute autre action on déclare que l’instance de type afficheur LCD que nous avons nommé lcd présente une matrice de caractères organisée en deux lignes de 16 caractères chacune. Ainsi les procédures de LiquidCrystal.h seront capables de gérer correctement le « curseur d’écriture ». Au passage on se rappelle que le mot matrice désigne une sorte de grille comportant des cases organisées en lignes et colonnes, peu importe ce que l’on place ensuite dans ces cases. On peut y mettre une couleur uniforme, la matrice devenant un dessin dont chaque case est un pixel. Un « mots croisés » est une matrice, un jeu d’échec aussi.
Toujours dans la séquence des initialisations « au sommet », on en arrive en (7) à la concrétisation « électrique » des caractères spéciaux définis en (4). C’est par l’instruction lcd.createChar(1,G) que l’on fait passer dans la mémoire RAM de l’afficheur les « 0 » et les « 1 » qui indiqueront quels sont les points à allumer ou à éteindre, le processus étant détaillé dans le chapitre suivant. Comme on peut déclarer beaucoup plus de caractères spéciaux que ne peuvent en contenir les huit emplacements RAM de l’afficheur, en relation avec les fonctions actives du MENU, les séquences de programme seront associées à des groupements propres. Comme il faudra « transporter » ces « paquets » régulièrement au cours du programme, leur génération est placée dans des procédures.
Enfin, en (8) on trouve un habituel affichage qui en début de tout logiciel présente le « produit » et sa version. Cette phase est montrée sur la Fig.6 avec un petit « bug » volontaire. À la place du mot Logiciel on a écrit le mot Loggciel. Si vous observez attentivement, vous constaterez que les deux « g » n’ont pas la même morphologie. Celui de gauche présente une taille plus homogène à celle des autres caractères, alors que celui de droite est étriqué.
Concrètement, plusieurs caractères d’origine présentent ce coté peu esthétique. Par exemple le « p », le « q » font partie de cette classe d’éléments pas très beaux. Par ailleurs les accentués n’existent pas. Enfin, on peut vouloir utiliser des petits dessins particuliers comme le caractère Ω qui sert d’exemple dans l’encadré. Pour résoudre toutes ces contraintes d’ordre purement esthétique, chacun peut se créer jusqu’à huit matrices propres simultanées. Dans la suite cette faculté sera mise à contribution à profusion… dans les limites admissibles pour la taille du programme complet on s’en doute. Sans cette possibilité, le voltmètre analogique « à ruban » ne serait pas envisageable.
UTILISATION DES CARACTÈRES PERSONNALISÉS.
Caractère dans ce titre n’est pas le mot le plus approprié, il serait bien plus pertinent d’utiliser le vocable GRAPHIQUES personnalisés. En effet, si l’on observe les textes visualisés sur ce type d’afficheur, on constate qu’ils sont constitués de « pixels ». Ce sont donc de petites images constitués de « damiers » organisés en huit lignes et cinq colonnes. On peut en allumant ou non chaque point élémentaire dessiner ce que l’on veut. Autrement dit, nous croyons que l’afficheur nous présente du texte, mais en réalité il se contente de mettre bout à bout seize dessins sur une ligne et seize sur l’autre. C’est le fournisseur qui a inclus une kyrielle de petits dessins qui pour nous sont des lettres, des chiffres et de la ponctuation.
Pour bien comprendre la philosophie relative à ce chapitre, nous allons raisonner sur un caractère personnalisé qui nous sera très utile pour la fonction ohmmètre incluse dans les possibilités de l’appareil de mesures : « Ω ».
Première étape : Prendre la fiche nommée Créer des caractères personnalisés pour un LCD et la conserver bien en vue pour comparer ces explications avec la syntaxe des Méthodes.
Deuxième étape : Concevoir l’image et la « transformer en binaire ». (Voir la Fig.8)
* 1) Imaginer le petit dessin que l’on veut afficher dans la matrice 8 x 5.
* 2) Remplacer les « allumés » par des « 1 » et les « éteints » par des « 0 ».
* 3) L’ordinateur ne manipulant que des OCTETS compléter par trois « 0 » en tête.
* 4) Avec un B en début on précise que l’octet sera exprimé en binaire, mais si on ne précise pas avec B le compilateur par défaut prendra
x l’information en décimal. En 4 on effectue le calcul pour transposer en décimal et en 5 on note le résultat.
Troisième étape : Déclarer la matrice au compilateur.
Cette directive doit être placée avant la séquence d’initialisations void setup() : byte ohm[8] = {0,0,14,17,17,10,27,0}; .
Vous constatez que nous commençons par préciser au compilateur que ce que nous nommons ohm est un tableau de huit éléments de type byte. Puis entre accolades on liste les huit valeurs qui par défaut sont ici données en décimal car non précédées de « B« .
Quatrième étape : Chaque fois que nous en aurons besoin, pour pouvoir utiliser un caractère spécial il faut qu’il soit résidant dans la mémoire RAM de l’afficheur qui comporte huit « matrices » disponibles. (Voir la Fig.9) lcd.createChar(5,ohm);
Avec cette instruction LiquidCrystal.h recopie dans l’emplacement n°5 la matrice binaire déclarée par l’identificateur ohm dans l’instance de l’afficheur identifié par lcd.
Dernière étape : À tout moment on peut faire afficher ce caractère spécial avec lcd.write(5); que l’on peut traduire par : Afficher sur lcd à l’endroit actuel du curseur sa matrice RAM n°5.
Adaptation du programme au SHIELD LCD.
Mobiliser un KIT fréquencemètre et son bloc alimentation secteur constitue une « version de luxe », tous n’auront pas forcément le budget nécessaire. D’un autre coté, nombreux d’entre vous sont ceux qui disposent déjà d’un Arduino et d’un SHIELD LCD. Alors envisager de transformer ces deux compères en un laboratoire avec quelques résistances et autres LED sera très séduisant. Bien moins commode certes, mais si peu coûteux. Pour vous permettre cette opportunité nos études seront complétées par les informations d’adaptation indispensables pour vous amener à bon port. (Les programmes version SHIELD LCD sont fournis dans un dossier à part) Tout ne sera pas forcément possible, mais une bonne majorité des fonctions seront réalisables. Si vous consultez le tableau des affectations des E/S donné en début de ce paragraphe vous constaterez immédiatement que D13 pilote le rétro éclairage. Il faut donc neutraliser tout ce qui concernait la LED verte. Cette perte n’a cependant rien de dramatique.
Plus conséquent, D5 pilote maintenant DB5, du coup tout ce qui permettait de faire du comptage avec TIMER1 ne sera plus possible. On perd donc fréquencemètre, périodemètre et impulsiomètre.
C’est assez frustrant, mais d’un autre côté on conserve pratiquement toutes les autres mesures électriques et les diverses générations de signaux. Au final, pas mal de possibilités sont conservées, le tout pour un investissement financier relativement dérisoire. Nous voilà consolés.
RÉSUMÉ pour les particularités relatives à l’option SHIELD LCD :
• Pour des raisons de protection du matériel on vous impose de couper une broche sur le module de visualisation et d’ajouter une diode « anti retour ».
• Un dossier <! Programmes pour la version SHIELD> contiendra les programmes pour la version Arduino + SHIELD. (Le « ! » a pour but de faire passer le
x dossier en tête de liste par l’explorateur.)
• Les particularités de programmation seront abordées le moment opportun au cours de nos expériences, et en particulier l’adaptation pour utiliser les
x boutons poussoir déjà présents.
