Affichage efficace de texte / graphiques simples sur LCD couleur par ARM

12

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.

supercat
la source
1
Ce n'est pas une réponse, car vos exigences incluent le fait de ne pas être lié à un fournisseur ARM spécifique, mais la famille de microcontrôleurs LPC LH754xx comprend un pilote LCD intégré.
Kevin Vermeer
@reemrevnivek: Il existe un certain nombre de puces ARM avec de petits pilotes LCD; Je ne peux imaginer aucune puce ayant un pilote adapté à tout affichage graphique de taille utile apparaissant dans un package qui serait utilisable dans autre chose qu'un scénario de puce sur verre. Une puce peut avoir un contrôleur, mais un écran LCD avec un contrôleur puce sur verre semble plus économe en énergie et plus facile à utiliser. Je vais vérifier la puce que vous avez mentionnée, cependant - cela pourrait être intéressant.
supercat
@supercat - Je pense aux écrans LCD qui ont une interface RVB: horloge pixel, synchronisation de trame et lignes de contrôle de synchronisation de ligne, avec un bus de données pixel parallèle. Envisagez-vous d'utiliser un écran contrôlé par COG?
Kevin Vermeer
1
@reemrevnivek: C'est ce que je pensais. Ils semblent être assez courants, car ils sont utilisés dans de nombreux appareils portables alimentés par batterie comme les téléphones portables. Un écran COG avec contrôleur intégré sera beaucoup plus économe en énergie qu'un écran qui nécessite des données RVB à horloge continue.
supercat
@reemrevnivek: Je viens de mettre à jour ma question avec plus de détails.
supercat

Réponses:

7

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:

Mémoire tampon et registres MCU à RAM, puis interface LCD

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):

  • Feuille d'encre Epson S1D13521B01 E (1 module)
  • Epson S1D13700 (11 modules)
  • Compatible Epson SED1520 (8 modules)
  • Compatible Himax HX8345 (1 module)
  • Compatible ILITek ILI9325 (3 modules)
  • Compatible KS0107 / KS0108 (26 modules)
  • Novatek NT7534 (14 modules)
  • Orise Technology OTM2201A (1 module)
  • Orise Technology SPFD5420A (1 module)
  • RAiO RA8835 (1 module)
  • Sanyo LC7981 (13 modules)
  • Sino Wealth SH1101A (2 modules)
  • Sitronix ST7920 (29 modules)
  • Solomon SSD1303 (1 module)
  • Solomon SSD1305 (9 modules)
  • Solomon SSD1325 (2 modules)
  • Solomon SSD1332 (1 module)
  • Solomon SSD2119 (2 modules)
  • ST STV8105 (1 module)
  • Toshiba T6963 (23 modules)
Kevin Vermeer
la source
@reemrevnivek: J'avais pensé aux LCD couleur avec des contrôleurs intégrés. Ils semblent assez courants, mais ceux que j'ai vus semblent généralement s'attendre à ce que le processeur horloge en plusieurs bits par pixel, même si un scénario d'affichage courant est l'affichage de texte en couleur unie. J'ai implémenté un contrôleur LCD à 4 niveaux de gris basé sur DMA en utilisant une fois un CPLD, et cela a très bien fonctionné, mais c'était un appareil alimenté par ligne.
supercat
1
@supercat - Très peu de contrôleurs LCD s'attendent à ce qu'un processeur synchronise plusieurs bits par pixel pour chaque image. Ils s'attendent généralement à ce que du matériel graphique dédié le fasse. Fondamentalement, une fois que vous obtenez des écrans RVB assez grands (c.-à-d.> 128 * 128), la puissance de traitement requise pour générer l'image pour l'écran est suffisamment grande pour qu'un GPU dédié (même s'il est intégré au MCU) soit à peu près toujours présent.
Connor Wolf
1
@supercat - Mais ce que vous décrivez, un CPLD spécialisé qui effectue des conversions ASCII en raster, est essentiellement du matériel graphique spécialisé (personnalisé) . Je dis essentiellement de ne pas réinventer la roue, et il est probablement plus facile et plus rentable d'acheter simplement un microcontrôleur avec une interface vidéo intégrée, puis d'en concevoir un vous-même.
Connor Wolf
1
Quoi qu'il en soit, si vous voulez vraiment rouler vous-même, je dirais utiliser quelques circuits intégrés SRAM à double port, et utiliser un port pour la sortie sur l'écran LCD et l'autre pour le MCU. Cela permet au MCU de modifier le contenu de la mémoire à la vitesse qu'il souhaite, et l'écran LCD peut fonctionner à sa fréquence de rafraîchissement.
Connor Wolf
1
@Fake Name: Ce ne serait pas une conversion ASCII en raster. Il s'agirait essentiellement d'une conversion bit par pixel en multibits par pixel. Je pense que vous comprenez mal ce que je regarde. Je ne recherche pas des affichages qui n'ont que des pilotes , mais ceux qui incluent des pilotes et des contrôleurs , donc ils n'ont besoin d'être alimentés que lorsque les choses à l'écran changent.
supercat