Newsgroup: it.hobby.elettronica.digitale
Titolo: usart PIC

Salve!
La usart hardware dei Pic  (sto usando un Pic 16F877A) come si comporta 
all'eventuale arrivo di un carattere e non si prevede di usare un apposito 
interrupt per gestire il tutto? cioe' puo' accadere quanto segue:
Arrivo di un normale carattere oppure carriage return (13ASCII) sena che il 
software stia testando la usart
viene eseguita una routine per leggere la usart, a questo punto vado a 
leggere anche cose spurie cioe' cose che sono arrivate prima che una 
apposita routine gestisse il tutto?  la usart hardware dei pic ha un buffer 
che aspetta di essere svuotato? 

 ha scritto nel messaggio 
news:49eb5b32$0$6835$5fc...@news.tiscali.it...

Il pic che hai citato dispone di una fifo hw di 2 caratteri (+ un terzo del 
quale sia eventualmente già iniziata la ricezione).
Ciò significa che al raggiungimento del primo carattere è settato dall'hw il 
bit RCIF.
Ad ogni lettura di RCREG svuoti il bufffer di ricezione di un carattere.
Quando il buffer è vuoto RCIF è di nuovo azzerato dall'hw.
Quindi se hai un ciclo di scansione di RCIF sufficientemente rapido 
potrestti anche evitare di gestire la ricezione in interrupt (anche se è 
consigliato farlo per sicurezza di non perdere caratteri).
Se quindi vuoi essere sicuro che il buffer di ricezione sia vuoto prima di 
iniziare una particolare fase, devi effettuare un controllo di RCIF.
Se è alto, effettui una lettura ripetuta di RCREG fino a quando RCIF va a 
zero. 


Fino a poco tempo fa usavoil basic della melabs per fare semplici programmi 
che girassero sui pic, la seraile la gestivo senza alcun problema anche 
senza interrupt.
Ora sto cercando di imparare il C, gia' ora capisco delle potenzialita' e 
sopratutto la portabilita' intesa come il fatto che un programma scritto per 
Micro ATmel possa essere riscritto senza tanti problemi per un altro micro.
Sto usando il compilatore della CCS, per settare la seriale l'istruzione e' 
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7) succede che anche provando 
gli esempi della stessa CCS e si cerchi di forzare la seriale tenendo 
inviando ad esempio il carriage return senza fermarsi dopo un po si blocca 
la seriale, facendo alcune ricerche sul loro forum consigliano di usare 
l'istruzione con l' aggiunta di ERRORS cioe' #use rs232(baud=9600, 
xmit=PIN_C6, rcv=PIN_C7, ERRORS),  probabilmente usando un buffer in una 
funzione di interrupt non si arrivi al blocco.
nell' applicazione che stavo scrivendo che per ora non usa interrupt ho 
notato che c'e' una fase dove non si va a leggere la usart, ma se su questa 
arriva un carattere ovvero un byte, non appena si passa alla lettura arriva 
questo carattere, quindi volevo capire se e' il compilatore che creando le 
routine ci mette qualcosa di suo oppure il Pic16F877A ha qualcosa di 
hardware tipo un buffer di almeno 1 byte.
tanto per capirci includo il programma che sto testando:
#include <16F877a.h>
#include <string.h>
#include <input.c>
#define  STRING_SIZE   51
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
#define red_led pin_b5
void tipo_chiamata(char *chiamata)//, char *prima)   //prototipo di funzione
void main() {
char input_str[STRING_SIZE];
while(true)
{
for (a=0; a<4; a++)
{
get_string(input_str,STRING_SIZE);     // gets the string x4
}
printf("ath\r");
tipo_chiamata(input_str);
}
}
void tipo_chiamata(char *chiamata)
{
delay_ms (2000);
output_low (red_led);
printf("\n\nil valore di chiamata e' %s\n\n", chiamata);
delay_ms (1000);
output_high (red_led);
}
Succede che dopo aver immesso per 5 volte una stringa e dato invio si va 
alla funzione void tipo_chiamata(char *chiamata) che stampa la stringa 
arrivata per ultima, questa funzione dura circa 3 secondi gisuto per far 
accendere e spegnere un led in questa fase (accensione stampa della stringa 
spegnimento del led) se digito dei caratteri sulla tastiera, al ritorno di 
questa funzione avro' sul video il primo carattere che avevo digitato, 
aggiungo che in questa fase cioe' dell' immisione di caratteri durante lo 
svolgimento della funzione void tipo_chiamata(char *chiamata) se non avessi 
aggiunto ERRORS alla riga di inizializzazione della seriale avrei bloccato 
la seriale.
Questa e' la funzione get_string(char* s, unsigned int8 max) che fa parte 
del header input.c
void get_string(char* s, unsigned int8 max) {
   unsigned int8 len;
   char c;
   --max;
   len=0;
   do {
     c=getc();
     if(c==8) {  // Backspace
        if(len>0) {
          len--;
        putc(c);
        putc(' ');
        putc(c);
        }
     } else if ((c>=' ')&&(c<='~'))
       if(len<=max) {
         s[len++]=c;
         putc(c);
       }
   } while(c!=13);
   s[len]=0;
}

 zero.
Grazie per l'ottima spiegazione, che mi ha fatto capire dove puo' essere il 
problema che ho, cioe' credo che volendo lasciare il firmware cosi' l'ho 
scritto ora senza usare interrupt sulla seriale, devo testare RCIF che 
tramite il compilatore che sto usando e' kbhit() se dovesse essere 1 allora 
vado a leggere RCREG tramite getc cosi' da svuotare il buffer e  mettere a 0 
RCIF, in pratica dovrei fare questo:
int8 carattere;
if(kbhit())
carattere= getc();
Volevo chiederti una cosa che e' scritta di sicuro nei datasheet :-) ma noto 
che sei preparato quindi ne approfitto :-) quesra sorta di buffer e' 
presente anche nei Pic piu' piccoli dotati di usart hardware come puo' 
essere un Pic16F628A? 

 essere un Pic16F628A?
Il 'buffer' sul manuale è chiamato FIFO.
Quindi ciò che viene esplicitato come two deep FIFO, significa appunto che 
il buffer di ricezione è di 2 bytes + quello che è ancora in fase di 
ricezione (se il buffer non è svuotato di almeno un byte, il carattere in 
ricezione andrà paerso).
Da quanto ne so, ed anche per le ragioni di compatibilità che ed 
interscambio che accomunano i pic, tutte le seriali hw hanno almeno 2 bytes 
di buffer hw.