Newsgroup: it.hobby.elettronica.digitale
Titolo: Stranezze.....

viod main ()  {
            char ore[4],minuti[4],secondi[4];     //Variabili che 
conterranno i dati
            Time_wr(12,31);                             //Imposta in un 
PCF8593P un orario (12:31)
            LCD_Init(); 
//PredisponePORTB a pilotare un LCD
            LCD_Cmd(_LCD_Clear);                //Pulisce il Display
            LCD_Cmd(_LCD_Cursor_Off);       //Spenge il cursore
    while(1)   {                                                   //Inizio 
ciclo senza fine
                ByteToStr(Time_rd(2),secondi);      //Converte il valore da 
BCD a Stringa
                ByteToStr(Time_rd(3),minuti);        //               " "
                ByteToStr(Time_rd(4),ore);             //               " "
                LCD_Out(1,1,ore);                           //Visualizza le 
ore
                LCD_Out(1,4,minuti);                      //Visualizza i 
minuti
                LCD_Out(1,7,secondi);                    //Visualizza i 
secondi
                LCD_Out(2,3,"Realclock");             //Messaggino
                                         }       //Fine ciclo
}
Buonasera al NG, volevo mostrare questo frammento di codice che, se 
sottoposto al compilatore MikrC PRO for PIC 2009 (ma lo faceva anche con il 
'vecchio' MikroC compiler versione 8.2.0.0, in pratica l'ultima release 
prima dell'uscita del PRO), mi genera con successo un .hex che in questo 
ordine di compilazione funziona, in pratica Time_wr imposta i parametri di 
ore/minuti in un clock I2C PCF8593 e successivamente, nel ciclo while, li 
legge continuamente e li visualizza su un LCD. Il problema sta nel fatto che 
se nell'IDE la funzione Time_wr la sposto subito prima del ciclo while, in 
pratica dopo LCD_Cmd(_LCD_Cursor_Off), il compilatore genere il file .hex 
correttamente senza errori ma, una volta inserito nel PIC, sul display non 
compare pi� nulla. Premesso che tutte le impostazioni e dichiarazioni 
precedenti e seguenti a questo frammento sono corrette, per quale motivo 
spostare una funzione che verr� eseguita una sola volta dopo il reset o 
prima alimentazione (e comunque non ripetuta nel ciclo while), in base alla 
sua posizione possa pregiudicare la funzionalit� aspettata??E' probabile che 
il compilatore richieda una priorit� tra le funzioni utente e quelle gi� in 
libreria o mi sono perso qualcosa per strada?Ho programmato in C 
applicazioni DOS , ma questo tipo di problemi (ovvero dover mettere in un 
certo ordine funzioni che peraltro non interagiscono con altre), non mi era 
mai capitato....
PIC 16F877A-8 Mhz clock
Grazie - Roberto 

 sua posizione possa pregiudicare la funzionalità aspettata??
cut...
Può darsi che vi sia un problema nelle temporizzazioni.
Se l'I2C è gestita su interrupt, la funzione Time_wr potrebbe creare
un header da spedire e passare alle prossime funzioni LCD
immediatamente, ancor prima che tutto il pacchetto sia spedito.
La durata delle funzioni LCD permette l'esaurirsi dello stream di dati
e l'I2C risulta libera per le operazioni di read Time_rd che verranno
eseguite correttamente.
Ponendo le funzioni Time_wr e Time_rd troppo vicine, può accadere che
l'inizio della seconda crei un flush della prima, soprattutto se il
buffer dei dati è il medesimo.
Si genera così una serie di errori che di sicuro impallonano il time-
keeper.
Dovresti verificare se esiste una funzione in grado di determinare la
disponibilità dell'I2C, una sorta di "READY".
Altrimenti prova ad infilare tra le funzioni adiacenti una pausa di
alcune decine di millisecondi per verificare la mia ipotesi.
Crea la funzione: void donothing(void) e richiamala 1000 volte.
Fammi sapere.
In assembler questioni di questo tipo sono ordinarie.
Ciao.
Piccio.

Piccio.
Ciao e grazie 

 quelli del calendario...
Questa non l'ho capita.
p.s. Su schede pi� complicate spesso e volentieri al power up si aspetta 
anche 1 secondo o due per essere sicuri della stabilizzazione di oscillatori 
(al quarzo) e power up delay di altre periferiche.
p.p.s. Stai molto attento quando utilizzi librerie esterne: sarebbe sempre 
bene poterne vedere il sorgente o comunque avere una buona documentazione, 
cosa che non va molto d'accordo con la filosofia di quelli della 
Mikroelektronika
p.p.p.s. Non sarebbe una cattiva cosa giocare con quel minifirmware per 
aggiornare il display solamente quando ci sono differenze. Sacrifichi un 
pochetta di ram ma guadagni molto sulla velocit� di esecuzione del codice 
visto che sei in condizione di I/O bound
Ciao
CG