Sto cercando un tester portatile per rs232 che mi mostri i dati in rx e tx, autobaud e parametri Quelli belli costicchiano diverse centinaia di euri Quelli economici non mi piacciono Ho deciso di provare a costruirmelo sia per avere il pieno controllo sul funzionameno sia perche' e' un sistema che non ho mai realizzato e quindi stimolante dal punto di vista 'famo roba nuova' In pratica due connettori per il passaggio del cavo, un maschio ed una femmina Un display lcd per la visualizzazione dei dati e parametri trasmissione Quattro tasti per dare qualche comando al trabiccolo, la batteria completerebbe il sistema Pensavo di usare un microprocessore tipo i pic/avr per 'sentire' i dati su alcuni pin pin del micro Una delle funzionalita' principale dovrebbe essere l'autorilevamento dei parametri in trasmissione/ricezione, entro certi limiti ad esempio baud compreso tra 50 e 115200, bit dati tra 5 e 9, parita' o niente parita', ecc Non so da dove iniziare per l'autorilevamento parametri, soprattutto perche' non conosco a priori cosa passa sul cavo Come fare per capire a che velocita' sta funzionando la trasmissione? E per la lunghezza del dato? Ciao e grazie RobertoA
Se sei interessato a usare i Pic, guarda sul sito della Microchip e nella serie 18 e superiori, troverai che le EUSART supportano l'autobaud. Se ti leggi il datasheet di un qualsiasi 18F4520/4525, puoi avere risposta ai tuoi dubbi Per il display e la Rs232 ci sono le librerie standard del pic C 18, anche se, personalmente, preferisco usare le mie librerie. ciao Angelo
Grazie per la risposta Purtroppo anche le eusart prevedono di sincronizzarsi con dei caratteri di controllo (il 55H mi pare di vedere) Ed io vorrei 'attaccarmi' ad una linea rs232 gia' esistente, quindi senza modificare quello che passa sulla linea Ad esempio, se un gps e' collegato alla rs232 del pc, vorrei inserire il mio strumentino in mezzo tra pc e gps e vedere quello che il gps spara al pc Non posso quindi presumere che caratteri possa inviare il dispositivo al pc Fin'ora l'unica possibilita' che mi viene in mente e' leggere costantemente la linea di trasmissione e visualizzare sul display tutte le combinazioni quindi i messaggi in transito se la linea fosse a 50 baud, quelli se lal inea fosse a 300, quelli se la linea fosse a 600, e cosi' via lasciando all'operatore il compito di indicare i messaggi 'leggibili' Solo che immagino non sia questo il modo migliore Ciao RobertoA
Il giorno Tue, 1 Feb 2011 13:41:27 +0100, "RobertoA" ha scritto:
La strada migliore sarebbe quella di utilizzare un timer ed identificare i fronti di salita e discesa dello start bit, questo però presuppone che la periferica comunichi un carattere apposito. Un altro approccio è quello di controllare gli errori di trama o 'FRAME ERROR' nella uart.
Se i fronti dopo la discesa dello start non sono validi avrai questo tipo di errore, puoi fare un software che cerca di agganciare la comunicazione fino a che non si riscontrano più errori di trama, naturalmente partendo dal baud rate più veloce sino al più lento, e accettando di perdere qualche dato durante la ricerca della giusta frequenza.
In genere l'autobaud lo fai se hai un carattere di riferimento, meglio se due. Il piu' "famoso" metodo per l'autobaud e' l'uso dei caratteri "A" e "T" per i modem (Hayes standard prima, ITU V25ter poi). Con la A si determina il baud rate, con la T la parita' e numero di bit.
Se non puoi dare dei caratteri di riferimento, meglio un menu' dove imposti manualmente i parametri.
Infatti, presuppone l'utente possa riconoscere una sequenza di caratteri come "corretta", cosa che per tua definizione non e' dato da sapere. Tantovale impostare manualmente un setting e verificare se quello che passa ha senso. Anzi, direi che elimini una variabile (cosa decide di fare l'algoritmo di autobaud).
Piuttosto allora meglio fare un aggeggio che campiona quello che c'e' in linea e salva su qualche memoria e poi ci fai analisi a non finire con calma :)
In genere l'autobaud lo fai se hai un carattere di riferimento, meglio se due. Il piu' "famoso" metodo per l'autobaud e' l'uso dei caratteri "A" e "T" per i modem (Hayes standard prima, ITU V25ter poi). Con la A si determina il baud rate, con la T la parita' e numero di bit.
Se non puoi dare dei caratteri di riferimento, meglio un menu' dove imposti manualmente i parametri.
Infatti, presuppone l'utente possa riconoscere una sequenza di caratteri come "corretta", cosa che per tua definizione non e' dato da sapere. Tantovale impostare manualmente un setting e verificare se quello che passa ha senso. Anzi, direi che elimini una variabile (cosa decide di fare l'algoritmo di autobaud).
Piuttosto allora meglio fare un aggeggio che campiona quello che c'e' in linea e salva su qualche memoria e poi ci fai analisi a non finire con calma :)
Il giorno Tue, 1 Feb 2011 16:07:57 +0100, "RobertoA" ha scritto:
Ci sono, ci sono.
Poi bisogna precisarere cosa vuol dire campionare la linea. Fare una sequenza di lettura per esempio a 1 µS e poi vedere quando i fronti cambiano, poi cercare delle combinazioni valide all'interno. Richiede un approccio qualitativo e un algoritmo non è affatto semplice, imho
La strada del frame error è sicuramente più facile da implementare se la UART del µC la supporta, per esperienza ti dico che con gli AVR questo approccio funziona.
*RS232* defines an asynchronous type of communication. This means, that sending of a data word can start on each moment. If starting at each moment is possible, this can pose some problems for the receiver to know which is the first bit to receive. To overcome this problem, each data word is started with an attention bit. This attention bit, also known as the /start bit/, is always identified by the space line level. Because the line is in mark state when idle, the start bit is easily recognized by the receiver.
Stop bits
Suppose that the receiver has missed the start bit because of noise on the transmission line. It started on the first following data bit with a space value. This causes garbled date to reach the receiver. A mechanism must be present to resynchronize the communication. To do this, framing is introduced. Framing means, that all the data bits and parity bit are contained in a frame of start and /stop bits/. The period of time lying between the start and stop bits is a constant defined by the baud rate and number of data and parity bits. The start bit has always space value, the stop bit always mark value. If the receiver detects a value other than mark when the stop bit should be present on the line, it knows that there is a synchronization failure. This causes a framing error condition in the receiving *UART*. The device then tries to resynchronize on new incomming bits.
For resynchronizing, the receiver scans the incomming data for valid start and stop bit pairs. This works, as long as there is enough variation in the bit patterns of the data words. If data value zero is sent repeatedly, resynchronization is not possible for example.
The stop bit identifying the end of a data frame can have different lengths. Actually, it is not a real bit but a minimum period of time the line must be idle (mark state) at the end of each word. On *PC*'s this period can have three lengths: the time equal to *1*, *1.5* or *2* bits.
*1.5* bits is only used with data words of *5* bits length and *2* only for longer words. A stop bit length of *1* bit is possible for all data word sizes.
Credo che questo possa esserti di aiuto per fare analisi dei dati e della relativa velocita'.
Altrimenti, in un mio recente ricevitore multipurpose per radiocomandi, ho fatto un buffer di circa 200 byte per memorizzare il campionamento a
30 uSec. dei livelli della linea di ricezione. Il timeout della trasmissione fra byte dello stesso frame, nel mio caso
3 mSec., lo memorizzo come un byte 0xff. A buffer pieno ricerco i due byte 0xff, confronto il numero dei byte, i buffer buffer byte a byte e in caso di match, risalgo alle singole velocita' dei bit ricevuti. Da li' in poi, si tratta di normale amministrazione. Penso che potresti fare qualcosa di simile; senza ricorrere nemmeno alla serie 18, ho usato un 16F648A da meno di 50 centesimi!!! ciao Angelo
Dici che campionando la linea prima di abilitare la seriale e cercando il "bit più corto" non ci si riesce?
Prima o poi un singolo bit a uno o zero dovrà ben uscire. A quel punto prendi il reciproco e arrotondi al baud rate più vicino.
O, meglio, ti fai una tabella di coppie durata bit (moltiplicata per 0,5, almeno poi cerchi la minima maggiore del tempo che hai misurato) e baud rate. O, direttamente, valore da impostare sulla seriale.
Il giorno Tue, 1 Feb 2011 16:39:28 +0100, "F. Bertolazzi" ha scritto:
E' vero, mi è sfuggita la frase col GPS, in quel caso è banale. Basta mettere il baud a 38,400 e verificare la trama, poi passare a 4800 se c'è un errore.
Facendo due calcoli, con un timer si può impostare il ritardo per partire col secondo carattere a tempo.
Il giorno Tue, 1 Feb 2011 16:46:15 +0100, "F. Bertolazzi" ha scritto:
Anche questa è una strada, se non altro ti evita il campionamento e il successivi rompicapo. Basta impostare il timer su entrambi i fronti e usare l'interrupt, fare la differenza e tenere in memoria il valore più basso.
Dopo qualche byte hai per forza un valore di baud.
L'esempio del gps e' un "esempio" appunto Non e' detto che ci sia un gps e non e' detto quindi che ci sia un carattere bello noto li a disposizione per farsi acchiappare Potrebbe essere un qualsiasi dispositivo e quindi posso presumere quali caratteri possa inviare il dispositivo al pc Restringendo il discorso ai gps, le velocita' che ho trovato e' frequentemente diversa dai 4800 o 38400 Ricapitolando, caratteri noti a priori non ce ne possono essere , velocita' note neanche Rimane il discorso del valore baud derivato dal valore del bit piu' stretto, almeno si spera di trovarlo entro un numero di byte ragionevole Ciao
Grazie per la risposta Non ho pero' capito bene quale utilita' particolare possa avere il link inviato Conosco bene il funzionamento della rs232 ed il mio problema e' nel trovare un sistema che mi permetta di settare automaticamente i valori di baud rate e parametri comunicazione Ciao
Il giorno Tue, 1 Feb 2011 18:15:56 +0100, "RobertoA" ha scritto:
Se consideri che ogni byte ha nel caso tipico START + 8BIT + STOP hai al massimo
20 fronti per ogni byte, se conti i fronti misurati dopo una 50-60 fronti dovresti avere una probabilità rilevante di un corretto baud rate.
Ma poi per verificare se ci sono errori il controllo del FRAME lo devi fare lo stesso. E tralasciamo il caso in cui ci sono 1,5 o 2 stop bit, nella pratica ho incontrato solo una volta 2 stop bit in una stampantina termica
Il link era solo per darti idea da dove venivano le specifiche riportate. In effetti, volevo sottolineare che il bit di start e di stop "dovrebbero" essere presenti e riconoscibili. Nient'altro che un eventuale punto di partenza per studiare una strategia. ciao Angelo
Se stessero passando degli 0H quello che vedresti sarebbe il fronte di salita dell'inizio bit di start e poi il fronte di discesa della fine bit di stop, in pratica una transizione basso-alto ed un'altra alto-basso Potrebbe essere confuso con il singolo bit di start del carattere 55H C'e' poi il discorso della lunghezza dei dati (5-6-7-8-9 bit), non sapendo quella e' duretta tirare fuori il baud rate corretto
Se per 'frame' intendi l'insieme di bit dall'inizio dello start alla fine dello stop, puoi controllarlo solo rispetto ad un frame di riferimento, devi sapere velocita' e parametri, altrimenti non saprei come fare a controllarlo
No, veramente non vorrei tralasciare i casi particolari e quindi dati a 5 bit, stop a 2 bit, parita' o senza, ecc.. Ciao e grazie
Il giorno Tue, 1 Feb 2011 19:42:15 +0100, "RobertoA" ha scritto:
Certamente, ma almeno saprai se il byte ricevuto è valido.
Mi riferisco ai controlli che fa la UART per verificare che i fronti cambino nel range di timing richiesto.
Qui:
formatting link
dopo "USART Reception" c'è una figura con una frase in rosso che spiega quello che intendo dire.
Inutile impazzire per fare quelle verifiche che la UART fa automaticamente quando imposti i parametri, compresi gli start e stop.
Allora non credo che tu possa fare diversamente. Trovi il baud rate con il timer, poi metti una combinazione di stop bit e di parità e se trovi errori di frame provi a cambiare tutte le combinazioni possibili fino a che non ci sono più errori.
Avrai una perdita di dati all'inizio, ma alla fine funzionerà. Naturalmente sul µC metti un quarzo che ti dia un errore di partenza basso.
Con un mC qualsiasi pui usare almeno due approcci:
Usa la UART e imposta le varie condizioni di baud rate, inizia senza parita': controlla gli errori (Framing error etc.) - se hai N caratteri ricevuti senza errori, baud ok, altrimenti seleziona il prossimo
Se hai dei pin di capture, puoi catturare il timing delle transizioni. Dopo N catture, il bit time sara' quello piu' piccolo che trovi, da qui ricavi il bit rate ... questo sistema permette di rilevare anche bit rate non standard.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.