Incorporato LCD driver carattere “Smart”. E 'questa una buona idea?

Question

Ho un progetto integrato che sto lavorando su, e attualmente sto codifica il driver LCD carattere.

Al momento, il driver LCD supporta solo la scrittura "stupido". Ad esempio, supponiamo che la linea 1 ha qualche testo su di esso, e mi fanno una chiamata alla funzione che scrive la linea. La funzione sarà semplicemente cercare l'inizio della linea e scrivere il testo (più abbastanza spazio bianco per cancellare ciò che è stato scritto lo scorso).

Questa è cosa buona e giusta, ma ho la sensazione che è terribilmente inefficiente a volte, dal momento che alcune linee sono semplicemente: "Alcuni-lettura: un po 'di valore"

Invece di "forza bruta" sostituire l'intera linea, ho voluto sviluppare un codice che avrebbe capire il modo migliore per update le informazioni sul display LCD.

(solo come sfondo, ci vogliono 2 byte a cercare in qualsiasi posizione char. Posso quindi iniziare a scrivere la stringa)

La mia idea era di avere prima un ciclo. Questo ciclo si confronta l'input per l'ultima scrittura, e così facendo, sarebbe coprire due cose:

A: raccogliere tutte le differenze tra l'ultima scrittura e l'ingresso. Per ogni segmento contiguo (sia esso uguale o diverso) aggiungere due byte per il numero di byte. Questo viene fatto riferimento in B per determinare se stiamo sprecando la larghezza di banda di serie.

B: L'anello sarebbe determinare se questa è veramente una cosa intelligente da fare. Se si finisce per utilizzare più byte per aggiornare la linea che a "forza bruta" la linea, allora dovremmo tornare e lasciare che il metodo della forza bruta assumere. Dobbiamo uscire dalla funzione di scrittura intelligente, non appena questa condizione è soddisfatta per evitare di sprecare tempo.

La parte successiva della funzione avrebbe preso tutte le differenze, cercare del carattere richiesto sul display LCD, e scriverle.

Quindi, se abbiamo una stringa come questa già sul display LCD: "Temp corrente: 80F" e vogliamo aggiornarlo a "Temp attuale: 79F"

La funzione passerà attraverso e vedere che ci sarebbe voluto meno larghezza di banda semplicemente cercare la "8" e "79". Il "7" riguarderà il "8" e "9" riguarderà il "0". In questo modo, non perdete tempo a scrivere l'intera stringa.

Ti sembra un'idea pratica?

Answer 1

Non ha alcun senso per ottimizzare questo. Trasmissione 20 byte a 9600 baud batte hardware 21 millisecondi. E prende il software pochi microsecondi. abbastanza veloce per essere in grado di aggiornare la visualizzazione più velocemente di quanto l'occhio umano potrebbe mai percepire di un fattore 2. E non è come è necessario il "larghezza di banda", non v'è alcun dato aggiuntivi che mi viene in mente che si 'd vogliono multiplex sul canale seriale.

Answer 2

Supponendo che l'offset nel display auto-incrementi ed è una singola scrittura di uscita ogni personaggio successivo, sarei propenso a dare semplicemente l'intera riga del display ogni volta a meno che non ci sia un problema di prestazioni specifico che si sta cercando di risolvere . vale a dire:. ottimizzazioni non necessari sono mal di testa potenziali futuri di manutenzione e il vostro tempo "ottimizzare" sarebbe meglio spesi per qualcosa che in realtà influenzano le prestazioni dell'intera applicazione

Nota: se l'aggiornamento del display è in realtà un'applicazione che colpisce problema di prestazioni, probabilmente hanno un senso di quanto più veloce ha bisogno di essere .... allora (e non noi) può essere la vostra guida a quanto ottimizzazione è sufficiente.

Answer 3

L'implementazione si sta progettando sembra essere troppo complesso per il problema. Tutto il necessario confrontando può effettivamente rallentare il funzionamento, se il processore non è veloce.

Se avete solo bisogno di aggiornamento per esempio, il valore della temperatura, si deve solo aggiornare il valore di temperatura e ignorare i testi fissi. È necessario avere le coordinate in memoria per ogni campo che deve essere aggiornato. Poi basta spostare la posizione di scrittura a quella posizione e scrivere il valore. E 'così che io di solito faccio.

Se l'aggiornamento dello schermo è ancora troppo lenta, si può considerare l'utilizzo di linguaggio Assembly. Ad esempio, alcuni anni fa ho fatto un software per un dispositivo di tipo orologio con display LCD a matrice di punti. L'aggiornamento del display è troppo lento (quasi un secondo per aggiornare l'intero display per esempio durante lo scorrimento), così ho scritto appena la routine livello più basso nel montaggio (sostituzione di circa 20 righe di C con 30 linee di assemblaggio). La funzione risultante era metà delle dimensioni e 3 volte più veloce del funzionale in C, e ora la velocità di aggiornamento del display era adeguata.

Answer 4

  

In questo modo, non perdete tempo a scrivere   l'intera stringa.

Si dovrebbe non sprecare molto tempo a tutti, sicuramente inferiore al tempo che ci vuole per fare tutto questo controllo.

Qual è il collegamento con il display LCD? SPI / I2C / parellel?

