Arduino e' in grado di generare segnali di controllo per LCD grafici ?

Arisalve :stuck_out_tongue:

Mi e' venuta un'altra delle mie idee un po fuori, cosi volevo un'informazione riguardo alla fattibilita' o meno ... mi spiego, avendo un qualsiasi display per notebook, che ormai indipendentemente dalla dimensione hanno quasi tutti un'interfaccia con segnali di comando standard (non importa se a 30 o a 40 pin), volevo costruire qualcosa che mi permettesse di testarli "al volo", senza bisogno di smantellare un portatile ogni volta, e magari di costruirlo portatile, cosi potrei fare i test in qualsiasi posto sia necessario.

Informazioni sui pannelli, qualcosa in rete c'e', anche se non tantissimo, ad esempio

Ed altre simili ... ora, senza entrare nel dettaglio di ogni singolo pannello, mi semba di capire che, a livello di protocolli di pilotaggio, se non uguali siano molto simili, tanto che parecchie volte, sostituendo uno schermo LCD ad un portatile, e' possibile montarne uno di una marca e modello differente senza troppi problemi (della stessa grandezza, anche se qualche volta mi e' gia capitato di montare per prova dei 15 pollici su un portatile da 16,4, ed avere lo schermo funzionante lo stesso) ... inoltre, mi e' gia capitato di trovare pannelli identici su notebook differenti connessi con differenti ingressi dello stesso connettore (in alcuni casi sono connesse solo le linee "odd", in altri solo le linee "even", ad esempio) ... suppongo si tratti di differenti tipologie di protocolli di pilotaggio ed interfaccia, e che i pannelli accettino indifferentemente sia l'uno che l'altro ...

Il mio dubbio era se fosse possibile costruire un "tester" per pannelli ... premetto che per una simile applicazione NON serve pilotare i pannelli in modo specifico (nel senso che non serve assolutamente scriverci ne disegnarci nulla) ... in pratica, tutto quello che servirebbe e' una serie di stringhe di comandi che pilotasse TUTTI i pixel insieme, nelle seguenti condizioni: tutto nero - tutto bianco (e gia qui sarebbe ok), e se possibile anche tutto rosso - tutto verde - tutto blu (non indispensabile, ma piu completo) ... lo scopo infatti sarebbe unicamente di controllare se i comandi vengono correttamente interpretati dal controller interno dello schermo, e se ci sono pixel bruciati o in corto.

Piu specificamente, se fosse possibile realizzare una cosa simile usando arduino per generare tutte le necessarie stringhe di dati ed i segnali di controllo ... ora, in base ai dati che ci sono su quei datasheet, c'e' qualcuno di voi che conosca arduino abbastanza bene da sapere se lo stesso sarebbe in grado di fare una cosa simile ? ... intendo, abbastanza velocita' e capacita' di elaborazione per riuscirci ?

Non voglio il codice gia pronto (anche se, avendolo davanti, non lo rifiuterei certo :stuck_out_tongue: XD), mi basterebbe sapere se, secondo voi, in via teorica la cosa sia possibile o no, in base alle capacita degli atmega.

Etemenanki:
Piu specificamente, se fosse possibile realizzare una cosa simile usando arduino per generare tutte le necessarie stringhe di dati ed i segnali di controllo .

No, anche mettendo da parte le considerazioni sul numero di pin necessari per interfacciare questi display, il fatto che diverse linee sono lvds, c'è il piccolo problema che occorre fornire il dot clock, con tutti i vari segnali sincronizzati con questo, che come minimo sono oltre 40 MHz, cosa totalmente fuori portata anche per Arduino DUE.

facciamo una cosa, TU ti leggi i datasheet e ci dici i comandi da inviare e con quale tempistica, NOI ti diciamo se è fattibile.
Burberismo a parte è un'ottima idea.
Dice che il clock dello schermo è 50HZ (il primo datasheet) ma se si può usare a (molto) meno, allora è fattibile. Oppure si può settare le uscite di arduino per dare il valore prefissato, (i bit dei colori sono indipendenti) e a questo punto attivare una sorgente di clock esterna che fa lavorare il monitor...
ma sono solo iliazioni.

Occhio che pare lavorare a 3,3v

lesto:
Dice che il clock dello schermo è 50HZ (il primo datasheet) ma se si può usare a (molto) meno, allora è fattibile.

Non fare confusione con il frame rate, che su i display vga lcd è tipicamente di 60 Hz, con il dot clock.

Heh, mi pareva troppo bello ... astrobeed, in effetti e' quello il punto di cui non ero sicuro ... troppa velocita' richiesta e troppo poca disponibile ... grazie comunque per le delucidazioni, mi hanno risparmiato un po di mal di testa :slight_smile: .

Mi chiedo se ci sia un componente specifico in grado di generare tali segnali, magari partendo da comandi piu semplici ... devo mettermi a scavare un'altro po nella rete, si direbbe :stuck_out_tongue:

lesto:
facciamo una cosa, TU ti leggi i datasheet e ci dici i comandi da inviare e con quale tempistica, NOI ti diciamo se è fattibile.
...

mi serve quel comando qui ... ( scherzo, ovviamente :stuck_out_tongue: :smiley: )

a parte il simbolo di conguenza, div e grad c'è già tutto, mi preoccupa di più la precisione che ti aspetti e tra quanto tempo vuoi la risposta :slight_smile:

astrobeed:

lesto:
Dice che il clock dello schermo è 50HZ (il primo datasheet) ma se si può usare a (molto) meno, allora è fattibile.

Non fare confusione con il frame rate, che su i display vga lcd è tipicamente di 60 Hz, con il dot clock.

