che limiti ha il modulo USART interno del pic18F4550?

ho implementato il "minimo sindacale" per restare in attesa di dati dalla seriale e scrivere sul display quello che ricevo, collegando la Freedom II al pc e utilizzando RS232 Terminal.
Scrivendo caratteri da tastiera tutto funziona correttamente, però se invio tramite la funzione "send message" una parola di 4 o più caratteri, in ricezione ne ricevo solamente tre e poi la ricezione rimane bloccata, mentre riesco a continuare ad inviare dati dal pic al pc e leggere correttamente sul terminale.
Ci sono dei limiti della seriale o sbaglio qualcosa nel codice di ricezione del pic?

Ste

Ciao, anche io ho sto "sperimentando" le capacità dell'USART interno, con risultati analoghi ai tuoi. Mi sembra anche che la questione sia dibattuta in altro topic www.laurtec.it/forum/17-programmazione-m...mi-18f2550-rs232-c18

Da quello che ho visto, sembra che il buffer della USART si "intasi" , se i dati vengono inviati troppo velocemente.

Stasera faccio qualche altra prova



Andrea

Prova a vedere anche questo topic
www.laurtec.it/forum/17-programmazione-m...18f1320-a-pic18f4550

Nel progetto del campanile per verificare l' overflow del buffer usart avevo scritto questo codice

//*********************CONTROLLO MODULO GSM (USART)
if (RCSTAbits.OERR){
Beep (100,3);
ClearLCD();
WriteStringLCD("ERRORE USART GSM");
Line2LCD();
WriteStringLCD("BUFFER OVERFLOW!");
delay_ms (2500);
RCSTAbits.CREN =0;
RCSTAbits.CREN =1;
}

Ciao
Renato

Ciao,

in effetti devi fare attenzione a non fare troppe cose tra un byte e l'altro altrimenti hai un buffer overflow.

Se non hai fretta non eccedere con la velocita'...
...chi va piano va sano e va lontano!

Saluti,

Mauro

@andreamelis: Grazie. Il link che mi hai suggerito fa riferimento ad un problema relativo al caricare un file .hex sul pic senza farlo direttamente da mplab. Comunque sia, teniamoci aggiornati su questo topic, rispetto alle varie prove che faremo e a cosa ne trarremo.

@fer_ver: Grazie. E' all'incirca il mio problema, nell'altro topic suggerisci di...
"In alternativa, per ovviare a questo problema, potresti usare l'interrupt"
in che modo l'interrupt riesce ad essere più veloce? si accorge subito del dato e riduce i tempi di "svuotamento"?
tra le varie prove mi sa che avevo comunque provato anche con l'interrupt al posto del polling e aveva ugualmente dei limiti. La capacità dell'usart e i tempi immagino li trovo sul datasheet del pic..il primo posto dove bisogna sempre guardare..
Appena ho un attimo ci butto dentro il tuo controllo..grazie ancora.

@Mauro: con le prove da pc il baud-rate è a 9600 penso abbastanza piano visto che mi dicevi che solitamente usi 19200 o 105200 (quando hai fretta!), però in effetti già lo scrivere sul display mi fa perdete tempo, adesso provo a memorizzare tutto in un array e poi stampare a video per vedere se migliora.

L'idea iniziale era magari trasmettere una stringa con più informazioni di seguito, pensavo si mettessero in coda e mano a mano che leggevo avanzavano, a quanto pare se arrivano informazioni e nessuno le legge..vanno perse...o sto dicendo cavolate?

Il "problema" vero e proprio è quando scrivo da android e passo per il bluetooth...dovrò rallentare in java. Vi tengo aggiornati.

Ste