Quando si progetta un dispositivo basato su ARM che dovrebbe visualizzare una grafica semplice su un LCD a colori, come si dovrebbe fare meglio a progettare le cose per consentire aggiornamenti rapidi, preferibilmente senza essere legati a un particolare fornitore ARM o LCD? Il mio progetto attuale utilizza un display in bianco e nero che può essere guidato alla velocità della luce da una porta SPI su un PIC (ridisegnando un display complesso in 1/60 di secondo). Sembra che i comuni display LCD a colori abbiano una porta SPI, ma anche riempire un LCD 160x120 con un colore solido richiederebbe 30ms e un 320x240 richiederebbe 120ms nella migliore delle ipotesi (10MHz shift clock).
Se uno potesse risparmiare i pin del controller, la modalità parallela potrebbe essere migliore, ma non conosco alcun mezzo indipendente dalla famiglia per collegare l'interfaccia parallela senza richiedere tre istruzioni separate per l'archiviazione della memoria per ciascun pixel (uno per impostare i dati, uno per impostare l'uscita del clock alta e uno per abbassarla). Alcuni chip ARM hanno interfacce bus di memoria, ma spesso vogliono fare cose come indirizzo multiplex e dati, o impegnare molti pin per produrre bit di indirizzo irrilevanti (il display LCD avrebbe bisogno solo di un bit di indirizzo).
Osservando ILI9320 di ILITEK o HD66789 di Renesas, un approccio che sembrerebbe interessante sarebbe quello di utilizzare un CPLD per convertire SPI in dati paralleli e includere una modalità che generasse un pixel per bit. Guardando la scheda tecnica Renesas, potrebbe essere possibile ottenere scritture pixel per bit con hardware minimo (non è richiesto CPLD) facendo in modo che tutti i bit di dati della porta parallela seguano il pin dei dati seriali, usando la modalità seriale per tutto tranne che per i pixel scrive e usando le funzioni di confronto / maschera in modo che i pixel di tutti gli zero siano trasparenti e che i pixel di tutti gli uni impostino i bit selezionati in GRAM, oppure i pixel di tutti gli uni siano trasparenti e i pixel di tutti gli zero cancellino i bit selezionati. La sezione "caratteristiche" della scheda tecnica IKITEK suggerisce che ha funzionalità simili, ma le mappe del registro non
Supponendo che il codice mostrerà principalmente testo e grafica a colori solidi, l'approccio ideale sembrerebbe quello di utilizzare un CPLD per interfacciare la porta SPI di ARM alla porta parallela del display e consentire al CPLD di essere caricato con i colori di primo piano / sfondo. Ciò sarebbe particolarmente bello se si avesse un mezzo per scrivere pixel "trasparenti". Dato un carattere come bitmap a due colori, si potrebbe semplicemente caricare i dati del carattere direttamente nella porta SPI; ciò consentirebbe di visualizzare i dati dei caratteri a una velocità di un pixel ogni due orologi ARM. D'altra parte, un CPLD sufficiente a gestire un'attività di controllo del display costerebbe circa $ 2.
Qual è il modo migliore per interfacciare un ARM con un LCD a colori, se l'obiettivo è principalmente quello di mostrare testo a tinta unita o grafica semplice (ad es. 16 colori o 64 colori)?
modificare
Ho realizzato molti progetti di display LCD, con molti tipi di LCD, tra cui LCD in modalità carattere, segmenti multipli 3: 1 personalizzati basati sul mio metodo di guida, LCD grafici in bianco e nero con controller integrati e in bianco e nero LCD bianchi per i quali ho progettato il mio controller basato su CPLD per interfacciarsi con un DMA per uso generale di un microcontrollore (fornendo anche una scala di grigi a quattro livelli). Sono orgoglioso di rendere i display zippy. Uno dei controller grafici era un po 'un cane che richiedeva circa 1/10 di secondo per un aggiornamento a schermo intero anche quando scrivevo dati costanti, ma la maggior parte dei miei display è in grado di riprodurre anche un'immagine abbastanza complessa in meno di 1/50 di secondo.
Molti dei progetti che faccio sono alimentati a batteria, quindi l'attuale assorbimento è un problema. Il controller del display basato su DMA che ho fatto ha funzionato bene, ma era per un progetto basato sulla linea. Credo che l'unico modo per ottenere un ragionevole assorbimento di corrente da un LCD grafico sia utilizzare un controller che combina il buffer di visualizzazione e i driver di colonna. Inviare un sacco di display tra i chip per ogni frame sprecherebbe molta energia anche su un singolo display bit per pixel; su un display a colori con sedici bit per pixel, sarebbe molto peggio.
Ho iniziato a guardare solo le schede tecniche LCD a colori; molti display sembrano utilizzare un controller simile a ILITEK ILI9320, sebbene tutte le schede tecniche che ho trovato per controller basati su quel design generale siano state contrassegnate come "preliminari". Alcuni come ILITEK affermano di avere funzionalità di mascheramento e trasparenza ma non elencano alcun registro per loro; Non so se i chip reali abbiano tali caratteristiche, ma le schede "preliminari" non sono state incluse o se hanno omesso le funzionalità ma si sono dimenticate di menzionarle. Se in pratica tutti questi chip hanno caratteristiche di trasparenza, sembrerebbe ragionevole progettare per loro; se no, no.
Mi aspetto che per la maggior parte dei progetti uno schermo tipico sia costituito da testo posizionato in modo arbitrario in un numero moderato di caratteri a colori solidi di dimensioni arbitrarie. Molto probabilmente i caratteri verrebbero archiviati come dati bit per pixel. Usando un Cortex-M3, se volessi scrivere il display con dati paralleli, il "loop interno" del codice per scrivere due pixel probabilmente finirebbe con qualcosa del tipo:
rol r0, r0, # 2; Prendi un bit in C, l'altro in N ITC strhcs r1, [r3, # DATA_OFS]; Scrivi dati strhcc r2, [r3, # DATA_OFS]; Scrivi dati strb r4, [r3, # CLOCK_SET_OFS]; Imposta l'orologio alto strb r4, [r3, # CLOCK_CLR_OFS]; Imposta l'orologio basso ITMI strhmi r1, [r3, # DATA_OFS]; Scrivi dati strhpl r2, [r3, # DATA_OFS]; Scrivi dati strb r4, [r3, # CLOCK_SET_OFS]; Imposta l'orologio alto strb r4, [r3, # CLOCK_CLR_OFS]; Imposta l'orologio basso
Non è esattamente la cosa più veloce del mondo. Eliminare le scritture alle istruzioni di impostazione / cancellazione dell'orologio sarebbe di aiuto. La mia ipotesi sarebbe che non esiste un buon modo indipendente dall'architettura per eliminare entrambe le scritture di clock, ma potrebbe esserci un modo abbastanza comune che consentirebbe di eliminarne uno (ad esempio molti chip potrebbero avere un contatore / PWM che potrebbe essere fatto per impulsare un'uscita brevemente in risposta a una singola operazione di memorizzazione in memoria).
L'uso della porta SPI e l'aggiunta di hardware per il clock di un pixel per bit accelererebbe notevolmente l'accesso al display. Se si utilizza un display senza mascheramento e trasparenza, il CPLD dovrebbe includere un contatore di indirizzi e per ogni pixel eseguire il clock di una parola di dati pixel oppure un comando set-address per la posizione del pixel seguente (per la quale sarebbe necessario un contatore ). Al contrario, se un display avesse mascheramento e trasparenza, tutto ciò che dovrei fare sarebbe avere il CPLD in grado di supportare una modalità in cui, dopo che aveva avuto un clock di 16 bit, ogni bit aggiuntivo avrebbe sincronizzato una parola di dati sul display con il LSB che traccia il pin SDI (potrebbe non essere nemmeno necessario utilizzare un CPLD - solo alcuni normali chip logici). Vorrei impostare il colore della trasparenza sul colore che voglio scrivere ma con LSB capovolto.
Non voglio inventare un bellissimo design che si basi su mascheramento e trasparenza e poi scoprire che gli unici display con tali caratteristiche hanno un tempo di consegna di 30 settimane. D'altra parte, se tali display sono adatti e rimangono ampiamente disponibili da molti fornitori, non voglio lasciare che la paranoia sulla disponibilità mi spinga a utilizzare un design inferiore.
