Bonjour à tous
Débutant avec l'arduino, j'ai récupéré un écran pour essayé d'afficher quelques data histoire de m'amuser..
Pourriez vous me dire comment peut-on savoir quels écran sont compatible ?
Pour information j'ai récupéré ce model : https://www.twscreen.com/en/lcdpanel/1771
Je vois qu'il fonctionne visiblement avec un signal c-mos .
En espèrant avoir posté au bon endroit..
Merci à vous
Je ne vois pas de driver spécifique - à mon avis il faut en plus une carte graphique pour le piloter... ça ne sera pas compatible directement avec votre Arduino.
Merci pour ta réponse si rapide ^^
Je ne sais pas du tout 
Comment fais tu pour savoir cela ?
Aprés si ce n'est pas possible, tampis je le jetterais mais c'est dommage car il est assez grand et les couleurs sont belle .
j'ai téléchargé la doc technique depuis votre lien. Il n'y a aucun mention spécifique d'un composant graphique qui serait embarqué... un ILI9486 par exemple ou autres adaptés à ce panneau
mais c'est juste une impression... je ne connais pas ce panneau
Il faudrait commencer par choisir la taille de l'écran et dire quel arduino est choisi.
Il peut y avoir des écrans trop grands pour certaines cartes arduino.
Bonjour, merci pour ta réponse .
Pour la taille de l'écran il fait : 170.9(H) × 128.2 (V)
Concernant le type d'arduino, je ne savais pas qu'il y avait une différence au niveau des écrans...Pour le moment j'ai un Uno mais si il faut je peut en racheter un
J-M-L, j'ai également regardé dans la doc et je n'y avait rien vu non plus.
L'écran est branché directement sur la carte mère qui le piloté auparavant .
Bonjour
ici un document pdf (merci Google ) où l'on voit la trentaine de signaux à gérer pour piloter cet écran....c'est du lourd et pour moi un circuit intégré dédié parait indispensable
cohétent avec ce qu'on voit sur la page web du produit :
Signal Interface
CMOS (1 ch 6-bit) 31 pins
Bonjour et merci pour ta réponse, oui j'avais posté ce tableau dans le lien du premier post...
Effectivement ça à l'air assez balaise a gérer.. Surement que la carte mère d'origine embarquée l'interface nécessaire au fonctionnement..
Il est dit:
OVERVIEW
T-51638D084J-FW-A-AB is 8.4” color TFT-LCD (Thin Film Transistor Liquid Crystal Display)
module composed of LCD panel, driver ICs, control circuit, and backlight unit
Maintenant la gestion n'est pas celle du ILI classique avec les nombreuses bibliothèques qui vont avec. Mais @J-M-L a raison, les drivers présents ne sont pas graphiques
Sur les 31 signaux, il y a 5 GND et deux VCC ainsi qu'un test qui ne doit pas être utilisé. Cela ramène le nombre de broches à gérer à 24. Sur ces 24 signaux, la couleur est définie sur 18 bits, et comme beaucoup d'écrans 18 bits, on n'en utilise souvent que 16 car cela fait deux octets. Reste donc les 6 signaux à gérer que l'on peut comparer aux 5 signaux d'un ILI classique.
Pour avoir écrit ma bibliothèque pour un ILI9341 et un ST7781, je trouve que le protocole est beaucoup plus simple.
MAIS car il y a un mais: Cet afficheur n'a pas de mémoire et pour afficher une page j'ai l'impression qu'il faut sans arrêt la rafraîchir. Ce qui nécessite:
− en 640 X 480, cela fait si on reste en 16 bits de couleur 2 x 640 x 480 = 600ko de mémoire ram, soit 300 cartes Uno
− 22 broches de libre, possible avec une Mega, mais pas avec une Uno
− une horloge pour DCLK gérée entre 20 et 30 MHz difficilement réalisable avec un circuit tournant à 16MHz, d'autant plus qu'il faut en moins de 50ns préparer aussi l'envoi des données.
Si on veut un écran avec un affichage qui ne nécessitait pas de mémoriser les pixels (dégradé, couleur unie, quadrillage...) et si la fréquence était 100 fois plus faible, ce serait possible.
Pour piloter un tel écran, il faudrait faire une carte graphique à composants discrets, mémoire de 1Mo+oscillateur+compteurs. Mais le mieux est d'acheter un écran qui fonctionne avec un driver moderne.
+1
Un FPGA serait à sa place dans une telle réalisation, ce qui sort du périmètre de ce forum
C'est pour ça que je demandais la taille (je pensais plus au nombre de pixels) : pour estimer le besoin en RAM et comparer avec ce dont dispose un Arduino.
Mais la taille en mm, si elle est imposée, permet aussi de chercher dans les écrans utilisables avec nos Arduinos, celui ou ceux qui s'en rapprochent le plus.
17 x 13 cm : c'est un bel écran. Ca fait près de 8" de diagonale si je ne me trompe pas. Il faudrait voir du côté des Nextion. On en trouve à 7" et 10".
Sinon, les écrans proches de cette taille sur Aliexpress sont plutôt destinés au Raspberry Pi.
Merci pour ton retour,
Bon je n'ai pas tout compris car je suis novice dans ce domaine..(notamment la correspondance des bits par rapport a la gestion des couleurs ^^)
Cet écran est une récupération qui était destiné à la poubelle. Si ce n'est pas possible, ce n'est pas grave même si, vu sa tille, ça aurais été plutôt cool ^^
Je me demande quand même, pourquoi y a-t-il par exemple pour le rouge "R0 R1 R2 R3 R4 R5 ? ce sont différentes nuances de rouge ?
Si je n'utilisait que le blanc, par exemple, cela réduirait il la mémoire a utiliser ?
Je pensais à cela, si la RAM est effectivement un soucis sur l'arduino , cela pourrait il passer sur un ESP8266 ?
Je regardais ce tableau de correspondance : NodeMCU ESP8266 Vs. Arduino UNO Board - Makerguides.com
L'ESP à l'air nettement plus puissant que l'arduino ?
Si on veut un affichage noir ou blanc, il faut un seul bit, par exemple 0 pour noir, 1 pour blanc. Avec un octet, on pet donc ranger les informations pour 8 pixels. Le besoin en mémoire sera de
640 X 480 bits soit 640 X 480 / 8 = 40ko seulement ce qui est au delà de l'Uno...
Si on veut 256 couleurs, il faut 256 possibilités soit un octet par pixel. soit 640 X 480 octets soit 300ko. Si on veut définir la couleur sur 16 bits (64000 couleurs), il faut 600ko/écran
Cela ne sert pas à grand chose d'avoir plus de 64000 couleurs, on est presque à la limite de la vision. C'est pour cela que bon nombre de circuits limitent la définition des couleurs à 260000 couleurs (18 bits/pixel). Comme une couleur est défini par les 3 composantes (couleurs primaire additives), cela fait que l'on peut définir les composantes sur 6 bits (64 niveaux). On a donc alors:
64 niveaux pour le bleu
64 niveaux pour le vert
64 niveaux pour le rouge
ce qui fait en tout 646464=262000 couleurs.
C'est pour cela que le rouge est défini par 6 bits R5 R4 R3 R2 R1 R0.
000000 correspond en général à du noir
111111 correspond en général à du rouge
100000 correspond en général à du rouge foncé (entre rouge et noir)
Si on veut du rouge clair, il faut alors rajouter autant de vert que de bleu
Le problème est que pour stocker des pixels sur 18 bits, il faut trois octets ou faire des découpages d'octets. C'est pour cela que l'on utilise souvent le 16 bits (rouge sur 5 bits, bleu sur 5 bits et vert sur 6 bits, l'œil étant plus sensible au vert). Du coup un pixel c'est deux octets.
Oui, "seulement" 40ko soit 16 fois moins.
Les ESP, c'est aussi de l'Arduino, mais pour moi un terrain inconnu.
Plus la mémoire. Pas forcément facile car il faut un double accès à la mémoire, d'une part par la FPGA, d'autre par pour écrire ou lire les pixels.
L'ESP32 dispose de bien plus de RAM que les cartes Arduino. Je pense de l'ordre de 500 kB. A vérifier.
Un grand merci à toi d'avoir pris de ton temp pour m'expliquer tout cela! 
(je vais quand même me relire encore ta réponse car je m'y mélange les pinceaux 
)
Si je résume, mes problèmes avec cet écrans sont :
Le fait d'écrire que d'une seul couleur peut me faire diminuer la taille de la mémoire mais pas suffisamment .
Du coup, est il possible d'afficher des données seulement sur certaine partie d'un écran ?
Cela réduirait encore la taille de la mémoire nécessaire ...? 
Il y a aussi la fréquence de 20MHz mini pour l'horloge qui pose problème. Il faut non seulement gérer l'horloge, mais aussi envoyer les données, compter les colonnes et les lignes... pendant ces 50ns. je ne suis pas sûr qu'une ESP à 240MHz suffise. C'est pour cela que l'on a parlé de circuit combinatoire dédiés (FPGA ou compteurs)
Oui, mais dans ce cas, autant acheter un petit écran à 10€ qui aura bibliothèque, mémoire...
ok, je voulais pousser le vice jusqu'au bout du bout ^^
Pour la taille, l'idée c'était d'avoir plusieurs petites zone d'affichage comme un équivalent de plusieurs petit écrans..
Je vais allez voir les FPGA mais ça sent la grosse usine pour pas grands chose..mais par curiosité je vais quand même allez voir ce que c'est