no, mi riferisco al clock frequency di pagina 12 del primo pdf, ma mi è sfuggita una "M"

da quel che ho capito ad ogni clock "input", lui legge i 6 bit per colore e li assegna al prossimo pixel. poi mi apsetto ci sia qualche altra complicazione di mezzo, ma se è così allora arduino semplicemente comanda i 18bit dei colori, e il generatore di clock è esterno.

però basta che quei 6bit non possono rimanere in uno stato fisso durate più refresh che ci fregano allegramente.

lesto:
però basta che quei 6bit non possono rimanere in uno stato fisso durate più refresh che ci fregano allegramente.

Cosa ti è sfuggito del fatto che tutti i segnali devono essere sincronizzati con il dot clock ? :slight_smile:

@Etemenanki
Vedo che ti intendi di schermi di portatili, io avrei questo schermo da 18" di un vecchio VAIO, connettore 40 pin. Posso farmene qualcosa?
Foto: https://www.dropbox.com/sh/bpabju8fry7kqdh/4L5FF7sdwZ

cece99, io mi "intendo" di schermi di portatili solo perche' riparo anche portatili (magari me ne intendessi abbastanza per farci altre cose ... :D)

A proposito, il tuo link dropbox non mi mostra alcuna immagine, solo tre riquadri vuoti, quindi non so che schermo sia ...

Etemenanki:
A proposito, il tuo link dropbox non mi mostra alcuna immagine, solo tre riquadri vuoti, quindi non so che schermo sia ...

Io le vedo perfettamente....
Cmq io avrei adocchiato un adattatore per display a 30 pin, solo che il mio ne ha 40, si può fare qualcosa?

Scusa, in che senso adattatore ? ... intendi uno di questi ? http://www.ebay.com/itm/16-0-LED-to-LCD-CCFL-Screen-Converter-Cable-40PIN-to-30PIN-for-ACER-ASUS-/200907701081?pt=LH_DefaultDomain_0&hash=item2ec7083b59

se si, questi servono per poter utilizzare i nuovi pannelli LCD con retroilluminatore a LED e connettore da 40 pin micro, sui vecchi portatili che avevano i pannelli classici con lampada CCFL e connettore a 30 pin largo, dato che i pannelli vecchi stanno uscendo di produzione e sara' sempre piu difficile trovarli ...

@cece99:
hai quotato un post lungo un casino di righe solo per fare i complimenti a Etemenanki :sweat_smile: :sweat_smile:
Vediamo di non aprire il festival del quote anche qui come già fanno in altre sezioni del forum internazionale ]:smiley:

astrobeed:
Cosa ti è sfuggito del fatto che tutti i segnali devono essere sincronizzati con il dot clock ? :slight_smile:

che i segnali vanno sincronizzati con il dot clock :slight_smile:

ma se colegiil segnale arduino ad una not che prende anche il clock dot? scusa ma non capisco il protocollo (okok, non l'ho nemmeno guardato, ora cerco qualcosa)

lesto:
ma se colegiil segnale arduino ad una not che prende anche il clock dot? scusa ma non capisco il protocollo (okok, non l'ho nemmeno guardato, ora cerco qualcosa)

E da quando Arduino è in grado di gestire frequenze di oltre 40 MHz ? :slight_smile:
Anche il solo segnale di sync per le righe, Hsync, è fuori portata per Arduino visto che come minimo sono 70 kHz.

errore mio, metti AND al posto di not, con un ingresso arduino (fisso) e l'altro ingresso il clok dot. questo però funziona solo in LOW o in HIGH, al massimo mettendo una NOT. no?

per gli altri segnali li possiamo ignorare, tanto vogliamo tinta unita, e quando coambiamo "tinta" non ce ne frega niente di avere per un frame lo schermo di due colori.

lesto:
per gli altri segnali li possiamo ignorare, tanto vogliamo tinta unita, e quando coambiamo "tinta" non ce ne frega niente di avere per un frame lo schermo di due colori.

Ma perché non dai uno sguardo ai data sheet postati ?
Non è che se al monitor gli dai il solo dot clock questo si accende, servono anche tutti gli altri segnali, pure solo per ottenere i tre colori base, e buona parte di questi sono di tipo lvds (bus differenziale).

ho guardato solo il primo ma non dice nulla. ora ho cercato un pò questa LVDS interface e ho capito che è bella tosta.. però c'è chi ha usato una FGPA per fere da ponte tra arduino e il monitor (anche se a questo punto basterebbe usare direttamente solo la FGPA per quello che vuole fare)

http://blog.tkjelectronics.dk/2012/10/lvds-display-controller-for-microprocessors/

Uhm, questo in teoria sembrerebbe un'interfaccia arduino/lvds (o simile accrocchio ;D) ... ma quanto costerebbe un "coso" simile ? ... perche' lo scopo principale sarebbe quello di costruire un "tester portatile", tipo scatolini quasi tascabile ... ovviamente al costo minore possibile ... per cui se poi la loro scheda viene una cifra e mezza, finisce lo scopo principale ...

Anche se, bisogna ammettere, se funziona come mi sembra di aver capito, poi permetterebbe agli utenti di arduino di usare display grafici a volonta', il che non sarebbe proprio cosi male ... :stuck_out_tongue: :smiley:

Etemenanki:
Anche se, bisogna ammettere, se funziona come mi sembra di aver capito, poi permetterebbe agli utenti di arduino di usare display grafici a volonta', il che non sarebbe proprio cosi male ... :stuck_out_tongue: :smiley:

Con una FPGA puoi fare quello che ti pare nei limiti delle sue risorse, incluso un controller per display, però non è una cosa che si implementa in cinque minuti e nemmeno economica.