Atmega 368 come convertitore seriale/parallelo per GLCD

Premetto che non lo chiedo per risparmiare ma perchè così eviterei di usare un microcontrollore nel mio folle progetto XD
Stavo pensando se fosse possibile usare il cuore di arduino come convertitore seriale/parallelo per display lcd grafici...insomma da usare al posto di questo.
Ho visto che quello sparkfun funziona sempre con un atmega, e sfruttando le librerie GLCD e serialGLCD in teoria basterebbe usarlo per tradurre i comandi.
Per esempio per fare un rettangolo dovrebbe leggere il comando

drawBox(x1,y1,x2,y2,z);

e "semplicemente" tradurlo in

GLCD.DrawRect(x1, y1, x2, y2, z);

E' una cosa fattibile o è molto complessa?

E' fattibile ed è complessa. In pratica, lato master devi creare una lib che trasformi le funzioni grafiche in comandi da spedire allo slave, lato slave devi crearti il codice che legga dal canale di comunicazione i dati seriali e ne esegua le funzioni. Ad esempio il tuo comando DrawBox potrebbe diventare il comando con codice byte $A0, al quale far seguire i 4 angoli del rettangolo. Spedisci i dati con un byte di inizio trasmissione ed uno di fine. Lato slave, leggi cosa arriva, controlli se sono dati corretti e poi esegui il comando $A0, che sarà il richiamo ad una funzione della lib.

In effetti la libreria SerialGLCD fa proprio quello che hai suggerito, andando a vedere i codici si legge una serie, ad esempio il nostro box è trattato così:

void serialGLCD::drawBox(int x1, int y1, int x2, int y2, int z) 
{	/* Draws a rectangle starting from x1,y1 to x2,y2. z=1 for draw, z=0 for erase.
	 Example: lcd.drawBox(10,10,20,20,1);
	 */
	Serial.write(0x7C);
	Serial.write(0x0F);
	Serial.write(x1);
	Serial.write(y1);
	Serial.write(x2);
	Serial.write(y2);
	Serial.write(z);
}

Quindi non fa altro che spedire in seriale i byte necessari, prima uno di abilitazione (il byte 0x7C c'è sempre in tutti), poi quello relativo alla funzione (0x0F) e poi quelli delle variabili.
A questo punto mi pare che basterebbe posizionare tutti i byte su delle variabili e decidere la funzione di gestione lcd semplicemente con uno Switch / Case no?
Però ho poco chiaro la funzione avaible() (che dovrebbe indicare il numero di byte trasmessi giusto?!) e Serial.read e non ho capito in fase di programmazione quale sia la sintassi per leggere i singoli byte ed associarli ad una variabile...

Altra cosa, usando le porte tx e rx non si può collegare più il sistema a computer tramite usb giusto? Ma nel caso di un mega, che ha più porte di comunicazione basterebbe lasciare libere le tx e rx e usare le altre con Serial"n" invece che Serial vero?

Artal:
A questo punto mi pare che basterebbe posizionare tutti i byte su delle variabili e decidere la funzione di gestione lcd semplicemente con uno Switch / Case no?

Sì, esatto. Analizzi il comando e poi lo esegui.

Però ho poco chiaro la funzione avaible() (che dovrebbe indicare il numero di byte trasmessi giusto?!) e Serial.read e non ho capito in fase di programmazione quale sia la sintassi per leggere i singoli byte ed associarli ad una variabile…

Available ti dice se e quanti byte sono arrivati sulla seriale. Se ti serve oppure no lo decidi tu.
Per trattare un byte letto da seriale come byte non devi fare altro che leggerlo ed assegnarlo ad una variabile di tipo “byte”.

Altra cosa, usando le porte tx e rx non si può collegare più il sistema a computer tramite usb giusto? Ma nel caso di un mega, che ha più porte di comunicazione basterebbe lasciare libere le tx e rx e usare le altre con Serial"n" invece che Serial vero?

Esatto. Usi la Serial1, per esempio, o un’altra seriale. Oppure anche l’I2C, se il progetto lo fai tu. Io tempo fa feci un sistema con un Tiny84 che mi pilotava un LCD classico ed i dati li riceveva via I2C, appunto.