Comunicazione seriale tra PIC : HELP

Ciao Mauro,
Ancora grazie per la gentilezza delle tue risposte.
La tua risposta è chiarissima, ma ti pongo un quesito che corrisponde ad un dubbio sottile: E' vero quello che tu dici che il carattere successivo al primo non parte fin quando TRMT non è ridiventat '1'. MA..

allegato:


Ma secondo questo grafico la trasmissione in sequenza di più caratteri non fa mai diventare '1' TRMT. E quindi non c'è sospensione tra il 1° e il 2° 3° nella trasmissione. A questo punto una successione di due o più istruzioni di ricezione potrebbe causare? piccoli anticipi/ritardi? e quindi errori di ricezione?

Ho il dubbio di non essere stato abbastanza chiaro chiaro!

Le mie istruzioni costringono la trasmissione ad essere sospesa per un istante fino a quandoTRMT non ridiventa 1. E solo allora esco dalla Funzione passando alla successiva putch() ??
In precedenza mettevo un delay() dopo putch() e TMRT ritornava ad '1', e questo equivale alla mia (**)
void putch (unsigned char byte) {
while (!TRMT) continue;
TXREG=byte;
while(!TRMT) continue;(**)
}
Riconosco che la tua osservazione è pur VERA nel senso che l'inizio della putch() successiva contiene lo stesso ciclo di attesa. Non so che dire (Se io elimino dal codice la modifica (**) riscontro nuovamente gli errori!). In sostanza la mia istruzione NON cambia la logica del codice se NON inserendo brevi ritardi causati dal test ulteriore su TRMT!

Se ciò che dico è una stupidaggine, correggimi!


Mi è sorto anche il dubbio, leggendo il data Sheet relativo alla RICEZIONE, che si debba modificare qualcosa nella funzione di Ricezione gestendo i Framing error? Vedi il paragrafo seguente :
16.1.2.5 Receive Framing Error
Each character in the receive FIFO buffer has a corresponding framing error Status bit. A framing error indicates that a Stop bit was not seen at the expected time. The framing error status is accessed via the FERR bit of the RCSTAx register. The FERR bit represents the status of the top unread character in the receive FIFO. (*)Therefore, the FERR bit must be read before reading the RCREG.x
The FERR bit is read-only and only applies to the top unread character in the receive FIFO. A framing error (FERR = 1) does not preclude reception of additional characters. It is not necessary to clear the FERR bit.
Reading the next character from the FIFO buffer will advance the FIFO to the next character and the next corresponding framing error.
The FERR bit can be forced clear by clearing the SPEN bit of the RCSTAx register which resets the EUSART. Clearing the CREN bit of the RCSTAx register does not affect the FERR bit. A framing error by itself does not generate an interrupt.

Che significa la frase(*)? “Pertanto, il bit FERR deve essere letto prima di leggere il RCREGx.”
Devo correggere la Funzione di ricezione? Come? Ma in ogni caso perderò quel Byte ?

unsigned char getch() {
while(!RCIF)
continue;
return RCREG;
}

Scusa la mia “pedanteria” ma anche con la MIA modifica alla funzione putch(), che tu “mi hai gentilmente cassato”, pur funzionando, mantiene ancora un residuo problema di ricezione:
Se resetto con MCLRE (al contrario rispetto al Power ON) ottengo quasi sempre, ma non sempre, un errore di ricezione del primo carattere come se ci fosse qualcosa che é rimasto sospeso?.

Credo di averti tediato anche troppo. Ti ringrazio in ogni caso.

Ciao Giovanni,

la spiegazione che ti avevo dato faceva riferimento a singoli byte, ed in particolare era valida facendo riferimento all'immagine del file pdf che hai inviato.
In riferimento alla seconda immagine del datasheet, il ragionamento che ho fatto non e' piu' valido, per cui la soluzione che hai proposto e' valida ed e' un alternativa al delay. Il secondo controllo introduce un'attesa , fino a quando non si ricade nella situazione della prima immagine.
Ti consiglio di controllare come vengono implementate le funzioni in C18 per avere magari altri riscontri.

Per il secondo punto l Frame Error e' un errore che ti permette di capire se il byte ricevuto e' valido o e' ha generato un errore, per cui potenzialmente errato. Per tale ragione viene detto di controllare il Frame Error bit prima di usare il byte ricevuto.

Saluti,

Mauro