Qualunque cosa sia, se DMA è supportata dal SoC sull'interfaccia, usarlo.

In caso contrario, non si dovrebbe essere in attesa intorno tra TX bytes, soprattutto se l'orologio di istruzioni del processore è molto più elevato rispetto l'orologio del collegamento dati. Questo è probabilmente vero, come la maggior parte di visualizzazione personaggio di cui ho lavorato hanno bassi specifiche di clock max.

Usa sia una routine di interrupt per gestire l'invio di ogni byte o utilizzare un approccio 'ibrido' se è possibile controllare di routing di interrupt (si sta facendo questo per il risparmio energetico). C'è una scrittura interessante fino qui

Answer 5

Per una visualizzazione dei caratteri, questo tipo di ottimizzazione aggiornamento è ciò che la biblioteca curses era tutto. Indietro nel giorno, quando abbiamo parlato a grandi computer con terminali stupidi e linee telefoniche a 1200 baud o meno, era spesso difficile per aggiornare lo schermo abbastanza veloce per fare programmi di sentire interattivo attraverso il collegamento modem lento. La libreria curses reso pratico mantenendo una cache di quello che dovrebbe essere sullo schermo dell'utente e l'invio di un vicino al numero ottimale di comandi di movimento e cancelli intervallati da caratteri normali per la visualizzazione. Si richiedeva che il supporto del terminale qualche forma di posizionamento del cursore.

Il maledice vita libreria su in un paio di forme, e ncurses , per esempio , è ben noto, open source e sotto licenza GPL.

In linea di principio, si potrebbe adattare ncurses di parlare con il controller display e lasciar fare tutto il duro lavoro.

La questione aperta è se sia valsa la pena. A 9600 baud, è possibile inviare 960 caratteri al secondo. Che è abbastanza veloce per ridipingere completamente una linea 4 da 20 colonna LCD 12 volte al secondo. Quindi a meno che non si esegue in un PIC o ATtiny in cui potrebbe essere necessario attuare tale UART nel software e la necessità dei cicli di effettivamente fare qualcosa di utile, non è probabile che sia poco vantaggio di essere troppo intelligente.

Detto questo, è ancora di solito senso di dipingere il testo fissato una volta, e solo aggiornare i valori visualizzati come cambiano.

Answer 6

Testo modalità LCD

Sono d'accordo con gli altri, se si sta scrivendo in modalità testo, non c'è davvero nessun punto di fare questo a livello di carattere. Il tempo di elaborazione necessario per fare i calcoli è probabile che prendere fino a quando il tempo per scrivere in realtà le cose.

Inoltre, a livello di singolo personaggio masticare attraverso un po 'di memoria, come avrete bisogno di tamponare ciò che è correntemente visualizzata (vale a dire ciò che è stato scritto lo scorso).

È possibile semplificare il processo scissione lo schermo in sezioni (linee tende ad essere più convenienti) e poi flagging quando che i cambiamenti di linea. Ciò è particolarmente utile se si desidera scrivere in un buffer di memoria dello schermo, e la sincronizzazione in un secondo momento (in un interrupt a tempo, per esempio).

Riduzione del disegno

Invece di lasciare questo fino al driver di raggiungere, si potrebbe diminuire il tempo di scrittura a livello di applicazione, garantendo solamente scrive la roba che i cambiamenti. Ciò potrebbe essere realizzato attraverso la designazione cellule valore specifico, in sostanza, nel modo seguente:

char text[50];
int val;
...
lcd_print("The count is ", 0, 0); // Print static text at the coords (0,0)
sprintf(text, "%d", val);
lcd_print(text, 0, 13); // Print changing text at (0,13)
...
sprintf(text, "%d", val);
lcd_print(text, 0, 13); // Print changing text at (0,13)

E non:

char text[50];
int val;
...
sprintf(text, "The count is %d", val);
lcd_print(text, 0, 0); // Print all text at the coords (0,0)
...
sprintf(text, "The count is %d", val);
lcd_print(text, 0, 0); // Print all text at the coords (0,0)

Modalità grafica LCD

D'altra parte, se il processo di scrittura è piuttosto costoso, come la mia (~ 20 byte, disegnando un personaggio in modalità grafica), il tempo quindi salvare su una base personaggio sarebbe utile. Ci sono due schemi che è possibile utilizzare. Il primo è come lei, ma come si potrebbe anche prendere in considerazione (se si utilizza la modalità grafica) il concetto di buffer una linea di pixel orizzontali attraverso la riga di testo.

Scrivendo ogni carattere su una base per carattere richiede spostando manualmente il cursore di scrittura alla linea di pixel, supponendo che il disegno orizzontalmente, e quindi verso il basso. Questa fase potrebbe essere rimosso scrivendo tutte le linee superiori di tutti i caratteri su una riga di testo, o meglio un sottoinsieme modificato (cioè "ABC" e poi separatamente "I" in "XXXDEFGHX" -> "ABCDEFGHI").

Naturalmente, l'esatta salvataggio utilizzando il secondo metodo dipenderà quante righe di pixel costituito l'altezza di un carattere. I più linee, maggiore è il risparmio (perché ti viene richiesto di spostare il cursore più volte).