Recent Comments
 | zoomxx on Decoding Digoo DG-R8S outdoor… |
| zoomxx on Decoding Digoo DG-R8S outdoor… |
 | Leo on Decoding Digoo DG-R8S outdoor… |
| zoomxx on Digoo DG-HOSA door sensor and… |
 | blogdir on Digoo DG-HOSA door sensor and… |
Mcufriend LCD TFT shield con ILI9325: Test librerie
Posted by on August 14, 2015
An English version of this post is HERE! Updated with link to a solution for bitmap colours.
Articolo aggiornato con il link al post sulla soluzione del problema dei bitmap con colori sballati.
Aggiunta l’ottima libreria di David Prentice.
Ho comprato recentemente uno shield con LCD TFT su Ebay, questo:
Alcune caratteristiche dichiarate erano:
- 4-wire resistive touchscreen
- spfd5408 controller with built in video RAM buffer
- 8 bit digital interface, plus 4 control lines
Lo schermo che mi è arrivato è però diverso
E’ evidentemente diverso. La scritta ili in basso a destra e la stampa 9325 a sinistra inducono a credere che il controllore sia un ILI9325 invece dell’SPFD5408.
Il sito mcufriend è giù da mesi, forse qualche anno. E’ presente su Archive.org ma i driver non sono stati archiviati.
Sono qunindi andato su questo sito http://misc.ws/2015/01/24/lcd-touch-screen-information/ da dove ho scaricato un programma di test, LCD_ID_Reader Version 1.2 che ho scaricato e provato usando un Arduino UNO R3 e l’IDE 1.6.5. Ho così avuto conferma che il controllore è un ILI9325 e visualizzato una schermata tutta rossa che dovrebbe significare che la libreria di Justin, l’autore del post, dovrebbe funzionare. E così è stato con l’eccezione della visualizzazione delle immagini bitmap. Io ho ottenuto questo
I colori sono sballati. Da esperimenti fatti sembra che ciò sia dovuto a qualche registro non configurato correttamente perché i colori Rosso Verde e Blu puri vengono visualizzati correttamente. (Edit: 08/09/2015 soluzione qui.)
La libreria Adafruit per questi schermi ad interfaccia parallela identifica correttamente lo schermo ma non visualizza nulla, ottengo il classico schermo bianco.
Cercando sul forum forum.arduino.cc ho trovato questo post www.mcufriend.com working in arduino uno and arduino mega scritto da buhosoft il quale pubblica una libreria Adafruit modificata. Tale libreria funziona solo che occupa il doppio dello spazio di quella originale Adafruit e l’esempio che visualizza immagini bmp su una UNO non ci entra.
Allora ho eliminato da tale libreria tutta la roba che non riguardasse l’ILI9325 ottenendo che l’unica differenza rispetto alla libreria originale Adafruit erano alcune righe nella routine di reset nel file cpp della libreria.
Le righe originali
*******************ORIGINAL ADAFRUIT******************
#ifdef USE_ADAFRUIT_SHIELD_PINOUT
digitalWrite(5, LOW);
delay(2);
digitalWrite(5, HIGH);
#else
if(_reset) {
/*
digitalWrite(_reset, LOW);
delay(2);
digitalWrite(_reset, HIGH);
*/
digitalWrite(_reset, HIGH);
delay(50);
digitalWrite(_reset, LOW);
delay(100);
digitalWrite(_reset, HIGH);
delay(50);
CS_ACTIVE;
RD_ACTIVE;
WR_ACTIVE;
delay(10);
}
#endif
Vanno sostituite con queste
*****************MODIFIED BUHOSOFT*******************
#ifdef USE_ADAFRUIT_SHIELD_PINOUT
digitalWrite(5, LOW);
delay(2);
digitalWrite(5, HIGH);
#else
if (_reset) {
digitalWrite(_reset, LOW);
delay(2);
digitalWrite(_reset, HIGH);
}
#endif
Effettuando questa modifica alla libreria Adafruit funziona tutto tranne daccapo la visualizzazione dei bitmap.
Ho quindi provato la libreria di Smoke and Wires. http://www.smokeandwires.co.nz che si trova su GitHub https://github.com/Smoke-And-Wires/TFT-Shield-Example-Code. Funziona ma ho sempre il problema dei bitmap.
Ho poi provato la libreria di samuraijap. Funziona ma con errori, le immagini e i disegni appaiono nel posto sbagliato come se l’indirizzamento della memoria fosse errato.
Ho quindi provato la libreria di ruelj2. Anche questa funziona ma durante la scrittura dei dati compaiono delle righe bianche sullo schermo che poi scompaiono cessata la comunicazione.
L’altra libreria provata è stata quella di goltermc che ha funzionato.
Aggiungo la libreria di David Prentice
http://forum.arduino.cc/index.php?topic=286790.msg2477797#msg2477797
Ho eseguito il test solo con l’esempio graphictest_kbv ma ha funzionato perfettamente.
Quelle provate ma che non hanno funzionato sono:
- Libreria di andreword
- Libreria di JoaoLopes
- Libreria di acharis
- Libreria di SeedStudio, una vecchia versione per SPFD5408A che sembra essere compatibile con l’ILI9325
Non ho provato la libreria UTFT in quanto i pin per la comunicazione parallela sono diversi, usa i primi 8 pin compresi quelli della seriale.
Molte librerie sono vecchie e per funzionare sull’IDE 1.6.5 bisogna aggiungere un const davanti a tutte le righe che iniziano per static unsigned char font[] PROGMEM = { nel file glcdfont.c
Negli sketch di esempio per i bitmap va inoltre aggiunta la riga #include <SPI.h>
An English version of this post is HERE!
zoomxtech 
Pingback: McuFriend LCD TFT shield e ILI9325: problema Bitmap con colori scorretti risolto. | zoomxtech
Ciao, bell’articolo innanzitutto.
Ho anch’io uno shield LCD ma in tutte le prove che ho fatto mi è sempre comparsa solo e soltanto la schermata bianca sul display.
Provando con il comando tft.readID() a leggere il driver mi restituisce il codice C0C0.
Con la libreria AndersMmgLcd trovata in giro (credo differisca per alcuni ritardi in fase di reset) sono riuscito a capire che il driver è lo 0x9341…però gli esempi trovati in giro mi danno comunque una schermata bianca (tra cui ad esempio quello di goltermc).
Hai idee su come correggere la cosa?
Ho provato anche a definire la costante USE_ADAFRUIT_SHIELD_PINOUT uguale a 1 ma non è cambiato niente.
LikeLike
Grazie!
Purtroppo non ho un display con ILI9341 e comunicazione parallela per cui non saprei come effettuare test. Io ne ho uno ma con comunicazione SPI che ancora non ho mai usato con Arduino, solamente con i micro STM32 che vanno a 3.3v
Le tue ricerche hanno già trovato una delle due risposte che conosco, quella del ritardo, che ho trovato su GitHub
https://github.com/adafruit/TFTLCD-Library/issues/18
L’altra parla di comunicazione difettosa, tipicamente una saldatura fredda, l’ho letta sul forum Adafruit e sul forum di Arduino dove un utente, ripristinando la saldatura difettosa, trovava un ID0x9341.
Purtroppo la libreria UTFT, come ho scritto, utilizza una piedinatura differente.
Dovresti provare a cercare sia sul forum Arduino che su GitHub. Eventualmente posta sul forum Arduino cercando di mettere più informazioni possibili, ad esempio una foto del retro dello shield come ho fatto io.
Riguardo la costante USE_ADAFRUIT_SHIELD_PINOUT devo indagare ulteriormente. Io ricordo di averla commentata ma lo sketch mi stampava lo stesso il messaggio che stavo usando lo Shield Adafruit per cui, tempo permettendo, dovrei sperimentarci sopra.
LikeLike
Ciao e grazie innanzitutto della risposta!
Ho trovato la mia soluzione. Innanzitutto anticipo che non sto usando Arduino ma un R3 UNO.
La scheda insieme al display li ho comprati da BangGood.
La soluzione è riportata qui: http://forum.banggood.com/forum-topic-95414.html
Seguendo solamente il primo commento mi funzionava il display ma non il touch.
Seguendo anche il secondo commento postato funziona il touch e poi viene riportato il codice per invertire i valori di ingresso del touch (che altrimenti erano sballati).
Spero sia utile!
LikeLiked by 1 person
Forse a me non servirà ma magari servirà a qualcun altro. Grazie!
La R3 Uno è una scheda Arduino a tutti gli effetti. Da Banggood hai preso scheda e schermo assieme. Magari non è una Arduino/Genuino originale, ma una compatibile che fa uso del chip e dei driver CH341 come convertitore USB-Seriale.
LikeLike
In effetti ancora non avevo capito se fosse una scheda Arduino oppure no. Ho visto che anch’essa è made in Italy ma c’è scritto solo R3 UNO e non Arduino (viene solo descritta come “compatibile con i dispositivi Arduino”)
LikeLike
Salve,
mi chiamo Loris ho anche io da poco acquistato un monitor come sopra illustrato e visto che ho trovato questa pagina ho provato gli schetc sopra indicati e come gia provato da tanti lo schermo diventa da bianco diventa rosso, ma ora se volessi visualizzare l’immagine da una SD come si modifica lo schetc?
LikeLike
Loris, scusami per il grandissimo ritardo ma mi deve essere sfuggita la mail di moderazione.
Per leggere l’immagine bitmap da SD ho usato l’esempio della libreria Adafruit.
LikeLike
Salve..ho smanettato anch’io con un display simile a questo,8 bit+ segnali di controllo,il display era più grande,480 x 320 .Mi sono fatto le librerie da zero compresa la parte a bassissimo livello dove per guadagnare qualche MHz faccio tutto a livello di registri, e FIFO,ma si può fare di meglio(DMA ecc),il micro è un Kinetis da 120 MHz,sui 3 euro circa.Per comodità di Debug ho fatto i trasferimenti da SD card a display bloccanti.Purtroppo con librerie gà fatte non me ne va mai bene una,sono io che non so sfruttarle.Con gli svantaggi dei vbloccanti se non altro ci si muove nel debug sapendo cha il lavoro della riga precedente è stato svolto.
Consiglierei (the discover oh hot water)
1)Leggere assolutamente l’ID del controller,farsi del codice apposta,e leggerlo almeno in una finestra di variabili di debug
2)Guardare l’inizializzazione e verificare se vuole i colori in RGB888 ,RGB565,RGB555 o al contrario in BGR888 ,BGR565,o BGR555,tranne nei casi di 888 i colori vanno quindi estratti dalla bitmap (se si lavora con SD card) o da file C se ci sta in flash,e se la conversione bitmap C non è come la vuole il controller
3)Farsi col Paint una Bitmap di quadrettoni rosso giallo e blu coi rispettivi colori a 255 e gli altri a 0 in ognuno dei 3 casi.Non è una prova esaustiva,ma se già questa esce sbagliata ci sono da fare vari passi indietro.NB serve qualcuno dei tanti tools in rete per convertire in RGB16bit,oppure Photoshop,non avendolo ho usato Easy Graphic Converter.
LikeLike
Complimenti per la realizzazione di una libreria da zero. Io non ne sono capace!
Il problema dei TFT cinesi economici è che il controller non è sempre quello dichiarato, è come un terno al lotto. Quindi il primo problema è quello di identificare con un apposito sketch il controller.
Sul forum Arduino in inglese c’è un utente, David Prentice, che ha iniziato a lavorarci realizzando uno sketch molto completo e realizzando una libreria pressoché universale.
Per farlo ha acquistato diversi moduli TFT ad 8 bit, quindi non SPI, su cui ha poi lavorato.
Il megathread è qui
https://forum.arduino.cc/index.php?topic=366304.0
Discutendone con lui problema dei colori sballati risulta essere un difetto del modulo che sembrerebbe avere alcuni bit del colore bloccati. Anche lui ha avuto lo stesso identico problema.
Sono però arrivato alla conclusione che tali moduli, su una UNO, occupano troppi pin e parecchia memoria.
Sto provando quindi con le schede STM32F103 economiche, conosciute come Blue Pill, e le Maple Mini, sempre con STM32F103. Con queste si riesce a fare una decodifica di immagini jpg letta da SD
https://forum.arduino.cc/index.php?topic=376768.0
Il forum di riferimento è
http://stm32duino.com/
LikeLike
Salve.Quello che metto in discussione è la cosa un pò troppo frequente in quest’epoca di Arduini e Raspberrys,di aspettarsi che le librerie siano pronte all’uso con qualsiasi hardware,e se non vanno boh….non dico di farsele da zero(cosa che ho dovuto fare per risorse limitate su un micro che già deve fare troppe cose),ma almeno di fare un pò di debug a basso livello per vedere se i pin interessati si muovono.
Per la cosa del colore,immagino che Prentice ci avrà provato,ma invito tutti almeno a provare su quel tal modulo l’effetto di ogni bit,semplicemente facendo delel maschere durante l’invio dei dati.
Esempio ,io mi immagino che sia RGB565 in SD card e il display voglia BGR565.Il codice sarà tipo(semplificando e schematizzando,il codice non è proprio corretto)
//facciamo fitna che l’immagine abbia un numero di bytes multiplo di 512,così non ho resto
num_blocks_image=image_size_in_bitmap_header/512;//(ricavato da header bitmap)
while(num_blocks_image–)
{
read_512_bytes_from_SD(my_buffer);
do
{
RGB_Word_SD=my_buffer[i++];
RGB_Word_SD=my_buffer[i++]<<8;//MSB arriva dopo
//eventuale manipolazione bits RGB…supponiamo che LCD li voglia in BGR
Extract_RGB_in_ILI9xxx_format(&RGB_Word_SD,&LCD_BGR_hi,&LCD_BGR_lo);
//2 bytes per descrivere ogni pixel
write_data_to_LCD_RAM=LCD_BGR_hi & mask1;
write_data_to_LCD_RAM=LCD_BGR_lo & mask2;
}while(i<512);
}
se mask1=mask_2=0xFF l'immagine mi passa tutta,se invece mi immagino che l' msb del rosso sia il bit 4 del secondo parametro allora da finestra variabili di debug forzo mask2=0x10,e vedo subito l'effetto che fa,rifaccio con mask2=0x8..0x4…0x20 ecc
LikeLike
Nel nostro caso il driver è noto ed esiste il datasheet. Non ho controllato che le librerie lo rispettino, però.
Quello che abbiamo supposto è che, dato il costo molto basso, si possa trattare di scarti di produzione.
Quel modulo è l’unico che mi ha presentato questo difetto, gli altri no.
Il test poi non è stato fatto leggendo una immagine ma generando i colori in bande.
La maggior parte del lavoro lo ha fatto David, io mi limito ad utilizzarlo per applicazioni che richiedono pochi colori.
Attualmente però uso display con comunicazione SPI.
LikeLike
Ah…ok…spero comunque che quanto ho postato sia corretto e possa essere di qualche utilità
LikeLike