Lors de la conception d'un appareil ARM qui devrait afficher des graphiques simples sur un écran LCD couleur, comment mieux concevoir les choses pour permettre des mises à jour rapides, de préférence sans être lié à un fournisseur ARM ou LCD particulier? Mon projet actuel utilise un écran noir et blanc qui peut être piloté à la vitesse de l'éclair par un port SPI sur un PIC (redessiner un écran complexe en 1/60 seconde). Il semble que les écrans LCD couleur courants aient un port SPI, mais même remplir un écran LCD 160x120 avec une couleur unie prendrait 30 ms, et un 320x240 prendrait 120 ms dans le meilleur des cas (horloge de décalage de 10 MHz).
Si l'on pouvait épargner les broches du contrôleur, le mode parallèle pourrait être meilleur, mais je ne connais aucun moyen indépendant de la famille de connecter l'interface parallèle sans nécessiter trois instructions de stockage en mémoire distinctes pour chaque pixel (une pour définir les données, un pour régler la sortie d'horloge à un niveau élevé et un pour le régler à un niveau bas). Certaines puces ARM ont des interfaces de bus de mémoire, mais celles-ci veulent souvent faire des choses comme des adresses et des données multiplex, ou consacrer beaucoup de broches à la sortie de bits d'adresse non pertinents (l'écran LCD n'a besoin que d'un bit d'adresse).
En regardant l'ILI9320 d'ILITEK ou le HD66789 de Renesas, une approche qui semblerait intéressante serait d'utiliser un CPLD pour convertir le SPI en données parallèles et d'inclure un mode qui produirait un pixel par bit. En regardant la feuille de données Renesas, il pourrait être possible d'obtenir des écritures pixel par bit avec un minimum de matériel (aucun CPLD requis) en faisant en sorte que tous les bits de données du port parallèle suivent la broche de données série, en utilisant le mode série pour tout sauf pixel écrit et en utilisant les fonctions de comparaison / masque de sorte que soit les pixels à zéro soient transparents et les pixels à un définissent les bits sélectionnés dans GRAM, soit les pixels à un soient transparents et les pixels à zéro effacent les bits sélectionnés. La section "caractéristiques" de la fiche technique IKITEK suggère qu'il a des fonctionnalités similaires, mais les cartes de registre ne
En supposant que le code affichera principalement du texte et des graphiques en couleur unie, l'approche idéale semble être d'utiliser un CPLD pour interfacer le port SPI de l'ARM au port parallèle de l'écran et permettre au CPLD d'être chargé avec des couleurs de premier plan / d'arrière-plan. Ce serait particulièrement agréable si l'on avait un moyen d'écrire des pixels "transparents". Étant donné une police sous forme de bitmap bicolore, on pourrait simplement charger les données de police directement dans le port SPI; cela permettrait d'afficher les données de police à raison d'un pixel toutes les deux horloges ARM. D'un autre côté, un CPLD suffisant pour gérer une telle tâche de contrôle d'affichage coûterait environ 2 $.
Quelle est la meilleure façon d'interfacer un ARM avec un écran LCD couleur, si l'objectif est principalement d'afficher du texte en couleur unie ou des graphiques simples (par exemple 16 ou 64 couleurs)?
Éditer
J'ai réalisé de nombreux projets d'affichage LCD, avec de nombreux types d'écrans LCD, y compris des écrans LCD en mode caractère, des segments multiplexés 3: 1 personnalisés en utilisant ma propre méthode de commande, des écrans LCD graphiques noir et blanc avec des contrôleurs intégrés et des écrans noir et blanc. -écrans LCD blancs pour lesquels j'ai conçu mon propre contrôleur basé sur CPLD pour interfacer avec le DMA universel d'un microcontrôleur (fournissant même des niveaux de gris à quatre niveaux). Je suis fier de faire des affichages zippés. L'un des contrôleurs graphiques était un peu un chien qui nécessitait environ 1/10 seconde pour une actualisation en plein écran même lors de l'écriture de données constantes, mais la plupart de mes affichages peuvent rendre même une image assez complexe en moins de 1/50 seconde.
Beaucoup de projets que je fais sont alimentés par batterie, donc le tirage actuel est un problème. Le contrôleur d'affichage basé sur DMA que j'ai fait fonctionnait bien, mais c'était pour un projet alimenté par ligne. Je crois que la seule façon d'obtenir une consommation de courant raisonnable à partir d'un écran LCD graphique est d'utiliser un contrôleur qui combine le tampon d'affichage et les pilotes de colonne. L'envoi de beaucoup d'affichage entre les puces de chaque image gaspillerait beaucoup d'énergie même sur un seul affichage bit par pixel; sur un écran couleur à seize bits par pixel, ce serait bien pire.
J'ai seulement commencé à regarder les feuilles de données LCD couleur; de nombreux écrans semblent utiliser un contrôleur similaire à l'ILITEK ILI9320, bien que toutes les fiches techniques que j'ai trouvées pour les contrôleurs basés sur cette conception générale aient été marquées "préliminaires". Certains comme ILITEK prétendent avoir des fonctionnalités de masquage et de transparence mais ne répertorient aucun registre pour eux; Je ne sais pas si les puces réelles ont de telles fonctionnalités mais les fiches techniques "préliminaires" ont négligé de les inclure, ou si elles ont omis les fonctionnalités mais ont oublié de les mentionner. Si en pratique toutes ces puces ont des caractéristiques de transparence, il semblerait raisonnable de les concevoir; sinon, non.
Je m'attendrais à ce que pour la plupart des projets, un écran typique se compose de texte placé arbitrairement dans un nombre modéré de polices de couleur unie de taille arbitraire. Les polices seraient très probablement stockées sous forme de données bit par pixel. En utilisant un Cortex-M3, si je voulais écrire l'affichage avec des données parallèles, la "boucle interne" du code pour écrire deux pixels finirait probablement par quelque chose comme:
rol r0, r0, # 2; Obtenez un bit en C, l'autre en N itcs strhcs r1, [r3, # DATA_OFS]; Écrire des données strhcc r2, [r3, # DATA_OFS]; Écrire des données strb r4, [r3, # CLOCK_SET_OFS]; Réglez l'horloge à un niveau élevé strb r4, [r3, # CLOCK_CLR_OFS]; Régler l'horloge à un niveau bas itmi strhmi r1, [r3, # DATA_OFS]; Écrire des données strhpl r2, [r3, # DATA_OFS]; Écrire des données strb r4, [r3, # CLOCK_SET_OFS]; Réglez l'horloge à un niveau élevé strb r4, [r3, # CLOCK_CLR_OFS]; Régler l'horloge à un niveau bas
Pas exactement la chose la plus rapide au monde. L'élimination des écritures dans les instructions de réglage / effacement de l'horloge serait utile. Je suppose qu'il n'y a pas de méthode indépendante de l'architecture pour éliminer les deux écritures d'horloge, mais il peut y avoir une méthode assez courante qui permettrait d'en éliminer une (par exemple, de nombreuses puces peuvent avoir un compteur / PWM qui pourrait être fait pour impulser une sortie brièvement en réponse à une seule opération de stockage en mémoire).
L'utilisation du port SPI et l'ajout de matériel pour cadencer un pixel par bit accéléreraient considérablement l'accès à l'affichage. Si vous utilisez un affichage sans masquage ni transparence, le CPLD devrait inclure un compteur d'adresses, et pour chaque pixel, horloge un mot de données de pixels ou bien une commande set-address pour la position du pixel suivant (pour laquelle il aurait besoin d'un compteur ). En revanche, si un affichage avait du masquage et de la transparence, tout ce que j'aurais à faire serait de faire en sorte que le CPLD prenne en charge un mode où, après avoir cadencé en 16 bits, chaque bit supplémentaire synchroniserait un mot de données vers l'affichage avec le LSB suit la broche SDI (il n'est peut-être même pas nécessaire d'utiliser un CPLD - juste quelques puces logiques normales). Je définirais la couleur de transparence sur la couleur que je veux écrire mais avec le LSB inversé.
Je ne veux pas proposer un beau design qui repose sur le masquage et la transparence, puis découvrir que les seuls écrans avec de telles fonctionnalités ont un délai de 30 semaines. D'un autre côté, si de tels écrans sont susceptibles d'être et de rester largement disponibles auprès de nombreux fournisseurs, je ne veux pas laisser la paranoïa sur la disponibilité me pousser à utiliser un design inférieur.
Réponses:
Le problème avec l'utilisation d'un microcontrôleur pour piloter un LCD est qu'un LCD nécessite une attention constante. Cela peut être atténué avec un CPLD piloté sur SPI (en utilisant DMA, bien sûr), mais vous rencontrez ensuite l'autre problème: les écrans LCD couleur nécessitent beaucoupdes données. 320x240 en noir et blanc est marginal à 9,6 Ko, mais faites-le en couleur 24 bits et soudain, vous devez fournir 230 Ko de données en 1 / 60e de seconde. (N'oubliez pas, cependant, que vous pouvez obtenir un contrôle 4 bits, 16 couleurs simplement en liant les 20 bits les plus faibles à un paramètre). Un tampon de trame 24 bits ne tient plus dans la RAM intégrée sur la plupart des microcontrôleurs, et vous n'avez probablement pas le temps de lire à partir d'une puce de RAM externe, de synchroniser les données et de faire d'autres traitements. Essayer de le faire avec un CPLD (ou un FPGA) et une puce RAM vous fait bien dépasser le prix de 2 $ qui vous a fait reculer dans votre question.
La solution traditionnelle pour interfacer un microcontrôleur avec un écran LCD couleur est un contrôleur d'affichage comme un SSD1963. Voici un schéma fonctionnel très simple:
Entrée parallèle dans un grand tampon de trame RAM (traduction: plus de 2 $) interfacé avec une interface LCD parallèle configurable en registre. L'entrée parallèle est généralement compatible avec une interface de bus mémoire.
Le marché des écrans LCD couleur n'est pas toujours facile à trouver sur le Web, étant généralement le domaine des OEM uniquement, le reste achetant des écrans auprès d'entreprises qui intègrent le contrôleur à l'écran. La meilleure ressource que j'ai trouvée a été Crystal Fontz, en particulier cette page sur le choix des écrans LCD graphiques . Faites défiler vers le bas pour les contrôleurs, qui incluent les options suivantes (remarque: tous ne sont pas des contrôleurs de couleur):
la source