Hello,
apparement il y'a des ecrans 5'' pour arduino
j'ai lu qu'il vallait mieux utiliser un DUE pour la communication parallele et la puissance du cpu
mais ou acheter un tel ecran en europe et être sur que la doc est suffisante ??
merci pour votre aide
Bonjour
Je ne comprends pas trop la question, mais pour des écrans Arduino, il y a de nombreux exemples sur le Net.
En ce qui me concerne j’ai utilisé sur plusieurs projets des écrans Nextion ou son homologue chinois avec un Arduino nano ou un Attiny85 en standalone sans problème.
Cordialement
pour des ecrans relativement grand, faut oublier l'arduino je pense
le mieux c'est un stm ou alors les ecrans adafruits et le module ra5... ce qui revient cher
Arduino c'est tout une gamme de cartes et de processeurs différents maintenant donc on ne peut pas généraliser.
Il faut définir clairement un besoin et des contraintes et faire son choix après.
bah deja en terme de contrainte, trouver un ecran 5'' 800x480 (800x600?)
adressable en parallele, pas trop complique a mettre en oeuvre et avec un rafraichissement decent. et commandable en europe (belgique)
je pourais essayer du aliexpress mais je dois etre sur du modele et que la doc soit abondante, ou carrement un project github qui prouve que ça fonctionne
ah aussi pas d'ecran RPI car je veux un truc qui ne mette pas 10' a booter
j'ai établi mes besoins mais faut croire que je suis le seul a avoir besoin de ça
Je ne comprends pas la raison.
Les liaisons parallèles , dont la célèbre Centronic ou le GPIB pour le pilotage d’appareils de mesure sont des souvenirs du passé.
Meme si au final le traitement est parallèle, des circuits intégrés, intégrés aux modules ecran, assurent la conversion série/parallele ce qui évite de mobiliser un grand nombre de gpio sur les microcontroleurs.
Pourquoi l’I2C ou le SPI, plus rapide, ne sont pas compatibles avec tes besoins ?
Le choix y est bien plus vaste.
Je fais tourner un écran SPI sur une carte esp32-s3-zero avec seulement 2 gpio Mosi et Sck ( je n’ai qu’un seul composant SPI donc CS n’a pas a être géré, si l’ecran est tactile il faut ajouter miso).
Note : avant d’acheter un composant sur Aliexpress j’utilise un moteur de recherche avec cette recherche : ”Github Nom_du_composant”.
Tu vois immédiatement si des bibliothèques existent.
Tu peux, à partir du site Github avoir accès aux exemples des bibliothèques.
Que demander de plus ?
Un autre avantage du SPI, sur les CPU un peu performants, c'est que les transferts peuvent se faire en DMA ce qui réduit la charge du CPU. Ne pas oublier qu'un écran 800x600 c'est quand même 480000 octets à transmettre lorsqu'on remplit l'écran, en mode 256 couleurs et le double si tu es en mode 64k couleurs.
Avec l'interface parallèle ce n'est pas toujours possible si le bus n'est pas connecté sur des GPIOs consécutifs et correctement alignés sur un multiple de 8 ce qui n'est pas toujours possible lorsque tous les GPIOs ne sont pas accessibles (et c'est le cas sur de nombreuses cartes).
j'ai lu sur ce forum et ailleurs qu'il fallait du parallele pour des grandes resolutions
j'en sais rien, si ça march een SPI et sur arduino due/mega, evidemment que je suis preneur
d'ou la difficulté de trouver le bon MPU pour le bon ecran
et effectivement le DMA sur bus parallele me semble la meilleur option
hé bien aujourd'hui on revient au parallele justement
pas de sérialisation, donc ça fly
quant tu dis que tu utilises du SPI, je serais curieux de savoir sur quel ecran et quelle vitesse de rafraichissement
Il doit y avoir quelque chose que je n'ai pas compris. Par exemple pour un petit écran 320*200 équipé d'un ILI9341.
-> Si on écrit un point en 256 couleur en mode parallèle, le cycle mini est de 150ns. Si on utilise un processeur rapide, on peut envoyer un octet toutes les 150ns.
-> Si on utilise le mode SPI, le cycle mini est de 100ns. Si on utilise un processeur rapide, on peut envoyer un octet toutes les 800ns.
J'ai l'impression que si on veut un peu plus de rapidité, il faut passer en mode parallèle.
Je n'ai pas fait d'essais, mais je suppose qu'en utilisant le mode 16 bits, on doit aller encore plus vite.
Avec une carte comme ci dessus, monté sur shield sur uno ou mega, les GPIO ne sont pas alignés du tout. Avec une uno, on utilise des GPIO de 2 ports différents (PD7|PD6|PD5|PD4|PD3|PD2|PB1|PB0), sur une Mega, c'est trois ports différents (PH4|PH3|PE3|PG5|PE5|PE4|PH6|PH5). Et cela fonctionne.
Possible pour une question de vitesse, mais la mémoire des pixels est dans l'écran, pas dans le miro. Si on veut avoir un écran avec des changements de valeurs (par exemple un affichage météo, avec des vitesse, des directions...) le nombre de données à mettre à jour n'est pas très importante et un micro peu rapide peut suffire.
oui j'ai des ILI 320x200 mais je veux passer a du plus grand et plus rapide
Ce n'est pas ce que je dis.
Ce que je dis c'est que l'on ne peut pas faire de DMA. Ce qui implique du transfert octet à octet sans traitement intermédiaire. Or, si les IOs utilisées sont sur plusieurs ports il faut découper les octets du buffer d'image pour les envoyer vers tels ou tels bits de plusieurs ports.
Ce n'est pas la marque de l'écran qui compte, c'est la référence du circuit intégré qui pilote l'écran.
J'utilise l'écran rond de de 1,28 pouce 240x240. Le CI est un GC9A01.
Le SPI est à 40 MHz sur un esp32-S3.
Excuse-moi, je suis un vieil électronicien qui ne parle pas cette langue.
J'ai quelques doutes quand on sait que la principale raison qui a fait abandonner le parallèle est son incapacité à monter en fréquence.
Désolé, mais ce n'est pas un point qui a de l'importance pour l'usage que j'en ai.
Je manque totalement d'expérience sur la rapidité des écrans, donc je n'en dirais pas davantage.
Je dirai que très grossièrement que SPI à 40 MHz correspond à un débit parallèle de 40/8 = 5 MHz.
Probablement la réalité sera inférieure si on fait intervenir les bits de service qui ne transportent pas d'information.
Mais ces bits de service existent aussi en mode parallèle.
Les circuits du SPI sont spéciaux et étudiés pour la vitesse.
Sur un avr la vitesse max du SPI est 16 /2 = 8 MHz
Une suite alternée de 1 et de 0 correspondra à du 4 MHz
Un digitalWrite est plus lent, la même suite de 1 et de 0 avec un rapport cyclique acceptable ne dépasse quelques centaines de kHz.
Note que je ne t'ai pas dit de passer sur un écran SPI, je t'ai écrit que je ne comprenais pas ce choix qui me parait un choix du passé.
Tu fais comme tu veux.
Tu peux aussi te poser la question : pourquoi ces écrans se font rares s'ils sont si bien ?
La réponse est peut-être qu'entre les avr 8 bit à 16 MHz et les micros 32 bits à 240 MHz la donne a changé.
lol
fais ce que tu veux ,moi j'essaye de trouver une solution a mon probleme, on est dans cette discussion je pense ;-)
Ce serait plus simple de dire pourquoi tu as besoin un écran de 800x600 avec un fps rapide ou au moins ce que tu veux dire par plus grand plus rapide car 10 images par seconde pour afficher une température c'est rapide et pour une caméra de surveillance c'est lent
J'ai l'impression que si on veut de la vitesse, il ne faut pas que ce soit le proocesseur qui calcule les octets comme dans les écrans bon marché, mais qu'il y ait un processeur dédié comme dans les nextions.
Si on est sur AVR, et que l'écran est câblé en dur, il ne faut pas utiliser digitalWrite, mais on peut écrire directement dans le port.
Si on est sur du micro plus rapide, en SPI, on ne pourra pas aller plus vite car le driver de l'écran ne le permettra pas. si le temps de préparation de données négligé, on a le choix entre un SPI à 10MHz (ILI9341) soit environ 1µs/octet et un mode parallèle 8 bits à 150ns/octet.
Maintenant il faut savoir aussi quand a-t-on besoin de vitesse. Ce que je trouve éventuellement long, c'est les effacements d'écran et les chargements d'images.
Pour effacer un écran avec 800600 en mode 16 bits, en SPI, il faut envoyer 800600*2 soit 960000 octets. A 10MHz de SPI, il faut environ 1s.
C'est toujours la même donnée qu'il faut envoyer, et en mode 16 bits pour du noir ou du blanc (ou toute couleur dont les poids forts sont égaux aux poids faibles), c'est toujours le même octet qu'il faut envoyer.
Pour effacer un écran en mode parallèle, on positionne la couleur (8 bits une seule fois), et comme la donnée ne change pas, il suffit d'envoyer un carré de période 150ns sur /WR. on peut donc envoyer les 960000 octets en 0,15s.
Bonjour Pour les écrans évoqués içi (5” , 7”) le bus MIPI-DSI est une solution dédiée efficace.
Son utilisation sous IDE Arduino est en approche pour les ESP32-P4 qui disposent de ce bus.
C’est déjà opérationnel pour ESP32-P4 avec l’IDF d’Espressif , le portage en mode ‘Arduino’ va suivre
Avec les ESP32 qui intègrent une interface I2S, il y a la librairie LovyanGFX qui gère certains écrans en interfaces parallèle.
Il faut voir si l'écran de ton choix serait supporté par cette librairie.