Newsgroup: it.hobby.elettronica.digitale
Titolo: Convertire RS232 su IP

In passato ho visto diverse soluzioni per convertire una connessione 
RS232 (ma anche RS422/RS485) su IP: qualcuna utilizzava il protocollo 
UDP, qualcuna il TCP.
Spesso ho dovuto lavorare con porte seriali virtuali per poter 
utilizzare software proprietari che "parlavano" solo RS232.
 
Quello che non ho mai capito è se esiste uno standard Internet su come 
veicolare il traffico asincrono RS232 su reti IP, in pratica come 
incapsulare i byte su RS232 in pacchetti IP.
 
Avete info in merito?


esiste una apposita estensione RFC (non ricordo il numero sorry) che
implementa i controllo seriali sopra il protocollo telnet.
 
molti serial server professionali che uso, Moxa, tra gli altri, lo
utilizzano.
 
non conosco pero' dei software client che sfruttino questo protocollo
(oltre, naturalmente, quelli associati ai serial server e commerciali)
 
essento tutto standard e aperto, nulla ti vieta di programmarne uno.
 
 
-- 
Ciao,
 Andrea
 <a [a] a> z80 <punto appunto> it

 incapsulare i byte su RS232 in pacchetti IP.
 
 
http://stor.altervista.org/python3/sserver/sserver.html
 
 


Aggiungo: mentre in una lan interna non dovrebbero esserci problemi (con 
beneficio di inventario), una connessione sicura in internet si ottiene 
solo con TCP, perche' con UDP i pacchetti potrebbero arrivare 
frammentati, fuori sequenza, o essere proprio persi.
 

Il 03/03/2013 09:49, Claudio_F ha scritto:

Qui si parla solamente della tecnica di tunnelling (non so se si chiama 
esattamente così): prendo i byte da seriale e li metto in un pacchetto 
(TCP o UDP), prendo i byte da socket e li trasmetto su seriale.
 
Mi chiedevo se esistessero altri metodi più o meno standard.
 
Per esempio, ho visto ultimamente una connessione chiamata DTU 
(soprattutto in router asiatici che hanno una seriale per applicazioni 
M2M) che non so quanto c'entri con la terminologia della RS232 (DTU/DCU).
 

 Mi chiedevo se esistessero altri metodi più o meno standard.
 
Non ho capito la domanda. Qualsiasi servizio o comunicazione tramite IP 
si appoggia (piu' o meno visibilmente) al trasporto TCP o UDP, che 
rappresenta il livello piu' basso della rete a disposizione delle 
applicazioni.
 


Infatti non parlavo del livello di trasporto (UDP o TCP, la differenza è 
chiara).  Intendevo se ci fossero standard diversi a livello applicativo 
per trasportare i "dati grezzi" della RS232 tramite pacchetti TCP/UDP.
 
La tecnica descritta nella pagina che hai linkato è quella che verrebbe 
in mente a chiunque: prendo i byte grezzi e li incapsulo nei pacchetti, 
senza conversione, header o altri dati.
 
Usano tutti questa tecnica?  Sicuramente no.  Per esempio, Andrea 
suggeriva l'RFC2217 che è abbastanza complicato rispetto all'idea 
originale di incapsulare semplicemente i dati grezzi, senza porsi il 
problema della configurazione della porta seriale remota.
 

 problema della configurazione della porta seriale remota.
 
infatti. il protocollo telnet, nasce come una estensione della semplice
connessione TCP per veicolare alcune caratteristiche in ambito di gestione
dei terminali ed in effetti molti serial server usano il telnet per
realizzare la connessione via IP con il sistema host, perche'
l'implementazione puo' essere molto semplice, sino ad arrivare alla sola
trasmissione dei dati sul socket nudo e crudo.
 
Il telnet aggiunge la negoziazione delle opzioni, un meccanismo di gestione
delle informazioni fuori banda dati (come trasmettere il segnale di break,
il cts, l'rts, ecc.) e l'estensione 2217 descrive proprio come implementare
le specificita' della porta seriale.
 
in tutti i casi, pero', la latenza e la necessita' di incapsulare dati in un
pacchetto piu' strutturato e trasmesso con un altro sistema non seriale, ti
fa perdere la isocronicita' del dato (non puoi assumere che il dato
ricevuto sia stato effettivamente ricevuto entro tot microsecondi dal
momento che il tuo applicativo lo rileva. Motivo per cui, per esempio, per
collegare orologi GPS al sistema Network Time Protocol si deve
obbligatoriamente usare una seriale nativa (UART) collegata alla cpu, per
dare regolarita' e predicibilita' al jitter e avere una speranza di rendere
affidabile il segnale a 1Hz (PPS) che il ricevitore ti da' e che di solito
e' attaccato al DSR della porta seriale.
 
Se non hai problemi di questo genere, e se le caratteristiche della porta
seriale sono fisse (per es. ho un modem GSM collegato a 96008N via serial
server) aprire un socket e dialogarci in maniera grezza e' gia' funzionale.
 
Se hai bisogno di cose aggiuntive, come il settare le caratteristiche della
porta seriale devi andare di 2217 e poi usare o un emulatore di porta
seriale virtuale oppure, meglio, inserire il supporto a quell'RFC nel tuo
applicativo (lato host, certo, dove sicuramente troverai librerie e altri
oggetti che ti renderanno il lavoro piu' semplice se non gia' del tutto
fatto)
 
attenzione ai protocolli UDP, perche' ti possono portare i dati fuori
sequenza e comunque non gestiscono affidabilita' nella rete IP (mancano
ritrasmissioni, segnalazioni di mancata connessione, ecc.)



Sulla differenza nell'uso emulazione seriale ti segnalo questo thread,
interessante per la differenza tra UDP e TCP e il pro e contro di ogni soluzione
 
http://goo.gl/VOVCN
 
 
--
ciao
  Stefano