Newsgroup: it.hobby.elettronica.digitale
Titolo: TCP/IP o altro?

Ciao!
Ennesima discussione sulla scelta di protocolli, ma stavolta anche 
considerando il layer fisico...
Dunque, vorrei utilizzare un canale di comunicazione (bus) che abbia 
queste caratteristiche:
* multinodale (almeno 32 nodi)
* multimaster dinamico (cioè un client può essere contemporaneamente 
anche server su un altro canale, vedi sotto)
* coesistenza di più canali di comunicazione "virtuali" (appunto)
* possibilità di inviare messaggi broadcast
* garanzia della consegna e gestione delle collisioni
* banda di almeno 250 kBps (di payload, escludendo quindi gli header)
La lunghezza complessiva del bus non dovrebbe superare i 10 m, almeno 
nella prima versione.
In pratica quello che mi serve è riuscire a creare una rete tra n 
schedine, ciascuna delle quali deve poter dialogare in maniera 
indipendente con un gruppo di altre (da 1 a n-1). Ci possono essere 
anche più collegamenti contemporaneamente sullo stesso bus. I dati da 
scambiare sarebbero pacchetti di un centinaio di byte (con un refresh di 
qualche decina di Hz).
Volendo con una RS485 e un po' di inventiva si può realizzare il tutto, 
ma non è proprio elegante.
Mi sono venuti in mente i programmini client/server in ambiente di rete: 
in pratica realizzo una normale rete Ethernet tra le schede e configuro 
i vari socket come necessario. Mi basta arrivare al livello di 
trasporto, nel senso che il livello applicativo altro non è che il mio 
programma.
Con il TCP/IP dovrei riuscire a soddisfare tutti i punti di cui sopra se 
non m'inganno. Se dovessi farlo tra PC non vi sarebbero problemi: ma 
utilizzando dei uC (quasi sicuramente degli Armettini) ci posso riuscire 
ugualmente? Mi riferisco più che altro alla gestione di più socket 
contemporaneamente, quindi a dei fork lato server....
Sfogatevi pure con eventuali idee :)
--
Marco / iw2nzm

 [...]
Una parola sola: CAN!
A.D.

   
Direi proprio di si, ha tutte le caratteristiche desiderate e di piu'.
I messaggi CAN sono limitati a max 8byte+ 11bit o 29bit,
se servono messaggi piu' lunghi, vanno spezzati in pacchetti.
B.

 programma.
Non confondere Ethernet con TCP/IP. Non hanno nulla a che vedere.

F. Bertolazzi ha scritto:

Ho forse usato impropriamente il termine Ethernet per riferirmi al 
livello fisico che utilizza gli RJ45. Il protocollo sul quale intendevo 
orientarmi era appunto il TCP/IP.
Grazie della precisazione
Marco / iw2nzm

 Una parola sola: CAN!
Can I?
Il mio nuovo motto :)
Ok, mi metto a studiarlo!
Marco / iw2nzm

 orientarmi era appunto il TCP/IP.
Che, in teoria puoi benissimo "appoggiare" sul protocollo fisico del CAN.
Il CAN è un ottimo protocollo, fondamentalmente è un RS485 in cui gli
"space", ovvero quando il livello del + (o A che dir si voglia) è alto e
del - (o B che dir si voglia) basso sono sostituiti da un'alta impedenza.
In pratica trasmetti solo i "mark", ovvero gli zeri e quindi non solo non
puoi avere conflitti elettrici, ma puoi, durante la trasmissione, rilevare
eventuali collisioni.


Mi accodo in ritardo al consiglio. Quando mi è capitato di usarlo non
ci sono stati problemi di sorta (C167 Infineon).
Il suggerimento che mi sento di aggiungere è, anzichè farti un tuo
protocollo sopra il layer fisico, di utilizzare dei protocolli già
belli e pronti come il CANOpen.
Non so esattamente su che micro hai intenzione di fare il lavoro ma,
come esempio, qui [
http://www.port.de/engl/canprod/content/
sw_lib_atmel.html] c'è una implementazione del CANOpen su micro Atmel
(AVR e AT91SAM7) con parecchia documentazione (ma non ho idea dei
costi della loro licenza).
Cordiali saluti
Pietro