UART-IL MISTERO

[93enricobb]

Salve a tutti,
Volevo trasmettere da un PIC18f452 dei dati al computer tramite la porta seriale ma ho riscontrato problemi che trovo davvero misteriosi. Uso il PIC a una velocità di 40 MHz, per la comunicazione seriale dato che devo alimentare il PIC a 3V ho collegato TX ad un comparatore che porta il segnale a 5 volt e poi viene collegato ad un MAX232, la velocità che ho impostato per l'UART è di 19200 baud rate, one stop bit e nessuna parità. Con l'oscilloscopio ho verificato che i livelli all'uscita del MAX fossero giusti e lo sono, variano da -9 a +9, ho anche verificato la durata di tutta la trasmissione (in uscita il segnale dal bit di star all'ultimo bit dura 0.5ms). Come prima programma ho fatto inviare al PIC il numero 50 (00110010), usando hyperterminal funzionava bene riceveva giusto, 5 minuti dopo ho riprovato e riceveva 114 (01110010).
Il programma era esattamente lo stesso e le impostazioni di hyperterminal pure! ! Il programma l'ho fatto settando manualmente i registri e successivamente anche usando la libreria di Mikropascal...il risultato è lo stesso...ho poi inviato al posto di 50 114 (01110010) e riceveva 242 (11110010)!! è da notare che duplica sempre l'ultimo bit a 1 che riceve..però all'oscilloscopio ho visto il bit lo invia giusto! ! poi perché ogni tanto va e ogni tanto no? AIUTATEMIIII VI PREGOOOO
P.S. ho anche provato a settare il baud rate a 9600...tutto inutile
P.P.S ho anche provato a cambiare computer...inutile pure questo

[TardoFreak]

L' idea di usare un comparatore è alquanto bislacca. Il segnale di uscita da un micro alimentato a 3,3V rientra ampiamente nei limiti TTL quindi puoi benissimo collegare l' uscita dati (TX) dal micro al MAX232.
Per quanto riguarda l' ingresso dei dati (RX), se il micro ha gli input "+5V tolerant" non hai problemi, manda pure il segnale di uscita del MAX232 al micro. Se l' ingresso non accetta un livello a 5V puoi semplicemente metterci uno zener con una resistenza e tutto funzionerà a perfezione.

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

Ammesso che il problema sia un problema circuitale.

[Candy]

Anni fa mi ero interessato molto alla cosa. Il prodotto finale che ne era venuto fuori mi era anche servito per il miocontalitri e poi per il mio bus multimaster che avevo sviluppato.
Ti posso di dire che il fenomeno lo avevo notato anche io.
Ora, in primo luogo toglierei tutto quanto non è indispensabile tra il PIC ed il PC, lasciando unicamente il PIC, il convertitore 232 e la porta seriale, questo perché, è inevitabile, ogni componente che aggiungi, per quanto bassi, introduce dei ritardi...
Ed inoltre ti riassumo quelle che erano state le mie considerazioni.
Il problema mi si era presentato ecco, ad ogni treno di otto bit, il PC riceveva l'ottavo prendendo ancora parte del settimo e senza segnalare errori di ricezione. Ai tempi, (sto cercando di ricordare intanto che scrivo), avevo quindi realizzato una comunicazione tra due PIC, dove uno dei due, con un display, visualizzava pari pari quanto riceveva: con PIC uguali, quarzi uguali, stesse impostazioni, era tutto perfetto, anche ad altissimi baud-rate: 250000. Mentre l'interfaccia PIC/PC andava a rotoli. Fintanto che usavo PC con WIN95 la gestione della porta seriale, mi pare di avere capito, era diversa. da Win98 in avanti i problemi che ho riscontrato aumentavano.
L'unica soluzione che ho trovato è stata quella di: adottare un baud rate lato PIC con un errore percentuale bassissimo, possibilmente nullo, mentre lato PC prima di accettare il byte, controllare gli errori, (usando quindi le API di windows). Non so come si comporti Hyperterminal, ma ti sconsiglio vivamente di usare quello. Piuttosto usa uno dei tantissimi tool gratuiti che ci sono in rete per il test delle porte seriali.
Inoltre, sempre cercando di ricordare, avevo concluso che è meglio evitare di trasmettere lunghi pacchetti dati senza pause di trasmissione. Ho interpretato questo, (senza documentarmi per il vero), pensando che lato PC il driver della porta usi solo il primo bit di start trasmissione per sincronizzarsi, senza poi risincronizzare i byte successivi, e, quindi, un lungo treno di byte andrebbe inevitabilmente a sfasarsi.

La trasmissione 232 è di fatto asincrona: i due partner devono avere un clock uguale identico per non cadere in errori di sincronizzazione e, questo, è praticamente impossibile. Inutile, spero, dare tutti i restanti suggerimenti: il segnale deve arrivare al PC con forma rettangolare quasi perfetta, ecc, ecc.

Non ti arrendere, se vuoi raggiungere un risultato. Non provare unicamente col PC, ma tenta diverse combinazioni, anche con dispositivi diversi, se puoi.

[TardoFreak]

Io la seriale la uso parecchio e, se devo dire il vero, hyperterminal trovo che sia un ottimo emulatore di terminale.
Migliore ancora è RealTerm, molto più veloce.
In questi giorni lo sto usando collegato ad un adattatore USB-Seriale che ho realizzato io con un PIC18F14K50, a 300kBaud che comunica con un Cortex-M3. Scarica dentro il Cortex una valanga di dati in formato s, con protocollo Xon/Xoff e non a mai perso un byte.
Anche con l' adattatore USB-RS232 seriale commerciale ed un ST202 dal lato Cortex tutto funziona in maniera eccellente fino alla massima velocità (115200 Baud).

Mah!

[Robert8]

Ho riscontrato anch'io lo stesso problema ed avevo notato che gli errori si presentavano solo con valori non ASCII e quindi avevo risolto inviando solo valori ASCII coi quali funziona perfettamente. Mi sa che il problema risieda nel lato PC con HiperTerminal ma non ero riuscito a configurarlo per ricevere non ASCII.

[Robert8]

OOPSS: pardon, ho letto meglio:

..però all'oscilloscopio ho visto il bit lo invia giusto!

Come non detto

[93enricobb]

Ho disattivato il PLL e funziona...con il PIC che lavora a 10 MHz va! ! però cavolo a me serve a 40 MHz... cercherò una soluzione :/