Newsgroup: it.comp.lang.c
Titolo: Seriale Trasparente





Sto' implementanto un loopthrough di una 
seriale: mi spiego, supponiamo di avere un dispositivo di segnalazione allarmi 
che ha come output una seriale, ed una centrale di gestione allarmi che riceve 
in ingresso una seriale:


 


ALLARMI -> 
RS232->CENTRALE


 


la seriale trasparente non fa altro che 
collegare gli ALLARMI ad un client, che fa via rete la spedizione di ciò che 
riceve in ingresso da ALLARMI verso un'altro client (sara' il server 
in questo caso), il server non fa altro che il writeout di cio' che riveve via 
rete verso una sua seriale, alla quale sara' attaccata la CENTRALE:


 


ALLARMI->RS232->CLIENT->TCPIP~~~~~~~~~~~TCPIP->SERVER->RS232->CENTRALE


 


inoltre il server ciò che riceve dalla 
propria seriale lo spedisce al client (in realtà tutti i client) a cui è 
connesso, quindi lo schema completo sarebbe:


 


ALLARMI<->RS232<->CLIENT<->TCPIP~~~~~~~~~~~TCPIP<->SERVER<->RS232<->CENTRALE


Ora: se il protocollo di ALLARMI e CENTRALE 
non ha parità, il tutto funziona correttamente, questo è stato provato in campo, 
e anche da test, collegando al posto di ALLARMI e CENTRALE due PC su 
cui gira un'hiperterminal, questi riescono correttamente a colloquiare ed a 
spedirsi file con protocolli diversi come zmodem, zmodem con ripristino ecc. 
quindi senza parità tutto OK.


Se ALLARMI e CENTRALE specificano la parità 
invece riscontro alcuni problemi: supponiamo che ALLARMI e CENTRALE aprano 
entrambi la seriale con parità pari e CLIENT e SERVER la aprano anche loro 
con parità pari: in questo caso la comunicazione ASCII ed invio di file di 
testo avviene correttamente, mentre l'utilizzo di un protocollo come lo zmodem 
non avviene, anche gestendo glie eventi di EV_ERR per la parità: il tutto 
avviene così supponendo l'invio di 1 byte:


 


