Newsgroup: it.hobby.elettronica.digitale
Titolo: Problema con l'UART del PIC16F627A


...[cut]
In questi giorni sto adoperando una 16f628, sorellina maggiore della tua, e
anche io ho incontrato un problema simile al tuo.
Il tuo codice a dire la verità non l'ho letto con molta attenzione,
soprattuto perchè per "giudicare" la sua correttezza dovrei conoscere la
sequenza degli eventi che deve gestire la pic.
Cmq venendo al sodo il mio problema l'ho risolto riscrivendo il codice
tenendo bene presente i tempi che avevo a disposizione, ovvero per eseguire
le mie operazioni impiegavo più tempo di quello che intercorreva tra la
ricezione di un byte e l'altro, quindi i risultati non erano mai coerenti
(riconoscere una sequenza di 50 bytes al volo.......). Hai fatto bene i
conti?
E prima di salutarti, se mi permetti di darti un consiglio, prima di ogni
operazione di ricezione con l'usart, ti conviene svuotare il buffer con tre
MOVF RCREG,W consecutivi e ti metti al sicuro.
Sper di esserti stato almeno di spunto.
Ciao ciao
P.S. - Ho usato la pic @ 16MHz con l'usart settata a 38400 e l'MPLab come
ambiente di sviluppo.

 conti?
mi sembra che un pic in 65000uS faccia in tempo a processare una bella mole
di dati, quindi escluderei l'ipotesi che non faccia in tempo a ricevere due
dati consecutivi con le interruzioni, e anche se fosse controllando
l'overrun se ne accorgerebbe.
Nel codice secondo me non devi cancellare l'interrupt flag che viene
cancellato automaticamente quando RCREG č vuoto perchč altrimenti perderesti
un eventuale byte ricevuto durante l'ISR, e non dovresti nemmeno
disabilitare la ricezione per lo stesso motivo, in quato l'altro dispositivo
non si ferma di trasmettere e poi perderesti eventuali informazioni di
overrun e framming error sul byte in questione.
Io non ho mai avuto nessun problema anche senza eseguire le tre letture di
Rcreg per vuotare il buffer e lo trovo inutile, ma forse dipende anche dal
protocollo che si usa. quindi lascio questo punto a vastra discrezione e
abitudine
Ciao
Lucio

[cut]
....a parte il sesso delle pic......effettivamente il 65000uS ne puň
elaborare di roba, ma il suo problema č nel ricevere i bytes, tieni presente
che va a 19.200 Baud, a conti fatti hai pochissimo tempo tra un byte e
l'altro, quindi basta un'operazione in piů per far accumulare un ritardo
tale da far perdere il sincronismo con la sorgente dei dati.
Se non ho capito male lui ogni 65000uS manda un byte, č tra una trasmissione
e l'altra che deve ricevere qualcosa che non riesce a leggere correttamente.
Spero che le nostre osservazioni cmq gli possano servire a capire meglio
dove deve intervenire, altrimenti che ci stiamo a fare?
Ciao ciao

P.S. - Se non ho fatto male i conti tra un bytes ricevuto e l'altro ha circa
50 cicli di clock per fare cio' che gli serve (19.200 ~= 1 byte ogni 52uS,
PIC @ 4MHZ = 1 istruzione ogni uS)
Se tieni presente che dalla notifica della ricezione del byte se ne vanno
già 3 clicli (BTFSS e MOVF RCREG,W), rimane poco tempo per gestire il resto.

 PIC @ 4MHZ = 1 istruzione ogni uS)
Scusa, ma a 19.200 bps io non ho un *BIT* ogni 52us?
Olivier.

--
_________________________________
Penso tutto ciò che dico,
ma non sempre dico tutto ciò che penso !!
"Olivier" <ilgalla@MAPS_ONlibero.it> ha scritto nel messaggio
news:KKKpb.89183$vO5.3...@twister1.libero.it...

dipende, parliamo di baud-rate o di bit-rate?

> dipende, parliamo di baud-rate o di bit-rate?
Un BIT e un BAUD non sono la stessa cosa nella comunicazione seriale?
Olivier.


a questo punto mi fai venire dei dubbi...devo controllare meglio ma in tutti
i calcoli ho sempre differenziato le cose e mi sono sempre trovato bene.
Che io ricordi non sono la stessa cosa,cmq mi metto alla ricerca di
conferme.


ho trovato questo:
http://www.cnet.com/Resources/Info/Glossary/Terms/baud.html

Scusami...anche questo:
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci211643,00.html
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?baud
credo sia sufficiente

 PIC @ 4MHZ = 1 istruzione ogni uS)
Guarda che l'interruzione ce l'hai soltanto alla fine del byte, quindi se
viene rtrasmesso ogni 65000uS, tra un byte e l'altro hai 65000uS di tempo.
Della ricezione del byte se ne occupa l'uart e tu nel frattempo fai tutto
quello che vuoi.
Ciao
Lucio


 ha scritto nel messaggio
news:e6wpb.88994$e6.32...@twister2.libero.it...


 conferme.
Il termine BAUD in pratica indica il numero di modulazioni che applico al
mezzo di trasmissione per trasmettere informazioni. Sulla linea telefonica
ho *contemporaneamente* vari tipi di modulazioni, in ampiezza, in frequenza
ecc., quindi il BAUDps non corrispondono ai Bps. Nella trasmissione seriale
invece ho una sola "modulazione" per volta, porto lo stato o alto o basso,
quindi (se ha senso parlare di baud) i baud per secondo corrispondono ai
BPS.
Correggetemi se sbaglio, non sono tanto ferrato in materia!
Olivier.

> Magari le pic femmine sono più lente dei pic maschi :-P
ROTFL!  =)

Se non ho letto male si precisa anche l'assenza di bit di stop e di start,
solo allora è vero quello che dici tu, ovvero che baud-rate e bit-rate
coincidono.
Ci tengo a precisare che ciò che affermo sia la sacrosanta verità, ma visto
il dubbio è meglio confrontarsi per cercare di capire come stanno le cose.
Ciao ciao

Lui ne spedisce uno ogni 65000uS, tra una trasmissione e l'altra aspetta
dati dall'RX dell'usart.
Se dovesse ricevere una sequenza di byte, secondo te gliene arriva uno ogni
morto di papa?
Hai mai pensato che potrebbe arrivargli una sequenza di bytes a cavallo
dell'interrupt?
A questo punto sono io che chiedo a te che cosa ci fai con le pic (maschi o
femmine, fai te!!)

 ha scritto nel messaggio
news:MX6qb.94572$e6.34...@twister2.libero.it...


[cut]
...effettivamente rileggendo meglio.....
Inizialmente avevo inteso che lui spediva un byte ogni  tot, e nel frattempo
doveva ricevere altro.
L'importante è che tutta questa discussione sia tornata almeno unpo' utile a
Rocco.
Al prossimo dibattito,.
Ciao ciao