piloter un ecran LCD de PSP

[invitee5da1686]

salut

j'ais pour projet de piloter un ecran de console PSP

l'afficheur a une resolution de 480*272 pixels coool )

il dispose de - 8 entres pour le rouge
- 8 entres pour le vert
- 8 entres pour le bleu
- une entree de synchro verticale
- une entree de synchro horizontale
- une entree clock (validation des donnes)

la commande de l'afficheur est la suivante

- synchro horizontale : on envoi 10 fois ( la syncro verticale + 276 clock ) avec hsync a 0

- synchro verticale: on envoi 41 clock avec vsync a 0

- on envoi les donnes de la ligne (syncro verticale )+ les 276 clock pour les pixel avec la valeur des couleur R V B de chacune de 8 entres (8 bits )


le probleme c'est quil fo lui envoyer en permanence les donnes sinon les donnes sur lecran s'efface petit a petit

jais essayer avec un pic mais c'est trop long a ecrire tout lafficheur genre 2 sec pour remplir l'afficheur ...

je voudrait essayer d'utiliser une ram et un peu de logique pour envoyer les donnes ecrite dans une ram et les envoyer dans lafficheur en controlant l'afficheur automatiquement pour liberer le pic

si vous avez des idees se serait sympas car la c'est pas evident de pas faire une usine a gas ^^

pour la ram jais des HY534256ALS-60 recuperer sur une vielle carte graphique

http://pdf1.alldatasheet.com/datashe...534256ALS.html

et la doc de l'afficheur

http://document.sharpsma.com/files/L..._SP_122805.pdf
-----

[invite5637435c]

Bonsoir,

ton écran ne dispose pas de controlleur intégré donc il faut en faire un ou utiliser une carte graphique dédiée.

Pour en faire un il te faut nécessairement un µC adapté genre PIC24 (16 bits).

http://www.epn-online.fr/page/new564...u%C3%A9es.html

[invitee5da1686]

salut

merci pour ta réponse

je vais donc essayer de faire un controleur avec un pic 24

si jais bien compri certain pic 24 on des peripheriques pour controler automatiquement des afficheur ?

je me demande si sa vau vraiment le coup ... car jy connais rien en pic 24

j'avais penser d'utiliser une eprom 16 bit avec un compteur sur les adresses pour envoyer les donnes d'une ram et de generer les signeaux pour l'afficheur

qu'en pensez vous ?

[behemerre]

Salut,

si jais bien compri certain pic 24 on des peripheriques pour controler automatiquement des afficheur ?

Non.
Les PIC24 utilisent des registres 16 bits adaptés tes besoins c'est tout.
Il va te falloir programmer tout ça comme un grand aprés ou trouver un controller pour ton écran pour faciliter le travail

a+

[A voir en vidéo sur Futura]

[invitee0bbe70d]

Bonjour,

Les PIC24/dsPIC/PIC32 ne possèdent pas de controleur grahique intégré mais possèdent un port parallèle appelé PMP qui permet le controle de périphériques externes.
Les librairies graphiques gratuites permettent de piloter un écran LCD externe s'il est équipé d'un controleur graphique.
Tu peux voir la ici liste des controleurs LCD supportés et le schéma bloc du système.

Ces bibliothèques sont compatibles PIC24/dsPIC et même PIC32 si tu as besoin de plus puissance (décodage d'images JPEG,...)

a+

[invitee5da1686]

salut

merci a vous

l'ideal serait d'utiliser les librairies de microchip mais le probleme c'est que mon ecran n'a pas de controleur integrer

est il possible de lui trouver un chip controleur pour ce genre d'afficheur ?

ou alor de trouver un afficheur bon rapport qualite prix compatible avec la librairie ...

a+

[invite08dfbb47]

Hello!

Moi ce projet m'interesse fortement !
Je me débrouille bien avec les pics, je peux certainement filer un coup de main!

Toujours d'actualité pour toi ?
Tu en est ou ?

[mat64]

Ou alors tu peux utiliser un micro qui à un controlleur intégré (genre PXA255) , mais ça risque d'être un peu plus cher que le pic.

[invite3009a8f7]

Notre ami propose quelque chose de très intéressant. Un petit PIC32 de Microchip en 80 pins peut s'en sortir au niveau du nombre d'entrées/sorties côté LCD.
Comme le processeur travaille en 32 bits à 80MHz, on peut espérer un compromis viable entre la vitesse de rafraichissement (par exemple 10 écrans par seconde) et la capacité de traitement (par exemple tracer des lignes et remplir des rectangles en 2D sans devoir arrêter le balayage de sortie).
On réalise soi-même ce qui était du haut de gamme il y a 15 ans : les premiers accélérateurs graphiques pour GUI comme Windows. Bit block transfer, line draw, rectangle fill. On n'a pas besoin de plus pour obtenir de jolis écrans à la WinXP. Petit souci : pour simplifier la logiciel qui effectue le scan de sortie (3x8bits plus synchro), mieux vaut écrire les bits RGB en RAM. Est-ce qu'un PIC32 a assez de RAM interne ? 480x272 pixels x3 bytes = 400K byte environ. Il y a un sérieux problème, là ! C'est 32 K byte maximum, pour un PIC32 ! Quoi faire alors ? Trois boîtiers de 256 K RAM esterne ? Là, cela devient un usine à gaz, non ?
Pas nécessairement si les petits boîtiers de RAM partagent les lignes de sortie du scan LCD. Il y a là 24 lignes prêtes à servir ... Il suffirait d'ajouter 10 lignes d'adresses et voilà ... on adresse la RAM ...
On peut décider d'utiliser un système en temps partagé : 10 millisecondes pour scanner le LCD (les 24 lignes de sortie vers le LCD), suivies de 10 millisecondes occupé à digérer les commandes, et mettre le contenu de la RAM à jour.
Pas de vidéo, évidemment ! Ou alors, peut-être, une toute petite vidéo de 32x32 ou 64x64 que l'on écrit directement dans un tout petit buffer séparé (overlay). Tout dépend de la façon dont est écrit le logiciel.
Mais chemin faisant l'on pourrait regretter de ne pas avoir opté pour un petit contrôleur hardware, un vrai, du style Epson S1D15G10 ou Philips PCF8833 dont le balayage à partir du frame-buffer interne est réalisé par des petits compteurs internes hardware, qui ne consomment pas de puissance CPU.
Mais bon, rien qu'au niveau de l'idée, cela vaut la peine d'essayer ! Si cela donne quelque chose de bon, avec le PIC32 et 3 boîtiers RAM, on ne dépend plus de la bonne volonté de tel et tel fabricant de CI. On fait tout par logiciel et comme d'ici peu les petits µC pédaleront à 320 Mhz ou plus, on pourra peut-être viser du 1/4 HD (960x540) plutôt que du 480x270 comme sur la PSP.
Très joli sujet pour un travail scolaire !
Noter également que cette solution via logiciel permet de mieux implémenter certaines spécifications de GUI modernes comme la bibliothèque GUI de Microchip.
Vraiment, sous de nombreux aspects, logiciel, matériel et drivers pour GUI, il y a là un très joli champ d'expérimentation.

[invite1ec12035]

Bonjour à tous,
Ce sujet de discussion m'interesse car je suis un peu dans le même cas que MorpheusPic.
Je désire en effet obtenir quelques conseils sur l'utilisation d'un controlleur lcd avec un mcu (pic32).
Voici la datasheet de mon lcd NEC 640x480: http://www.datasheetcatalog.org/data...8/386688_1.pdf
Commander ce lcd juste avec un mcu classique serait deja impossible vu la vitesse de balayage de l'ecran (25MHz) et le flux d'infos à envoyer en permanence.
J'ai "choisi" un controlleur epson: le S1D13505, j'ai trouvé très peu de doc au sujet de controlleurs de lcd et celui ci a l'air assez populaire, la datasheet de ce dernier est assez lourde mais le principe n'a pas l'air compliqué, est ce que quelq'un a t'il deja utilisé ce genre de composant? Est ce un controlleur approprié?
S1D13505: http://doc.chipfind.ru/pdf/epson/s1d13505.pdf
Merci d'avance pour vos réponses.

[invite4671370c]

Salut
Ce sujet m'interesse aussi, alor j'en profite pour poser une ou deux questions.
La première, je pas compris a quoi servent les signaux Vsync et Hsync, et comment les utiliser.
Deuxièmement, je le meme TFT que toi jonas, mais le problème est tout con, je trouve pas de connecteur pour les donnes. Dans le datasheet ils donnent I/F CONNECTOR IL-310-31 machin truc. Or je trouve pas de connecteur comme ça. Quelqun aurait une petite idée ou trouver un connecteur comme ca?
Merci

[invite1ec12035]

Bonsoir,
Pour répondre à VIIV, j'ai trouvé mes connecteurs (pas encore commandés) chez Farnell, et si tu as le même écran que moi, tu devras acheter le connecteur en plastique + les pins à mettre dedans (+ le fils si t'en trouves pas et + la machine à sertir si tu en fais à la pelle .. ).
Les signaux Hsync et Vsync (+ clock et DE)servent au balayage de ton écran, par exemple chaque Vsync peut "durer" 640 clocks si ton horizontale fait 640 pixel, en principe cette partie est très bien expliquée dans la datasheet de ton écran.
J'attends vos réponses et/ou suggestions .

[invitee5da1686]

je voi que sa interesse du monde

c'est bien domage qu'il y est pas de controleur intergrer ...
pour le moment jais replacer ce lcd dans un placard ,si on pouvais le controller facilement pourquoi pas mais la sa devien compliquer vue le nombres de pixel a envoyer il lui faudrait un bon gros pic a lui meme rien que pour gerer le rafraichisement et une ram externe ou je ne sait koi car d'apres la datasheet la Clock du LCD doit pas etre en dessou de 9 Mhz sous peinne de destruction des pixel ? , quant jais essayer de le controller avec un 18f452 a 40 Mhz le temp de rafraichir environ 2 secondes :/ l'image elle commencer a s'attenuer sur le lcd (disparaitre)

sinon contre jais vue dans le commerce des cadres photo numerique avec un bel ecran a moin de 50 euro ,si c'est ecran on un controlleur et quil peuvent etre facilement piloter sa peut etre interresant ?

bonne chances pour ceux qui cherchent encore ^^
a+

[invite1ec12035]

Bonjour,
Je vois que Morpheus parle de destruction de pixels ??
Je ne m'y connais pas dans le domaine, mais à mon avis il s'agit 'simplement' de normes de rafraichissement définies par le VESA dont voici, en bref, quelques infos:
- de wikipédia: http://fr.wikipedia.org/wiki/VESA
Voilà, à bientôt !