ALLARMI->RS232 1 byte = 2byte (c'è la 
parità)->CLIENT (riceve 1 BYTE + msg EV_ERR ecc. in quento la conversione 
viene fatta direttamente dalla seriale che è stata aperta come parità 
PARI->TCPIP~~~~~~~~~~~~~~TCPIP->SERVER (riceve 1 byte)->RS232 (spedisce 
2 byte in quanto la serial è aperta come parità PARI e la conversione avviene 
dalla seriale)->SERVER.


 


Ho pensato che la conversione eseguita 
dalla seriale perda alcune informazioni come i vari data-set-ready (DSR), RTS 
ecc e gli eventi come EV_BREAK, EV_Err sono fatti in modo diverso tra 
server e client e non so come replicarli. 


Però ho pensato a quanto segue: mantenendo 
il fatto che ALLARMI e CENTRALE aprono la seriale con parità pari, se a CLIENT e 
SERVER faccio aprire la seriale senza parità, non avviene nessuna conversione, 
quindi i 2bytes in uscita da ALLARMI rimangono 2bytes per client che li invia 
verso server che li scrive sulla seriale, e quindi CENRALE dovrebbe poter 
ricevere esattamente il pacchetto in ricezione: ed infatti la cosa funziona: 
l'invio di file binari con protocollo zmodem ed altri funziona, non avviene però 
correttamente l'invio di testo ASCII: cioè da una parte invio un carattere a 
dall'altra non sempre viene visualizzato come se venisse ricevuto un byte mentre 
a causa della parità ne venissero attesi 2.


 


Credo che stia perdendo qualcosa: qualcuno 
sa darmi dei consigli sulle seriali o cualcosa che devo tener bene presente 
sull'uso delle seriali? Grazie


 


Posto questo messaggio qui in quanto sul newsgroup 
c++ sono inconcludenti, guardano più all'estetica del codice che al fatto se il 
codice funziona, mi piacerebbe sapere se ogni tanto scrivono qualcosa lungo più 
di 2righe non oso pensare se ogni tanto poi lo 
compilano...



 wrote in message
9aEw6.108676$lj4.3...@news6.giganews.com...
Sto implementanto un loopthrough di una seriale: mi spiego, supponiamo
di avere un dispositivo di segnalazione allarmi che ha come output una
seriale, ed una centrale di gestione allarmi che riceve in ingresso una
seriale:
ALLARMI -> RS232->CENTRALE
la seriale trasparente non fa altro che collegare gli ALLARMI ad un
client, che fa via rete la spedizione di ciò che riceve in ingresso da
ALLARMI verso un'altro client (sara' il server in questo caso), il
server non fa altro che il writeout di cio' che riveve via rete verso
una sua seriale, alla quale sara' attaccata la CENTRALE:
ALLARMI->RS232->CLIENT->TCPIP~~~~~~~~TCPIP->SERVER->RS232->CENTRALE
inoltre il server ciò che riceve dalla propria seriale lo spedisce al
client (in realtà tutti i client) a cui è connesso, quindi lo schema
completo sarebbe:
ALLARMI<->RS232<->CLIENT<->TCPIP~~~~~~~TCPIP<->SERVER<->RS232<->CENTRALE
Ora: se il protocollo di ALLARMI e CENTRALE non ha parità, il tutto
funziona correttamente, questo è stato provato in campo, e anche da
test, collegando al posto di ALLARMI e CENTRALE due PC su cui gira
un'hiperterminal, questi riescono correttamente a colloquiare ed a
spedirsi file con protocolli diversi come zmodem, zmodem con ripristino
ecc. quindi senza parità tutto OK.
Se ALLARMI e CENTRALE specificano la parità invece riscontro alcuni
problemi: supponiamo che ALLARMI e CENTRALE aprano entrambi la seriale
con parità pari e CLIENT e SERVER la aprano anche loro con parità pari:
in questo caso la comunicazione ASCII ed invio di file di testo avviene
correttamente, mentre l'utilizzo di un protocollo come lo zmodem non
avviene, anche gestendo glie eventi di EV_ERR per la parità: il tutto
avviene così supponendo l'invio di 1 byte:
ALLARMI->RS232 1 byte = 2byte (c'è la parità)->CLIENT (riceve 1 BYTE +
msg EV_ERR ecc. in quento la conversione viene fatta direttamente dalla
seriale che è stata aperta come parità PARI->TCPIP~~~~~~~~~TCPIP->SERVER
(riceve 1 byte)->RS232 (spedisce 2 byte in quanto la serial è aperta
come parità PARI e la conversione avviene dalla seriale)->SERVER.
Ho pensato che la conversione eseguita dalla seriale perda alcune
informazioni come i vari data-set-ready (DSR), RTS ecc e gli eventi come
EV_BREAK, EV_Err sono fatti in modo diverso tra server e client e non so
come replicarli.
Però ho pensato a quanto segue: mantenendo il fatto che ALLARMI e
CENTRALE aprono la seriale con parità pari, se a CLIENT e SERVER faccio
aprire la seriale senza parità, non avviene nessuna conversione, quindi
i 2bytes in uscita da ALLARMI rimangono 2bytes per client che li invia
verso server che li scrive sulla seriale, e quindi CENRALE dovrebbe
poter ricevere esattamente il pacchetto in ricezione: ed infatti la cosa
funziona: l'invio di file binari con protocollo zmodem ed altri
funziona, non avviene però correttamente l'invio di testo ASCII: cioè da
una parte invio un carattere a dall'altra non sempre viene visualizzato
come se venisse ricevuto un byte mentre a causa della parità ne
venissero attesi 2.
Credo che stia perdendo qualcosa: qualcuno sa darmi dei consigli sulle
seriali o qualcosa che devo tener bene presente sull'uso delle seriali?
--------------
La tua applicazione e la corrispondente struttura funzionale mi sembrano
abbastanza ragionevoli. Il tutto dovrebbe funzionare se le modalita' di
gestione della seriale adottate da CLIENT e da SERVER sono tali da
permettere di ricevere esattamente i dati (grezzi, senza nessuna
interpretazione) da ALLARMI e da CENTRALE, e da trasmetterli e riceverli
altrettanto esattamente tramite il protocollo TCPIP. Quello che non
quadra e' il concetto che hai del controllo di parita' applicato ad una
sequenza di dati (byte) serializzati (e forse, implicitamente, la
concezione delle modalita' di rice-trasmissione seriale). Ogni byte di
dati da inviare su di una linea seriale viene spedito bit per bit (ogni
bit corrisponde ad una durata fissa di segnale elettrico alto (1) o
basso (0), in logica positiva), premettendo al primo bit di dati un bit
di start fisso, e posponendo all'ultimo bit di dati uno o due bit di
stop. Inoltre, se si desidera un controllo di parita', all'ultimo bit di
dati viene fatto seguire un bit aggiuntivo di parita', che rende pari o
dispari (a seconda che si scelga una parita' pari o una parita' dispari)
il numero di bit 1 presenti nel singolo byte di dati. Ancora, per motivi
"storici", il byte di dati puo' essere scelto di 7 bit o di 8 bit (oggi
si usa quasi esclusivamente la codifica ad 8 bit, ma la codifica ASCII
base e' a 7 bit, e descrive solo i 128 caratteri di uso
internazionalmente piu' frequente, per cui anche con solo 7 bit di dati
e' possibile trasferire il set di caratteri ASCII base).  Quando, in
fase di open del canale seriale, si inizializza la rice-trasmissione, e'
necessario stabilire quale particolare configurazione di tutti questi
parametri (dati a 7 o 8 bit, no parity o parity even o parity odd, 1 o 2
stop bit), oltre al baud-rate ossia la durata del singolo bit, si
desidera fisicamente utilizzare. Cio' che e' essenziale, affinche' la
rice-trasmissione dei dati (che poi e' quella che interessa) abbia luogo
correttamente, e' che la definizione dei parametri anzidetti sia la
stessa nei due apparati connessi dalla seriale. Nel tuo caso,  SERVER e
CENTRALE dovranno avere le stesse modalita' di apertura fisica del
canale seriale, e cio' dovra' pure essere vero per la coppia ALLARMI e
CLIENT. Il protocollo TCP/IP (con tutte le proprie modalita', assai piu'
complesse, che tuttavia sono del tutto trasparenti e ignorabili per
l'utente) provvedera' alla rice-trasmissione dei soli dati
significativi, senza nessuna interferenza con le modalita' e
particolarita' aggiuntive elencate, relative e caratteristiche del solo
collegamento seriale.
Spero che questa nota, piuttosto riassuntiva, possa essere utile e
sufficiente. Se hai difficolta', fai tranquillamente un fischio. D'altro
canto, mi piacerebbe avere un'idea pratica di quanto e' complesso il
codice che permette la rice-trasmissione di messaggi fra CLIENT e SERVER
tramite TCP/IP. Se hai qualche notizia o esempio significativo, ti
ringrazierei se tu potessi darmene una qualche illustrazione. Ciao.
Andrea.

 ha scritto nel messaggio
news:9a1ggb$35s6b$1...@ID-38103.news.dfncis.de...


 start bit / stop bits e parity bits.
Scusate, ma siete off-topic.
EMG

 Perň non ho ancora chiare alcune cose:
Effettivamente, come qualcuno ha notato, siamo decisamente fuori tema
relativamente all'oggetto del news-group. E del resto, credo di avere
provato piu' di una volta, gia' da subito, a rispondere direttamente, ma
ogni volta sono stato avvertito che il messaggio, indirizzato a
gre...@cieffe.com
, non poteva essere recapitato. Ora forse porei
aggiungere qualche ulteriore informazione sull'argomento in esame, ma
dovresti pero' scrivermi direttamente, specificando un indirizzo al
quale possa poi contattarti. Saluti. Andrea.

Mi scusassero...
Enrico Maria Giordano ha scritto:
