Les écrans LCD alphanumériques présentent une solution facile d’emploi et bon marché de doter votre projet d’une interface indépendante de votre PC. Nous allons voir dans cet article comment se présentent ces écrans. Nous ne parlerons que des ecrans supportés par les bibliothèques Arduino, c’est à dire ceux dont le composant de pilotage est un Hitachi HD44780 ou compatible.
Les écrans LCD alphanumériques
.
Par :
DIFFICULTÉ :★☆☆
Vu de l’extérieur, les écrans LCD alphanumériques sont essentiellement caractérisés par leur taille. Deux modèles se rencontrent très fréquemment et sont les meilleurs marché, celui ayant 2 lignes et 16 colonnes d’affichage et celui ayant 4 lignes et 20 colonnes d’affichage. Voici, ci-dessous, ces deux modèles :
- Ecrans LCD alphanumériques
- Les deux types de LCD que vous rencontrerez le plus souvent. En haut le modèle 20 colonnes et 4 lignes et en bas le modèle 16 colonnes et 2 lignes. Comme on peut le voir, le marquage des broches n’est pas systématique. Le grand modèle se trouve aux alentours de 5€ et le petit à 2€.
Le connecteur du LCD
Ces deux écrans ont exactement la même connectique, c’est à dire un connecteur 16 broches situé en haut et à gauche de l’écran. Ce connecteur véhicule plusieurs signaux dont une partie forme un bus de communication parallèle 4 ou 8 bits selon la configuration choisie ainsi que les signaux permettant de contrôler la communication entre l’Arduino et l’écran. La figure ci-dessous donne la nomenclature des broches de ce connecteur.
Ces broches ont le rôle suivant :
| Numéro | Nom | Rôle |
|---|---|---|
| 1 | GND | Masse 0V |
| 2 | VDD | Alimentation +5V |
| 3 | VE | Tension de réglage du contraste |
| 4 | RS | Sélection du registre donnée ou commande |
| 5 | RW | Lecture ou écriture |
| 6 | EN | Activation pour un transfert (enable) |
| 7 | DB0 | Bit 0 de la donnée/commande |
| 8 | DB1 | Bit 1 de la donnée/commande |
| 9 | DB2 | Bit 2 de la donnée/commande |
| 10 | DB3 | Bit 3 de la donnée/commande |
| 11 | DB4 | Bit 4 de la donnée/commande |
| 12 | DB5 | Bit 5 de la donnée/commande |
| 13 | DB6 | Bit 6 de la donnée/commande |
| 14 | DB7 | Bit 7 de la donnée/commande |
| 15 | LED+ | Anode (+) du rétro-éclairage |
| 16 | LED- | Cathode (-) du rétro-éclairage |
La communication avec le LCD
Nous n’allons pas entrer dans les détails du protocole de communication [1] entre l’Arduino et le LCD mais voici une présentation rapide. Le LCD peut fonctionner en mode 4 bits ou en mode 8 bits. En mode 8 bits, les octets sont transférés sur les lignes DB0 à DB7. En mode 4 bits les octets sont transférés en deux fois sur les lignes DB4 à DB7. Le LCD dispose de 3 registres internes, le registre de données permettant entre autre l’envoi des codes des caractères à afficher, le registre de commande permettant d’envoyer des commandes d’effacement de l’écran, de positionnement du curseur, etc, et le registre d’état qui permet de consulter notamment la disponibilité du LCD pour recevoir des commandes ou des données. La sélection de l’un ou l’autre de ces registres est effectuée via les états, LOW ou HIGH, des lignes RS et RW. Une fois l’état de ces deux lignes établi, EN est placé à HIGH, la donnée ou la commande est placée sur les lignes DBx puis EN est placé à LOW.
Piloter directement un LCD est donc un processus relativement compliqué. Évidemment, comme c’est très souvent le cas avec l’Arduino, il existe des bibliothèques pour ça, ce qui permet de les utiliser aisément sans avoir à plonger dans la datasheet.
La connexion avec l’Arduino
Dans la grande majorité des cas, on préfèrera une communication sur 4 bits car une communication sur 8 bits consomme 10 ou 11 broches, ce qui, hormis sur un Mega ou un Due, laisse peut de broches libres. Avec une communication 4 bits, 6 à 7 broches sont nécessaires. Le choix des broches est libre.
RW or not RW
Cette broche peut être ou ne pas être employée. Son rôle est de permettre la consultation du registre de contrôle du LCD. En consultant le registre de contrôle, on sait si le LCD est disponible pour recevoir des commandes ou des données ou si il est occupé à dessiner des caractères sur l’écran. Si cette information manque, il faudra attendre un certain temps entre deux commandes ou données afin d’être sûr que le LCD est disponible. L’envoi d’information au LCD est donc plus lent mais on économise une broche.
En mode 4 bits, les broches à connecter à l’Arduino sont donc RS, EN, DB4, DB5, DB6 et DB7 ainsi que, de façon optionnelle, RW.
Le réglage du contraste
La broche VE permet de régler le contraste. Il est nécessaire d’y connecter un potentiomètre de réglage, un 10kΩ par exemple, dont les broches externes sont connectées à l’alimentation (+5V) et à la masse (GND) et la broche centrale à VE. Il suffit ensuite de tourner ce potentiomètre dans tous les sens avec patience jusqu’à ce que le contraste soit correctement réglé.
- Potentiomètre de réglage vertical.
- Le réglage s’effectue au moyen d’un tournevis. Il existe également des modèles horizontaux.
Le rétro-éclairage
Le rétro-éclairage est assuré par des DEL. Il faut donc limiter le courant avec une résistance en série sur LED+ ou LED-. Sur certains modèles de module LCD, cette résistance est présente, sur d’autres elle ne l’est pas. La datasheet des LCD recommande de mettre une résistance serie d’une valeur comprise entre 50 et 100Ω. Ajouter une résistance de 56Ω en série ne nuira pas, vous aurez juste un rétro-éclairage un peu moins puissant et vous assurerez une meilleure durée de vie du rétro-éclairage.
Dans beaucoup d’exemple de câblage que vous trouverez sur Internet, cette résistance est omise. C’est une errreur à ne pas reproduire.
L’implantation montrée ci-dessous résume les différents branchements nécessaires pour piloter un LCD avec votre Arduino. Ce n’est qu’un exemple puisque n’importe quelles entrées/sorties numériques de l’Arduino peuvent être employée pour les broches RS, EN, RW, DB4, DB5, DB6 et DB7 du LCD.
- Câblage d’un écran LCD sur un Arduino Uno
- Le potentiomètre de réglage du contraste est un modèle horizontal.
Quelle bibliothèque ?
Deux bibliothèques sont disponibles pour piloter un écran LCD en connexion directe : LiquidCrystal qui fait partie des bibliothèques standards et ne gère pas la broche RW bien qu’elle propose de la connecter [2] et LiquidCrystalFast qui gère, elle, la broche RW et n’offre qu’une connexion sur 4 bits. Comme son nom l’indique la seconde est plus rapide car elle n’utilise pas de temps d’attente en aveugle.
Le pilotage via le bus I2C
Il existe également de petits modules permettant d’interfacer un écran LCD avec un bus I2C. Cette solution peut être intéressante si vous manquez désespérément de broches sur l’Arduino pour votre projet puisqu’au lieu de monopoliser 6 à 7 broches, l’écran n’en utilisera plus que 2. Evidemment, la bibliothèque pour les piloter n’est pas la même. Il en existe même plusieurs selon le circuit intégré qui fait l’interface entre l’I2C et le bus parallèle de LCD.
Toutefois, le module que l’on rencontre le plus souvent est construit autour du PCF8574P de NXP, un circuit permettant d’augmenter le nombre d’entrées sorties numériques via l’I2C. La bibliothèque correspondante est LiquidCrystal_I2C.
Les bibliothèques évoquées ici feront l’objet d’un article séparé.
[1] le lecteur intéressé pourra se référer à l’article Wikipedia du HD44780.
[2] C’est toujours vrai dans la version 1.6 mais ça pourrait évoluer dans le futur.
17 Messages
-
Les écrans LCD alphanumériques 5 mars 2015 00:39, par Jac56
Bonjour,
Article clair et rigoureux comme tous ceux de votre site.
Bravo aux auteurs.J’avais envie de vous faire part de difficultés rencontrées avec des afficheurs LCD pilotés par I2C, fonctionnellement très intéressants, mais qui se sont révélés très sensibles aux perturbations électromagnétiques inévitablement présentes sur un réseau ferroviaire miniature (alimentation des moteurs de traction par signaux rectangulaires à rapport cyclique variable [sorte de PWM, à 25Hz, dans mon cas] ou par DCC [c’est encore pire]).
L’appareil où ces difficultés se sont révélées est un montage, à base d’Arduino Uno, spécifiquement conçu pour commander des servo-moteurs miniatures de type radiocommande d’avions (utilisés pour motoriser de vieux aiguillages Jouef HO manuels des années 60). Sur le bus I2C, il y avait d’autres composants (2 expandeurs d’entrées-sorties à 16 canaux Sx1509 Sparkfun pour ’lire’ des interrupteurs, et 3 modules Adafruit de générations PWM à 16 canaux pour les servos), une sorte de TCO.
Trois modèles différents d’afficheurs LCD, de fournisseurs différents et a priori sérieux (Lextronic CLCD162-BLB, Grove Seed et DFRobot, tous 2x16 caractères, tous pilotés avec la même bibliothèque classique LiquidCrystal_I2C) ont montré des perturbations plus ou moins graves : blocage total du bus I2C pour le premier, blocage de l’afficheur (et affichage de caractères illisibles) pour les deux derniers, dès le démarrage d’une seule locomotive sur le réseau.
Une autre anomalie est apparue sur tous les afficheurs (même hors perturbation électromagnétique) : en les passant sur un scanner I2C logiciel, on s’aperçoit que plusieurs adresses I2C répondent pour un seul module ; en pratique, cela peut produire le blocage des autres modules I2C du bus par collision intempestive d’adresses (jusqu’à 31 adresses fantomes sur le premier module LCD cité (!), nettement moins pour les autres). A noter que ces dédoublements d’adresse se rencontrent parfois sur les modules I2C PWM mentionnés plus haut, mais de façon moins systématique et génante. Jamais sur les expandeurs Sx1509.
J’ai essayé divers perfectionnements :
isolement galvanique de la partie ’puissance’ par photo-transistors, blindage amélioré du bus I2C et réduction de sa longueur, suppression ou essais de diverses valeurs des résistances de pull-up pour le bus I2C, ... rien n’y fit.La seule solution a consisté à faire le raccordement direct par le mode de communication sur 4 bits que vous décrivez dans votre article : l’affichage LCD fonctionne parfaitement, et le bus I2C, avec les modules restants, n’est plus perturbé. L’ensemble du montage (équipé maintenant de 42 aiguillages) fonctionne parfaitement.
Qu’un module soit défaillant, cela peut arriver ; mais que 3 modèles différents, de constructeurs différents, présentent à des degrés plus ou moins forts, les mêmes anomalies, alors que d’autres modules I2C continuent à fonctionner convenablement sur le même bus pose question.
Peut-être y-a-t-il un composant I2C commun à tous ces afficheurs ? Le driver HD44780 ne devrait pas être en cause puisqu’il marche correctement, en direct.Qu’en pensez-vous ? Avez-vous constaté des désordres similaires ? Suis-je passé à côté d’un correctif ?
Je n’ai pas trouvé de cas similaires sur internet.Encore bravo pour votre site ; on attend vos articles avec impatience.
-
Les écrans LCD alphanumériques 5 mars 2015 08:00, par Jean-Luc
Bonjour,
merci pour vos compliments.
Curieux en effet que ce ne soit que la présence des afficheurs qui perturbait le bus. Avec seulement les afficheurs comment se comportait le système ? Est-ce lié à la charge du bus ou à sa topologie ? Les modules I2C pour LCD sont en fait des expanseurs d’E/S et il est probable que ce soit le même circuit qui soit employé sur les 3 afficheurs.
Ceci dit, je pense que le bus I2C n’est pas la meilleure solution pour construire un système distribué du fait de l’absence de détection et de correction d’erreur. La fiabilité est insuffisante. Il a été conçu pour une communication courte distance sur une carte ou dans un appareil et ce n’est pas un bus de terrain.
-
Merci pour votre réaction rapide.
Je confirme que les anomalies observées ne concernaient que les modules LCD en I2C. Hors le cas mentionné de blocage complet du bus par un des modèles de LCD, les 5 autres modules ont toujours fonctionné convenablement, même avec le LCD ’figé’. Ce qui, d’un certain point de vue, est plutôt à l’honneur du bus I2C.
Vous avez raison : au départ, j’avais en effet tenté d’utiliser le bus I2C comme ’bus de terrain’ (4 à 5 mètres de câbles hors boîtier) car on ne trouve pas facilement des informations sur les limites de fonctionnement de ce bus ; cela marchait convenablement, en l’absence toutefois de sources de perturbations électromagnétiques (courant des moteurs des locos). Finalement, ce n’était pas une bonne idée, même si elle réduisait considérablement le nombre de câbles à déployer sur le réseau ferroviaire.
Ensuite, j’ai modifié fondamentalement le système : le bus I2C est resté confiné à l’intérieur du boîtier de l’appareil (longueur cumulée de câble blindé [avec blindage à la masse à une extrémité pour chaque tronçon] de 30 cm environ + quelques 20 cm cumulés de pistes sur les divers circuits imprimés) ; j’ai aussi isolé galvaniquement les sorties des générateurs PWM des entrées de commande des servos d’utilisation qui, eux, avaient déjà une alimentation séparée ; malgré ces précautions relativement strictes, les différents modules-afficheur I2C se figeaient toujours systématiquement ! et eux seuls, puisque les 5 autres modules fonctionnent parfaitement maintenant, une fois l’afficheur sorti du bus I2C et couplé ’en direct’. Les interfaces I2C des afficheurs se révèlent vraiment particulièrement sensibles... Sur les forum de robotique, je n’ai vu la question évoquée vaguement qu’une seule fois.
Depuis, par prudence, j’ai aussi blindé les boîtiers plastiques du montage en collant de l’adhésif métallisé à l’intérieur, mais je n’ai pas refait de tests avec l’afficheur LCD en I2C ...
J’évoque aussi ces difficultés en prévision des développements qui sont annoncés sur le site.
Si l’on envisage d’utiliser le générateur DCC (utilisant la librairie CmdrArduino-master et dont la description a commencé) avec une interface homme-machine ’hard’ (par exemple, utilisant des interrupteurs pour la direction, des boutons-poussoir pour l’arrêt d’urgence ou l’éclairage, des encodeurs rotatifs pour la vitesse, etc...), tout en réservant 6 ou 7 pins pour l’afficheur en direct, et cela pour plusieurs locomotives en parallèle (8 serait un excellent chiffre pour moi), les limitations des E/S d’un Arduino Uno conduiront très vite à utiliser des expandeurs d’E/S, donc vraisemblablement un bus I2C (?).
Dans ces conditions, instruits de ces risques de perturbation par le ’courant de traction’, n’est-il pas prudent de prévoir un bon découplage entre partie logique et partie puissance du montage, c’est-à-dire,- un découplage galvanique du signal DCC (entre la pin 9 de l’Arduino et l’entrée de commande du module LMD18200),
- un bon blindage des coffrets et des boîtiers, et des alimentations séparées pour partie logique et partie ’puissance’ du montage ?
Cette éventualité présuppose aussi, bien sûr, que l’Arduino ne sera pas limité par d’autres caractéristiques (étendue de mémoire SRAM ou vitesse de traitement, par exemple) ; j’ai commencé quelques évaluations sur les contraintes ’mémoire’ et cela semble ’tenir’ en sollicitant progmem quand cela est possible (essentiellement pour la partie interface homme-machine).
Qu’en pensez-vous ?-
Bonjour,
effectivement sur une installation conséquente, le nombre d’entrée/sortie peut se révéler une limitation. Mon choix est d’utiliser plusieurs Arduino, de faire un système distribué et de dédier chaque Arduino à une fonction en le localisant à proximité des dispositifs pilotés en limitant l’usage des expandeurs d’E/S. Ainsi dans mon TCO j’ai 2 Arduinos et un PIC, l’un gère l’affichage sur un écran graphique SPI, un second gère des DEL ws2812 et le PIC un balayage IR pour un clavier matriciel tactile. Un bus CAN relie les Arduinos et le PIC entre eux et à un autre micro-contrôleur central. C’est un bus très robuste qui intègre la détection des erreurs en hardware et qui ne nécessite que très peu de logiciel pour l’utiliser. J’hésite entre un Due et une carte Olimex pour ce dernier qui fera tourner le code de gestion des cantons et les circulations automatiques. J’ai un article en préparation sur le bus CAN.
D’ailleurs pour disposer d’un espace programme et données plus conséquent et des performance plus importantes, le Due (96ko de SRAM, 512ko de flash, 84MHz) ou le Teensy 3.1 (64ko de SRAM, 256ko de flash, 96MHz) sont un bon choix. Le Due integre 2 cellules CAN et le Teensy 1.
-
-
Les écrans LCD alphanumériques 7 avril 2015 22:29, par RailyRabbit
Très intéressant, comme toujours.
J’attends avec impatience un petit billet sur le bus CAN, ça m’intéresse ! ;)-
Merci ! Pour le bus CAN, ça va venir ;-)
-
-
Les écrans LCD alphanumériques 19 avril 2015 11:25, par Christian
Bonjour,
Je suis tombé par hasard sur cette page et je me permet de vous communiquer l’info suivante : Il existe des platines permettant de connecter un LCD 16 pins en I2C en utilisant les ports I2C des platines Arduino.
http://www.sainsmart.com/sainsmart-... ou chez Adafruit:https://learn.adafruit.com/i2c-spi-...
Cela fonctionne parfaitement bien avec seulement 4 liaisons fil.
Bonne journée.Voir en ligne : Les écrans LCD alphanumériques
-
Merci beaucoup pour ces informations !
-
-
Les écrans LCD alphanumériques 18 avril 2016 16:33, par diyae
Bonjour ,
d’abord je vous remercie pour cet article et ces interventions riches en information.je vous demande est ce qu’il ya une possibilité d’afficher plusieurs écrans lcd alphanumériques à la fois en utilisant la carte Arduino , par exemple (16 aff LCD) ,
et merciVoir en ligne : Les écrans LCD alphanumériques
-
Bonjour,
oui on peut connecter plusieurs afficheurs. Les broches peuvent même être communes à l’exception de EN. Chaque afficheur supplémentaire ne prendra donc qu’un broche de plus. Ceci dit 16 LCD c’est beaucoup, il faudra 21 broches et ce n’est donc pas possible avec un Uno.
-
-
Les écrans LCD alphanumériques 1er septembre 2017 10:25, par debutante69
Bonjour.
.
A quand un sujet sur le fonctionnement de base des écrans TFT pour UNO (240x320) ou MEGA (320x480), tactile ou pas, avec SDcard ou pas ?
.
Merci pour tous les articles déjà rédigés, si rares en français et aussi facilement compréhensibles.-
Merci pour cette question, les écrans TFT, Oled, etc.. font aussi partie des projets de modélisme. Vous en trouverez déjà dans les contributions du Forum.
Mais vous avez l’air de savoir déjà qu’il en existe de nombreux modèles qui différent par leur taille, la quantite de pixels, le contrôleur associé, les accessoires (mémoire, carte SD..) et le bus de communication (I2C, SPI, port parallèle..).
Generalement après l’achat d’un écran, nous récupérons sa documentation pour les interconnexions avec l’Arduino et une ou plusieurs bibliothèques pour appeler ses fonctions (texte, graphiques, tactile ,..) dans le programme.
Le sujet est donc très vaste et sera traité au fur et à mesure des réalisations.
-
-
Les écrans LCD alphanumériques 21 décembre 2018 17:54, par Christian Michel
Bonjour, quand je lance mon programme test se trouvant dans les exemples de l’IDE Arduino, le message "hello world" s’écrit en chinois. Je ne lis pas le chinois ce que je veux dire c’est qu’il y a une espèce de traduction des lettres de l’alphabet qui se traduisent en chinois. Pourriez-vous m’expliquer comment faire pour changer le driver si c’est un problème de driver évidemment ou bien si c’est un autre problème.
Un grand merci à vous tous et bonne continuation 😉😎-
Bonjour,
De deux choses l’une, soit vos branchements ne sont pas bons et les données envoyées à l’écran mènent à des caractères qui ne sont pas les bons. En effet la ROM caractère contient des caractères occidentaux et des caractères japonais, voir http://www.martyncurrey.com/arduino.... En achetant sur eBay on a quasiment la garantie d’avoir la version anglo-saxonne + japonaise (donc pas d’accents). Soit vous avez carrément reçu un écran dont la ROM ne contient que des caractères orientaux.-
Les écrans LCD alphanumériques 24 décembre 2018 17:54, par Christian Michel
Je vous remercie ÉNORMÉMENT pour la page internet que vous m’avez communiquée. Il y a toute sorte de renseignements qui m’ont été très utile. Je n’ai pas encore fait les changements nécessaire, mais je pense que vous avez raison et que j’ai branché les 4 fils de l’arduino au 4 mauvaises entrées du LCD. J’aurais du les intervertir. Dans tous les cas, je ne vous remercie pour votre aide. Passez de bonnes fêtes de fin d’année et bonne continuation😉😎
Voir en ligne : Christian Michel
-
-
-
Les écrans LCD alphanumériques 11 avril 2020 21:34, par francis
Bonjour
Je n’arrive Pas à comprendre le fonctionnement du potentiomètre branché sur ve, alors qu’une simple résistance ou un potentiomètre utilisé en résistance variable(2 broches) pourraient suffir.
si vous avez une explication, je suis preneur.
merci -
Les écrans LCD alphanumériques 12 avril 2020 11:38, par msport
Bonjour,
on trouve au sujet de ces afficheurs l’information suivante :
les caractères sur le type d’affichage à cristaux liquides mentionné ici ne deviennent visibles que lorsque VDD-VE ≥ 5V, où VDD est la tension de fonctionnement et VE est la tension de contraste de l’écran LCD. Un calcul simple donne une valeur de sortie de VE ≈ -2V, correcte pour le bon fonctionnement de l’écran LCD.
Donc, il faut que vous révisiez vos notions d’électricité/électronique, une résistance seule ne définit pas un potentiel et c’est justement le but d’un potentiomètre. CQFD.
Cordialement.
L’article joint indique d’ailleurs comment convertir un LCD 5V en LCD 3.3VVoir en ligne : Hack Your 16×2 LCD