linux user group brescia

Enrico Colombini said:
> On Saturday 09 August 2003 13:37, Francesco Tonolli wrote:
>> Ho letto di minicom ma nella pagina di man si parla di un modem, cosa
>> che io non ho.
> Minicom e' un clone di Telix, funziona anche senza modem.
>> Ma in questo caso come faccio a stabilire la velocità ,
>> bit di parità ecc, ecc?
> stty (credo).

 In effetti, Francesco, con stty puoi settare (e leggere) praticamente
qualunque parametro di una seriale (es. /dev/cua0)... poi dipende COSA ci
devi fare con la seriale: ad es. io, quando ci attacco un modem, con echo
ATZ > /dev/cua0 gli mando un "reset" (ATZ classico).
 Ovviamente "dall'altra parte" può esserci qualunque cosa (quindi anche
non un modem) capace di parlare RS-232.

 Per quanto riguarda il lato trasmissioni/cavo di connessione devi vedere
se il tuo apparato (macchina utensile) si comporta da DCE (modem-like) o
DTE (terminal like): nel secondo caso devi usare un cavo "crossato" per
la comunicazione col PC (incrociando TX, RX e "sistemando" qualche altro
criterio) mentre nel primo (DCE) un normalissimo cavo "dritto" seriale va
bene (max lunghezza: 12m, da standard, anche se ho visto funzionare, in
ambienti non disturbati, cavi lunghi anche 40m).

> Trovi in giro ampia documentazione sulle seriali, se non sbaglio a
> partire da  un Serial HOWTO.

 Probabilmente IMHO, proprio a causa dei "trascorsi storici" di Linux (e
Unix) le seriali devono essere uno degli argomenti meglio trattati,
assieme alle LAN/ethernet.

> Non dimenticare che il tuo utente deve poter accedere a  ttySx.
> In effetti le seriali sotto Linux sono una discreta rogna per chi viene
> da  Windows: sono completamente diverse;

 Sei sicuro che non sia invece (quasi) il contrario?.. non ci ho mai messo
le mani direttamente (uso prevalentemente la LAN) ma ho come
l'impressione che lavorare con la seriale sia ancora più semplice che
lavorare con la parallela: in pratica, grazie anche alla bassa velocità
del canale, una volta aperto un dialogo con la seriale (che, in standard
Linux, vedi sempre come un file), dovrebbe essere più o meno lo stesso
che trovarsi con una sessione DOS in comunicazione con un terminale (o un
modem).
 E' probabile che ci fossero con ${noto_OS_preemptive} i problemi, dato il
pesante context switching ed il fatto che, comunque, comandavano i suoi
layer di "astrazione"... a meno, ovviamente, di non usare tutto in
finestra DOS. ;)

> anch'io dovrei studiarmele e,
> alla fine,  scrivermi un driver decente (per usi simili ai tuoi), ma
> continuo a rimandare  :-)

 Domanda: perchè un serial-driver "custom"?... o forse volevi dire un
programma di comando (user) della seriale? (quindi, praticamente,
riscrivere Minicom).

 Ho l'impressione che a Francesco serva unicamente un programma
applicativo per (A) aprire la seriale necessaria, (B) inviare (o
ricevere) dati sulla stessa, (C) fare in modo che alcuni processi
automatici tengano sotto controllo il macchinario connesso.

 Anche il discorso multiseriale, IMHO, dovrebbe essere visto, dall'OS,
come l'interfacciamento con un numero N di porte separate (solitamente 8
o 16), non come un "qualcosa di strano": in questo caso consiglierei di
utilizzare schede da 8 porte in quanto ho avuto esperienza (purtroppo non
diretta: altrimenti avrei probabilmente ucciso qualcuno) di multiseriali
a 16 porte alle quali mancavano, per motivi di cablaggio, alcuni criteri
(per me) basilari, tipo RTS/CTS (quello che, in Windows, viene chiamato
"controllo di flusso hardware"): questi venivano "sostituiti" con i noti
XON/XOFF applicativi (residuo di quando si faceva un cavo seriale con tre
fili ;))... e vi lascio immaginare quello che succedeva quando (A) la
scheda di controllo non era sufficientemente veloce nel polling dei
device, (B) il traffico sui canali era discretamente intenso (ed a
19k2bps o 38k8bps) oppure (C) l'ambiente era "disturbato" (per "scassare"
un XON/XOFF basta qualche disturbo sulla linea)... Siamo andati avanti
per MESI cercando di capire cosa andasse storto nelle comunicazioni...
con la ditta fornitrice del servizio che (più o meno giustamente)
affermava che i protocolli da loro utilizzati (una specie di gateway
seriale/SNA-SDLC) erano collaudatissimi, che avevano effettuato delle
trace e che il loro sistema non si perdeva nulla.

 Poi, un giorno, belli belli, i (nostri) sistemisti mi vengono a dire che
"ah... ma certo... nelle schede multiseriali a 16 porte mancano questi
criteri: non c'era abbastanza spazio per i fili aggiuntivi"...
GRRRRrrr... avrei voluto ucciderli (i numerosi clienti ci avevano già
ricoperti di... "fango" a tonnellate): OVVIAMENTE il gateway del
fornitore NON si perdeva nulla "se i segnali erano forniti correttamente"
(quindi ANCHE RTS/CTS) mentre, non potendo utilizzarli, erano costretti
ad emularli via software (cosa che, si sa, non è la più sicura del mondo
già su UN canale singolo... figuriamoci con sedici!).

 Quando ho chiesto "ma quanto costavano DUE schede da otto porte?" sono
stati MOLTO evasivi... in pratica risulta che siamo stati pesantemente (e
giustamente) insultati da una marea di clienti (soprattutto ditte) per
non aver speso una manciata di "euri".
 Comunque adesso tutto è finito bene: il servizio è in outsourcing... e
costa la bellezza di qualche centinaio di milioni all'anno (scusate:
50-100mila Euro/anno)... tutto per non aver comprato un paio di schede da
8 porte invece che una sola "risparmiosa" da 16.
(vabbè... e abbiamo raccontato anche l'aneddoto ;-)))))

 Alla fine di tutto, ovviamente, il maestro nel ramo industriale sei tu,
Erix: cosa manca nella mia (chiamiamola così) "analisi" delle esigenze di
Francesco? Sono stato troppo semplicistico?

      Ciao,
            Luca