|
|||||
sono molto più comprensibili che:
anche se il risultato della compilazione è identico. In particolare si potranno provare i codici sopra 0x7F: i caratteri presentati dipenderanno dal set del character generator (CG) integrato nel controller del display. Potete anche variare la frequenza dell' oscillatore del PIC; sul campione provato, il driver con le routine di tempo calibrate per un clock di 4 MHz funziona anche se si alza il clock a 16MHz, il che vuol dire ridurre a 1/4 tutti i ritardi. Però, aumentando ulteriormente il clock, il sistema comincia presentare problemi per via sei tempi troppo ridotti. Oltre i 30 MHz di clock il display non risponde più correttamente. Inoltre, un altro display di costruzione decisamente più anziana, a 16 MHz cessa di funzionare. Provate con il vostro display quale è la tolleranza e provate a verificare quali tempi devono essere adeguati per far riprendere il funzionamento. Questo filmato presenta una variazione del programma di test che effettua le seguenti operazioni:
Si osserva bene la differenza di esecuzione ai diversi clock, dato che i ritardi di tempo, calcolati per 4 MHz, vengono dimezzati ad ogni step; nel caso di scrittura senza ritardo, le due linee appaiono quasi istantaneamente, indice che questi display sono "lenti", ma solo se non comparati con le possibilità percettive dell' osservatore. Il sorgente di questa versione è qui.
Volendo ottenere un oggetto adatto ad essere scritto nella memoria programma del PIC, si dovrà aggiungere nel sorgente la modifica per un CONFIG adeguato all' esecuzione stand alone, come visto nell' esercizio precedente. Nei prossimi esercizi vediamo come migliorare il driver rispetto al clock del microcontroller, come utilizzare il display per comunicazioni a 4 bit e senza lettura di BF. Poi potremo creare una interfaccia seriale SPI-like per ridurre al minimo le connessioni tra display e microcontroller.
|
Copyright © afg. Tutti i diritti riservati. |