ESERCITAZIONE # 12b

La routine che esegue la scrittura verso il modulo LCD è comune alle operazioni per dati o comandi.
In effetti, la procedura è identica: la destinazione come dato o come comando è impostata dallo stato del pin RS.
Una serie di condizionamenti #if-#else- #endif consente di compilare la versione adatta per l' uso della linea RW oppure no. 

Nel primo caso si verifica lo stato del flag BF prima di accedere in scrittura. Questo è sensato in quanto il comando precedente è stato probabilmente già eseguito e quindi la routine di check del flag BF uscirà molto rapidamente.

Nel secondo caso, si effettua l'operazione, poi si aggiunge un tempo standard di attesa del completamento del comando. Questo è stato dedico in quanto, tra una scrittura random di un dato o di un comando e la successiva è possibile che trascorrano più dei 37-100 us di esecuzione, ma solitamente sul display si scrivono sequenze di comandi e dati successivi; inoltre i comandi con tempo di esecuzione lungo impiegano millisecondi. Quindi, non potendo verificare lo stato del flag di busy, occorre avere la certezza che l' operazione precedente sia conclusa prima di lanciarne un'altra, altrimenti, al minimo, si rischia che il dato o il comando vadano persi.

In uscita, la routine riporta a livello basso tutti i pin di interfaccia; questa non è una operazione inutile e non appesantisce particolarmente il firmware, dato che impiega solamente 2 o 3 cicli addizionali (a 4 MHz di clock sono 2-3 us in più, mentre la sola attesa di conclusione di un comando vale 37-100 us). E', invece, indispensabile per conoscere con certezza lo stato delle linee di I/O utilizzate per il display nel caso in cui queste siano utilizzate anche per altre funzioni, come ad esempio una tastiera.

Viene utilizzata una locazione di RAM , LCDbuf, come buffer.

Se la linea RW non viene utilizzata, occorre impiegare in alternativa dei tempi standard di attesa di fine comando.
I tempi sono in funzione del comando inviato. Comandi con codice minore di 3 necessitano di un tempo di esecuzione maggiore di quello degli altri.
Se si tratta di dati, il tempo necessario è quello minimo.

L' operazione di lettura del flag BF ha una struttura identica a quella di lettura generica dal modulo LCD, quindi le routine sono intersecanti.

• LCDRdRam ritorna con il contenuto della cella di RAM letta in WREG.
• LCDRdBfa ritorna con l' indirizzo corrente e lo stato di BF in WREG. Questa routine non è bloccante, ovvero viene   rilasciata non appena effettuata la lettura.
• LCDChkBusy ritorna con l' indirizzo corrente e lo stato di BF in WREG. Questa routine è bloccante, ovvero non viene rilasciata fino a che il flag BF non è valido.

Va notato che qui è stato aggiunto un punto che solitamente è trascurato, se non del tutto ignorato. Tra l' abilitazione del controller e la possibilità di leggere dati stabili sulle linee di uscita è necessario un certo tempo, TDDR. Si tratta di un tempo dell' ordine dei 260-400ns, che nel caso di PIC con clock bassi sono ininfluenti, ma che con clock elevati (e cicli di istruzione da 100 ns) possono diventare sensibili. In particolare, i tempi di risposta del controller aumentano con il diminuire della tensione di alimentazione. e di questo va tenuto conto.
Certamente con un 16F84 a 4MHz i cicli WHILE non sono necessari, ma va tenuto presente che questi sono presento SOLO nel sorgente: durante la compilazione l' Assembler li prenderà in considerazione, inserendo i nop sottintesi  SOLO quando il clock del processore sarà tale da richiederlo. Negli altri casi non verrà inserito nulla. Quindi, questa struttura a cicli WHILE non è di alcun peso per il risultato della compilazione, anzi, costituisce un automatismo che lo adatta alle esigenze reali dell' hardware.

Per contro sono stati inseriti vari nop addizionali allo scopo di stabilizzare lo stato delle lineen di comunicazione tra PIC e modulo LCD; questo si rende necessario nel caso di cablaggi lunghi. Potranno essere rimossi nel caso di distanza minima, ma conviene non eliminarli, in quanto, rispetto al ciclo di accesso al modulo, influiscono in maniera trascurabile.

Le routines di scrittura fanno uso di una macro

Potrebbe parere del tutto inutile dichiarare una macro pari ad una linea di istruzione, ma questo serve per unificare la struttura delle varie versioni del driver, come vedremo in seguito.