CITAZIONE
non ho ancora capito il motivo di queste affermazioni che sento in giro. cioè intanto molti non hanno la matrice caratteri salvata, quindi bisogna salvarla sul pic, e qui va bene, si occupa un po di memoria (mettiamo un 16f876 che ha 8kb)
poi per il resto, ad esempio se disegno una riga sul display,non mi occupa memoria perchè la disegno punto per punto no?
la memoria di cui parli è forse quella per salvare eventuali immagini nel pic?
o forse prima di disegnare bisogna memorizzare tutti i punti del display sul pic e poi spedirli?
(e qui sorge il problema che il pic non riesce a scrivere nella program memory, e bisogna passare tipo ad un 8051 o al 18F)
I problemi sono più di uno. Innanzi tutto il primo problema é quello di dove memorizzare le immagini per richiamarle quando servono.
Considerando un display 128x64 pixel. In totale sono 8192 bit, corrispondenti a 1Kbyte.
Questa immagine deve essere memorizzata nella memoria programma del micro o, in alternativa, in una EEPROM esterna al micro.
Di EEPROM ce ne sono di vari tipi con 3 tipi di bus: I2C, SPI e microwire.
Il primo é il più lento, ma é quello che tendenzialmente offre tagli di memoria maggiori, mentre SPI e microwire,entrambi veloci, hanno memorie più ridotte e richiedono inoltre un numero di pin maggiore per essere gestite.
Risolto il problema di dove immagazzinare le immagini resta quello di visualizzarle.
I metodi sono 2: il primo consiste nel leggere dalla memoria eeprom (o interna al micro) l'immagine e inviarla direttamente al display. La seconda invece prende i dati dall'eprom e li memorizza sulla ram (buffer display). Il micro poi, ciclicamente, prende i dati dal buffer e li invia al display.
Considerando il caso di un utilizzo di eeprom con bus I2C operante a 400KHz si avrebbe che la lettura dei dati relativi ad ogni immagine 128x64 richiederebbe circa 1/40-1/50 secondo.A questo tempo deve essere aggiunto quello necessario all'invio dei dati dal display.
Se si utilizza la tecnica di lettura dati->invio al display per non complicarsi la vita oltre l'impossibile conviene effettuare direttamente la lettura dell'eeprom e inviare i dati al display. Questo sistema rischia però di appesantire il tutto dato che ad ogni invio dell'immagine, la cui durata alla fine può essere anche dell'ordine di 1/20 secondo, il programma sarebbe impegnato a fare solo quello.
L'aggiornamento del display con questo sistema é conveniente solo in caso di immagini statiche memorizzate su eeprom.
Se devi invece visualizzare immagini dinamiche, dove all'immagine vera e propria é sovrapposto qualcosa che cambia come cursori, numeri di contatori, orologi ecc., dovresti, ad ogni piccola variazione dell'immagine, rileggere i dati su eeprom, elaborarli "al volo" per sovrapporre le modifiche e inviarle al display. Fino a quando si tratta di scrivere una riga in orizzontale o in verticale il discorso é fattibile, ma se all'immagine devi sovrapporre un testo come il valore di un contatore l'impresa diventa al limite del proibitivo.
In questi casi é più conveniente usare il secondo sistema, dove l'immagine viene caricata solo una volta e le animazioni vengono effettuate modificando i dati sul buffer. Ciclicamente il display viene "rinfrescato" prendendo i dati dal buffer display e inviandoglieli.
La fase di rinfresco può essere anche realizzata a scansione, ovvero spendendo al display solo una parte dei dati ad ogni ciclo di programma (ad esempio una riga alla volta), cosicché la scrittura risulti diluita e non provochi grossi rallentamenti in occasione dell'aggiornamento del display.
La cosa migliore in assoluto sarebbe avere a disposizione una parte di ram doppia rispetto a quella necessaria al buffer display; si avrebbe in questo modo un doppio buffer: uno visualizzato e l'altro nascosto. Quando devi aggiornare l'immagine metti tutti i nuovi dati nel buffer nascosto e solo ad aggiornamento avvenuto rendi visibile il buffer nascosto e, parallelamente, nascondi quello visibile che sarà ora aggiornabile con i nuovi dati.
In questo modo avrai l'immagine che varia di colpo senza notare quelle imperfezioni causate dal trasferimento dei dati da memoria a display.
Queste sono le tecniche che uso io, poi magari ne esistono di migliori o di più efficienti.
Certo é che qui stavamo parlando di un display 128x64, non proprio il massimo dell'alta risoluzione. Se se ne prende uno ad esempio 256x128 la memoria da usare quadruplica e anche i tempi di aggiornamento, complicando ulteriormente il discorso. Se poi si ha a che fare con i display TFT..........beh il casino é esponenziale, dato che sono in pratica dei monitor RGB con segnali di sincronismo e i segnali colore da generare col micro.
Spero di averti chiarito qualche dubbio.
).
