Per la serie “ricicliamo i componenti”…
Tempo fa, sotto una pila di scatole avevo ritrovato un vecchio gioco elettronico della clementoni, un pseudo-portatile con un bello schermino LCD grafico; una volta staccato però mi ero arenato sulla pedinatura dei componenti e sull’interfaccia per utilizzarlo. SEZIONE DOWNLOAD in fondo all’articolo
Adesso con qualche base in più ci ho rimesso sopra le mani, vediamo cosa ne è venuto fuori.
Allora innanzitutto utilizza due integrati della Hitachi (ovviamente fuori produzione e a quanto pare “quasi” scomparsi dalla documentazione) HD44105 per il controllo di riga (si limita a fare il refresh automatico delle 4 pagine dello schermo (3 + 1 nascosta) e l’HD44102, praticamente una copia virtuale dello schermo su una ram da 50x8x4 pixel (sono 50 i pixel delle colonne,8 bit per pagina, 4 pagine).
Il bus di interfaccia è su un connettore a 15 fili, dei quali 8 per i dati/istruzioni, 3 di alimentazione (e contrasto) e 4 di controllo (di cui uno praticamente inutile (ma vedremo piu avanti).
Dopo un pomeriggio passato con lente e tester per seguire le varie piste, il sistema si interfaccia così sul bus:
(purtroppo per farla stare nella pagina l’ho dovuta rimpicciolire, per l’originale guarda qui)
Per fissare lo schermo alla scheda (nella scatola originale il tutto era tenuto da incastri) ho utilizzato una piastrina di plastica con dei perni nei fori già presenti, ma arriviamo alla parte che mi ha fatto perdere più tempo: la gestione via software.
Metodo utilizzato: per tentativi (rozzissima modalità di reverse engeneering 😉 ), perché dal datasheet le temporizzazioni per la gestione delle porte di controllo sono, IMHO, molto ma molto confuse e a volte contraddittorie (soprattutto per quanto riguarda la scrittura). Tutto il software è dedicato alla gestione dei 4 pin di controllo ( a dire la verità 3, il CS2 viene lasciato sempre attivo), attesa del flag BUSY dall’LCD e scrittura.
Ovviamente il display non implementa il codice ASCII, e le lettere (ma così i simboli e i numeri) le ho dovute costruire a mano, pixel per pixel, per intenderci, una semplice A è costruita:
stessa cosa per numeri e simboli (mi sono fermato alle maiuscole, per sfinimento)
Protocollo di gestione:
Il datasheet del HD44102 riporta una figura che descrive come gestire le variazioni sul bus di controllo, ma a quanto pare o non so leggere, oppure i tempi indicati sono moolto ottimistici; per fare un esempio il tempo di “Address setup time” (tAS) minimo (CS e R/W fermi tAS prima dell’Enable) è indicato di 140ns:
clock ATmega16 = 4MHz –> Tc = 250ns, quindi tra un ciclo e un altro ci sono 250ns, già oltre al tempo minimo del tAS, eppure se in due cicli consecutivi setto CS e D/I per scrittura (D/I = 1) e nel secondo l’Enable, la procedura non sembra essere riconosciuta.
Per questo ho inserito una funzione di ritardo legata al timer0 tra le varie operazioni sul bus di controllo. Il procedimento di scrittura a schermo è diviso in tre parti:
– (1) attesa del flag
– (2) invio indirizzo di partenza
– (3) scrittura in ram LCD (e quindi su schermo)
Analizziamo ogni passaggio:
(1) Lettura stato e controllo flag
N.B. Le commutazioni sul bus di controllo DEVONO essere in questa sequenza:
BUS_CONT = (1<<RW) | (1<<CS2); //DI = 0
BUS_CONT |= (1<<EN);
Tra queste due istruzioni c’è esattamente un ciclo di clock, circa 250ns e funziona (i problemi di temporizzazione visti sopra sono solo in scrittura).
Il BUSY flag è sul DB7, se è a 1 ripeto controllo, altrimenti passo a (2)
(2) imposto indirizzo
A destra trovate il frammento di datasheet relativo all’impostazione del cursore all’interno del display; si può scegliere la pagina (bit più significativi) e la colonna da cui partire (N.B. l’indirizzo della colonna Y si incrementa da solo una volta settato all’avvio).
Per la gestione del bus di controllo, la procedura resta uguale a prima (prima variazioni su CS2, R/W,D/I in seguito abilito enable) con l’introduzione di un ritardo prima dell’abilitazione dell’enable.
Questo comando non è da confondere con la “pagina visualizzata”, ovvero è permessa la scrittura su una pagina diversa da quella momentaneamente visualizzata (come già detto il display può visualizzare solo 3 delle 4 pagine in mem) e successivamente far scorrere la visualizzazione. (questa funz. per ora non è implementata).
(3) scrittura dati
Successive scritture incrementano il valore di Y, attenzione! una volta arrivato a 49 il registro viene riportato a 0!! (pericolo di sovrascrivere il testo appena scritto).
per questo nel programma utilizzo una routine di controllo colonna, se arriva in fondo, riporta cursore a 0 e incrementa la pagina.
Gestione caratteri
Le lettere sono inserite come variabili nella memoria flash (con il comando PROGMEM non vengono ricopiate nella RAM all’avvio) e caricate in ram solo se utilizzate.
Flash occupata dai simbolo/lettere:
4 byte per simbolo x ( 21 lettere(maiuscole) + 10 num + 6 simboli ) = 148 byte
Il tutto per consentire la completa trasparenza da parte del programma principale, il main infatti invia le lettere al display come fosse un semplice LCD seriale con ascii, la conversione è gestita totalmente dalla routine carattere(). Il file “invialcd.c” è la libreria che contiene tutte le funzioni e le var necessarie alla comunicazione con il display, compreso la cancellazione totale, il cambio pagina e l’ a-capo automatico.
Galleria foto (piclens apre una presentazione)
Sono di bassa qualità e il soffitto mi si riflette sullo schermino rovinando l’immagine, ma rendono l’idea 😉
Sviluppi&miglioramenti:
Non ho ancora implementato tutte le funzioni che offre il datasheet (es. gestione dello scorrimento del testo e magari un semplice text editor, o un semplice giochino tipo “snake”). In ogni caso il codice è stato pensato per essere riutilizzato e modificato per adattarlo ai vari scopi.
Sezione DOWNLOAD
Datasheet componenti (copia locale):
Sorgenti programma:
A presto,
Luca