Realizzazione di un semplice serial server

[Maurizio Conti]

Mi trovo nella necessità di implementare un semplice serial server sullo SlimLine. Analizzando gli esempi sul forum ho messo in piedi un programma ST che funziona abbastanza bene per bassi baud rate della seriale ma che ha seri problemi per velocità attorno a 115200. In particolare inviando un file ASCII sulla seriale mi trovo in uscita dal socket uno stream pieno di ‘buchi’ (si perdono molti caratteri).

Dopo vari tentativi per risolvere il problema mi sono reso conto che servirebbe un buffer sulla seriale più ampio degli attuali 256 bytes oppure occorrerebbe consumare più velocemente i caratteri in arrivo (ora è un programma nella task BACK) impiegando un programma nella task SLOW. In questo caso però la funzione SysGetOSpace sembra non funzionare così come la funzione del sistema operativo che esegue il flush del buffer del socket. Ha qualche consiglio ?

[Sergio Bertana]

In effetti lo SlimLine ha un buffer seriale di 256 caratteri in ricezione ed uno da 256 caratteri in terasmissione, i due buffers sono gestiti in interrupt, quindi nessun carattere viene perso. Tu mi parli di un baud rate di 115200 baud, che corrisponde a circa 11000 caratteri al secondo (1 carattere ogni 0.1 mS). Ipotizzando che la task di back (Unica task in cui puoi gestire le comunicazioni) venga eseguita ogni 10 mS (E’ un tempo cautelativo, sicuramente viene eseguita mediamente in molto meno) devi gestire al massimo 100 caratteri, qunindi ampiamente entro la dimensione del buffer seriale.

Naturalmente devi provvedere togliere i caratteri dal buffer seriale e a memorizzarli in un tuo buffer molto più grande per attendere i tempi di gestione lato TCP/IP che saranno molto maggiori (Vedi post).

[Maurizio Conti]

Grazie per la risposta. Nel frattempo ho approndito ulteriormente l’argomento e le cose stanno esattamente come da lei indicato. Chiedo però lumi sulla frase “i tempi di gestione lato TCP/IP che saranno molto maggiori“. Di che tempistiche si parla ?

Sul manuale ho trovato solo il parametro FlushTm che non riesco ad impiegare coerentemente col codice.  Non basta il buffer del socket TCP dimensionato al massimo ? Che buffer devo prevedere ?

Inoltre, può essere impiegato il comando SysFOBfFlush(FpSKT) in modo sincrono con l’immissione del pacchetto di caratteri nel buffer di tx del socket per forzarne immediatamente l’invio ?

[Sergio Bertana]

Quando cito i tempi del TCP/IP indico il fatto che quando SlimLine invia il pacchetto TCP verso il Client deve attendere il pacchetto di ACK di risposta dal client, i tempi dipendono dal traffico di rete e dalla velocità con la quale il client risponde con l’ACK. Su reti cablate ethernet i tempo possono andare da decine di mS anche a centinaia di mS, se poi si utilizzano reti WiFi i tempi possono dilatarsi anche di un fattore 10. Ma avendo la possibilità di inviare pacchetti dati abbastanza grandi (Massimo 512 bytes) in un unica trasmissione dovremmo riuscire a gestire comodamente il flusso dati.

Per quanto riguarda il parametro FlushTm, esso indica il tempo in mS dopo il quale i dati caricati nel socket vengono inviati. Cosa si intende, dopo avere aperto il socket con la Sysfopen i caratteri vengono trasferiti nel socket o singolarmente con una Sysfputc oppure a blocchi con una Sysfwrite, terminato il trasferimento di dati viene atteso il tempo definito in FlushTm prima di inviarli al Client. Questo permette di effettuare più volte la funzione di trasferimento per creare un pacchetto unico che sarà inviato dopo il tempo.

Quindi se FlushTm è 10 mS vuol dire che dopo avere caricato i dati nel socket, dopo 10 mS questi saranno inviati al Client. La funzione SysFOBfFlush permette invece l’invio immediato dei dati.

[Sergio Bertana]

Per  fare un server seriale però occorre tenere presente alcune indicazioni su come gestire il flusso dati dai due file stream attivi (Porta seriale e socket TCP/IP). Dalla seriale i caratteri arrivano uno alla volta, mentre sul socket TCP/IP sono trasmessi a pacchetti, per questo non bisogna che ogni dato ricevuto dalla seriale venga inviato immediatamente al socket, ma conviene attendere che dalla seriale non arrivino più caratteri per un tempo e poi si inviano quelli ricevuti sul socket.

Naturalmente se dalla seriale si continuano a ricevere caratteri ad una certa soglia di riempimento del buffer (70 %) i dati fino a li ricevuti devono essere inviati al client per svuotare il buffer di ricezione da seriale (Attento non il buffer interno da 256 bytes ma quello esterno da te gestito di almeno 512 bytes o superiore).

Più semplice invece la ricezione da TCP/IP, il pacchetto ricevuto dovrà essere spostato in un buffer temporaneo (512 bytes o superiore) e da lì inviato verso la seriale. Se dai una occhiata a questo post è indicato come funzionano i server seriali commerciali.

[Sergio Bertana]

Da tutto quanto detto, visto le differenze di risposta tra la comunicazione seriale e quella TCP/IP è evidente che i server seriali funzionano bene solo se vi sono dei tempi morti tra i vari pacchetti dati, o se la comunicazione è di tipo master/slave esempio modbus, dove ad un pacchetto inviato si attende il pacchetto di risposta e non si invia nulla fino a quando non viene ricevuto o dopo un timeout.

Sono proprio i tempi morti a permettere di svuotare i buffers dati verso il relativo file stream compensando le differenze di velocità e permettendo di garantire una comunicazione senza perdita di dati.

[Sergio Bertana]

In questo post si può trovare un programma che realizza un semplice convertitore Ethernet/Seriale.

[Autore]

Post