Afficheur graphique tactile série ou parallèle?

International Français
1

Bonjour,

Je joue avec un afficheur que j'ai acheté il y a un an ou deux qui est un afficheur graphique tactile parallèle VMA412.

Petit aparté pour ceux qui sont fan des datasheet et en leur absolue confiance, le constructeur Velleman indique pour cet afficheur a pleins de mode d'accès différents(série et parallèle), mais seule l'interface 8 bits avec série MCU 8080-I n'est possible,et que sur les deux afficheurs que j'ai, il y en a un qui a un ST77831 au lieu d'un ILI9341. Faut pas faire confiance au constructeur, il ne voit pas la différence entre le pilote et le composant fini.

De toutes façons quand j'ai cherché un afficheur, je n'ai pas vu qu'il y en avaient qui passaient le mode série. Le problème que pose un afficheur est que le nombre de broches complètement libres est quasi nul. Je m'en moque un peu car il est possible d'utiliser cet afficheur avec une carte MEGA, ou d'utiliser les mêmes broches que l'afficher pour commander autre chose, en utilisant le /CS de l'afficheur.

Pour ce genre d'afficheur, si je veux une présentation un peu correcte, il faut passer par une image qui ne tient pas dans la mémorette de l'arduino. Je stocke mon fond d'écran sur la carte SD.

Depuis que j'ai vu qu'il y avait des afficheurs série, libérant ainsi des broches, je me pose quelques questions quand à la vitesse d'affichage, notamment pour les images.

Sachant qu'avec mon afficheur parallèle, je mets entre 6 et 8 secondes pour afficher ou sauvegarder une image, je me dis que si je passe en communication série pour l'afficheur cela va être pire (pas pour la SD qui passe déjà par le mode série.

Y en a-t-il qui utilise l'affichage d'image avec un afficheur 240x320 série (peu importe qu'il soit tactile ou non) et combien de temps cela prend-il pour afficher une image?

Toujours en parallèle, je perds environ 1 seconde avec un méga en enfichant directement la carte (le port 8 bit de l'afficheur est branché sur 3 ports différents de l'arduino, et je gagne 1 seconde si je câble les 8 bits de données de l'afficheur directement sur le port K.

2

il y a des raisons pour que les ports parallèles soient de plus en plus abandonnés en faveur de liaisons séries (USB, SATA, I2C ... par exemple).

La synchro nécessaire sur les fils, les perturbations électromagnétiques à haute fréquence entre fils (cross talk), la distance de transport possible (impact de la longueur des fils sur les temps de propagation), nécessité de synchroniser les bits pour reformer l'octet, et bien sûr le prix du cuivre (2 fils c'est plus de 4 fois moins cher que 8) etc... font qu'au final on monte mieux en débit global en série.

Cela dit-il n'y a pas de magie...

320x240 pixels = 76800 pixels. à raison de 3 octets par pixels on doit transférer 76800*3=230400 octets pour remplir l'écran avec une image (un peu plus pour le header).

--> à 500,000 bauds et 10 bits par octets on transmets 50,000 octets par seconde donc il faudra presque 5 secondes pour envoyer l'image. Bien sûr l'image ne tenant sans doute pas en SRAM il faut la lire depuis un support et donc ce sera plus lent car il faut lire d'un côté puis envoyer de l'autre...

la compression d'image sur ordinateurs aide, mais décoder un JPEG sera lent et nécessite bcp de mémoire ce qui est un souci sur un petit Arduino genre UNO ou MEGA

3

La synchro nécessaire sur les fils, les perturbations électromagnétiques à haute fréquence entre fils (cross talk), la distance de transport possible (impact de la longueur des fils sur les temps de propagation), nécessité de synchroniser les bits pour reformer l'octet, et bien sûr le prix du cuivre (2 fils c'est plus de 4 fois moins cher que 8) etc... font qu'au final on monte mieux en débit global en série.

Dans le cas d'un afficheur graphique, soit dans le cas ou il s'enfiche directement sur la carte micro, soit dans le cas ou j'ai un circuit imprimé global contenant le micro, l'afficheur, les drivers pour mes moteurs, les MOSFET pour mes circuits tout ou rien..., que je passe en série ou en parallèle ne change rien. Je suis d'accord si mon afficheur devait être loin, mais là il est à moins de 2cm.

la compression d'image sur ordinateurs aide, mais décoder un JPEG sera lent et nécessite bcp de mémoire ce qui est un souci sur un petit Arduino genre UNO ou MEGA

Le format compressé n'a pour moi aucun intérêt, car il augmente la taille du code, le temps de traitement. La seule chose sur laquelle on peut gagner est la taille de l'image sur la carte SD. Mais pour avoir une image de fond sur une 8Mo minimum, ce n'est pas vraiment un soucis. Si le décodage se faisait dans l'écran, je ne dis pas, mais comme il doit être fait avant le passage écran-arduino!

320x240 pixels = 76800 pixels. à raison de 3 octets par pixels on doit transférer 76800*3=230400 octets pour remplir l'écran avec une image (un peu plus pour le header).

Sachant que j'utilise pour l'instant le mode 16 bits de couleur, 2 octets par pixels suffisent. Mais pour transférer les octets:
A) soit on donne pour chaque pixel, son adresse puis sa couleur,
B) soit on donne l'adresse de départ et la suite d'octets

Si j'opte pour la solution A), c'est environ 5 octets pour l'adresse et 2 ou 3 octets pour la couleur, ce qui à 500,000 bauds ferait 20 secondes.
Si j'opte pour la solution B), il faut que je dispose des octets dans le bon ordre notamment avec un ILI9341 qui ne sait remplir que dans un seul sens à ma connaissance. Cela veut dire que pour toutes mes images, il me faut une version Portrait, une version Paysage, voir une version Portrait inversée et une version Paysage inversée. Avec un ST7781, c'est plus facile, on peut remplir la mémoire écran dans les 8 sens possibles.

En mode parallèle, je ne suis limité que par la vitesse du micro. En théorie, l'ILI9341 a un temps d'écriture de 66ns, et on pourrait remplir l'écran en 40ms avec la solution A de tout à l'heure ou 5ms avec la solution B.

J'obtiens en 3 octets par pixels lamentablement 9,8s au lieu des 40ms, mais il faut bien que je fasse mes boucles, que j'aille demander de l'aide à la carte SD....
En 2 octets par pixels, je descend à 6,8 secondes. Normal.

Je soulève un autre point, que je n'avais pas vu au départ. Pour effacer l'écran, non pas avec une image, mais simplement avec une couleur fixée, je n'ai pas vu dans la doc du ILI9341 la possibilité d'envoyer 76800 fois le même word. Dans ce cas, pour effacer un écran, cela devrait prendre mes 3s. Je transfert en effet que 2 octets par pixels, je suis toujours dans ma solution B) car je me moque du sens dans lequel s'effectue le transfert.

En mode parallèle, il me faut 230ms pour colorier les 240x320 points avec une couleur, et 80ms seulement en noir ou en blanc (en fait si l'octet de poids faible est le même que l'octet de poids fort, j'envoie cet octet puis une suite d’impulsions /RW). J'aurais quel temps si je suis en série?

Je retrouve le même problème je dessine des rectangles pleins.

4

dans le cas particulier où vous n'avez pas à modifier les valeurs des pins en parallèle c'est sûr que on gagne un peu par rapport au mode série

De toutes façons le point c'est que dans l'un ou l'autre mode, ce ne sera pas rapide car votre arduino ne tourne qu'à quelques Mega-Hz et qu'on a des Mega-bit à transférer. faudrait être en Giga Hz.... Le graphisme ça coûte toujours cher d'où le développement des écrans type 4D ou Nextions etc avec de l'info embarquée côté écran...

Si l'interface doit être complexe, alors un RPi semble plus adapté à la partie IHM qu'un Arduino à mon avis

5

Si l'interface doit être complexe, alors un RPi semble plus adapté à la partie IHM qu'un Arduino à mon avis

Ce n'est pas le cas, au début je pensais à quelques boutons, et un afficheur texte 2x16, mais vu le prix d'un tactile couleur, j'ai changé d'idée. Je sais qu'avec un 320x240 parallèle, je peux aller plus loin, en voyant les afficheurs série, je me pose des questions. Si je gagne 6 broches, mais que je vais lentement, je garde mon parallèle.

Je ne me vois pas piloter mon moteur pas à pas avec u RPi, ni mettre un RPi et un arduino. Pourquoi faire cher et compliqué quand on peu faire simple? J'affiche une image contenant des boutons, et mon arduino pilote mes moteurs quand j'appuie sur un bouton. Maintenant si l'afficheur est graphique, ce n'est pas désagréable.

J'ai entendu dire qu'avant d'acheter un composant, il fallait lire la datasheet, je suis bien d'accord, mais toute la lecture des datasheets ne me renseigne pas sur la vitesse d'affichage d'un bitmap. Comment choisir dans ces conditions entre un afficher série et parallèle? C'est pour cela que je pose la question de la vitesse, mesurable seulement par quelqu'un qui a le matériel.

6

OK - oui.. je n'ai pas d'écrans série, j'ai que des TFT chinois pas cher mais qui font le job pour des interfaces simples. je ne me suis jamais aventuré à essayer de peinturlurer des trucs compliqués par transfert de bitmap

7

Je suppose que tu doit effacer l'écran au moins au début, Non?

A la mise sous tension, il y a n'importe qui dans la mémoire. Et éventuellement si tu change de menu.

8

ils ont des primitives d'effacement je suppose, j'avoue ne m'être jamais penché sur l'API de ces écrans, j'utilise les librairies