Newsgroup: it.hobby.elettronica.digitale
Titolo: Sostituire un banale bus RS485 con Ethernet "nudo"

Siamo al solito problema. Una decina di nodi devono comunicare su un
bus. La distanza tra due nodi vicini è di circa 1 metro. Tutta la rete
non supera i 5 metri complessivi. Si tratta di scambio dati ai fini di
controllo, quindi un bitrate non molto alto (diciamo circa un
centinaio di byte per ogni comunicazione).
Ad oggi risolvo egregiamente con un banale bus RS485 4 fili (anche se
il protocollo è half-duplex): un micro con una porta UART collegata ad
un transceiver RS485. Tutti sono collegati insieme ed un nodo master
interroga a turno tutti i nodi slave.
Siccome vorrei aumentare la quantità di dati scambiati, diminuire il
tempo di interrogazione totale (dal primo all'ultimo nodo) e, magari,
avere la possibilità di avere più master, senza aumentare troppo i
costi e la complessità dei micro, stavo pensando di passare ad
Ethernet "nuda".
Intendo un micro semplice collegato ad un controller Ethernet (tipo il
Realtek RTL8019AS che vedo spesso) SENZA tutto lo stack TCP/IP.
Infatti a me non interessano tutti i servizi di instradamento che il
protocollo IP offre: i miei nodi si trovano tutti su uno stesso
segmento di rete.
Al massimo mi mancheranno i servizi di connessione del protocollo TCP,
ma non imprecherò per implementare lo stack TCP/IP.
In pratica, così come oggi trasmetto un pacchetto dati sulla UART,
vorrei inviare un pacchetto dati su Ethernet, SENZA preoccuparmi delle
collisioni e delle eventuali ritrasmissioni dovute a collisioni.
Il controller di cui sopra (o qualcosa di simile) in effetti gestisce
le collisioni e le ritrasmissioni in modo autonomo? Se gli dò in pasto
100 byte, posso contare che lui me li trasmetta in modo affidabile
senza appesantire il firmware del mio micro?
Cosa ne pensate di questa idea? Conoscete qualche applicazione/
progetto dove viene usato il bus Ethernet "nudo" con successo? Oppure
in questo caso è meglio andare su uno stack TCP/IP completo e quindi
su processori ben più complessi?
Tenete presente che non ho nessuna necessità di collegare computer o
schede di rete su questo bus che servirà per soli scopi interni.
Ancora non riesco a decidermi se rimanere la mia tanto amata, semplice
e affidabile RS485 oppure passare a qualcosa di più complesso come
Ethernet o CAN.

 ma non imprecherò per implementare lo stack TCP/IP.
cut...
Dai un'occhiata al ENC28J60 (Stand-Alone Ethernet Controller with SPI™
Interface) della Microchip.
Ne ho acquistati alcuni su Farnell, costano poco e hanno l'SPI che è
molto comoda.
Si trova anche molta letteratura in rete.
Anche io ho in progetto di utilizzare chip di rete senza per questo
uniformarmi ad uno standard.
I trasformatori di segnale 10BASE-T li ricavo da vecchie schede LAN
comprate ai mercatini.
Piccio.

 comprate ai mercatini.
In realtà devo fare una piccola produzione, quindi i trasformatori
posso
cercarli tra i normali canali di distribuzione. Inoltre penso che
possano
andare ugualmente bene quei connettori RJ45 per 10/100Mbps con
trasformatore incluso.

 Ethernet o CAN.
CAN non è complessissimo specialmente se non devi conformarti ad uno
standard (tipo Canopen per intendersi, da cui puoi comunque prendere
spunto per sviluppare il tuo protocollo); gestisce lui eventuali
conflitti (in pratica puoi trasmettere quando vuoi) e trovi tutti i
pacchetti ricevuti già pronti nelle "mailbox" del controller. Puoi
adoperare un micro con il controller integrato oppure affiancare un
controller esterno; ad esempio l'82527 della Intel ha interfaccia
parallela e SPI

 parallela e SPI
E come potrei risolvere il problema dei pacchetti molto piccoli sul
CAN?

 parallela e SPI
E come potrei risolvere il problema dei pacchetti molto piccoli sul
CAN?
Questo interesserebbe anche a me per un recente problema che devo risolvere.
Fino ad ora il pacchetto di 8bytes era pi� che sufficiente.
Ora per� ho necessit� di mandare un numero elevato di parametri con messaggi 
a lunghezza variabile.
Servirebbe uno stack capace di mettere in ordine i vari pacchetti e 
ricostruire il messaggio originale.
In teoria, abbastanza semplice...
Nella pratica sto per� incontrando diverse difficolt�....
Se qualcuno avesse un qualche spunto dal quale prendere riferimento, sarebbe 
bene accetto. 

Ciao
non puoi aumentare la velocita sulla 485? e magari portarla a 422?
se ormai hai conoscenza e pratica di questa tipologia di rete, visto che
hai pochi nodi, ti conviene passare ad una tipologia totalmente diversa?
emi

 bene accetto.
Per quanto riguarda Canopen puoi prendere a riferimento il
trasferimento di SDO "segmented", serve proprio per trasferire grosse
moli di dati. Altrimenti va gestito "a mano": pacchetto iniziale in
cui si indica quanti dati scambiare e poi macchinette a stati per
gestire i trasferimenti; il tutto considerando che fino a 30-40 metri
puoi comunicare ad 1 Mbit

 sarebbe bene accetto.
Senza scomodare protocolli particolari, hai un indirizzo di 29bit,
(Extended mode):usane una parte (8 o 16bit) come indice di pacchetto.
Con 8 bit puoi trasferire fino a 8*256 bytes, con 16 bit
puoi avere un messaggio dati da 65535*8. Puoi usare il valorre
di indice 00 come segnalatore di fine pacchetto.
Gli altri 13 bit dell' indirizzo usali per identificare il tipo
di pacchetto, allarmi etc...
bb.

 di pacchetto, allarmi etc...
E l'indirizzo del nodo? Oppure il campo indirizzo non è un vero e
proprio
indirizzo destinazione, ma semplicemente il tipo del messaggio inviato?

<b...@nospam.invalid> ha scritto nel messaggio 
news:aHOgn.120685$813.1...@tornado.fastwebnet.it...

Certo questa � la teoria e fino a qui ci siamo.
La mia difficolt� � nel gestire una rete can di 12 dispositivi, ognuno con 
il proprio indirizzo e che deve ovviamente gestire solo i messaggi a lui 
indirizzati.
Inoltre c'� da gestire anche il caso di ricezione pacchetti incompleti e 
quindi ritrasmessi....
E' per quello che ho detto che serve una implementazione di uno stack 
completo,

 Interface) della Microchip.
[...]
Altra cosa che mi spaventa dell'Ethernet è il cablaggio. Pur essendo
logicamente
un bus, la topologia è a stella. Hai bisogno di un hub o switch e
questo, penso,
farà lievitare molto i costi.
Esistono degli hub economici validi anche nel mondo industriale?
Alternativamente è fattibile implementare un "mini-hub" passivo a due
porte in
ogni nodo della rete in modo da fare un cablaggio lineare tra il primo
e il secondo
nodo, tra il secondo e il terzo e così via?


Se lavorassi con uno stack CANopen dovresti proprio fare cosi :-)
In realta' lo schema del CAN e' piuttosto flessibile: non
deve necessariamente essere di tipo master-slave o punto-punto.
Ci si puo' sbizzarrire parecchio.
(L' indirizzo non lo devi pensare per forza come qualche cosa di
separato dai dati: puo' essere usato per molti scopi, tra cui
al limite anche il trasporto di dati.)
Molto dipende dal controller CAN che usi:
C'e' ne di ogni tipo, SJA100, MSCAN, 82527, o quelli integrati
nei vari controller....
Alcuni, tipo l' 82527, permettono di configurare ogni
mail-box per ricevere/trasmettere un messaggio specifico
(max 15 mailbox per 82527).
Altri usano una FIFO generale (SJA1000)..
Quasi tutti hanno uno o due registri di filtro (AMR) che si possono
programmare per filtrare tutti o parte dei bit di indirizzo.
Ad esempio, puoi decidere che i primi 8bit sono dedicati
all' indirizzo del nodo e quindi configuri il filtro
per rendere significativi solo i primi 8 bit dell' indirizzo CAN
In questo modo un controller ricevera' solo i  messaggi
indirizzati a lui stesso :-)
cosi' ci si fuma la possibilita' di avere messaggi tipo 'broadcast'.
Prendendo due piccini con una fava:
 >Certo questa � la teoria e fino a qui ci siamo.
 >La mia difficolt� � nel gestire una rete can di 12 dispositivi, ognuno 
 >con il proprio indirizzo e che deve ovviamente gestire solo i messaggi 
 >a lui indirizzati.
Per gli indirizzi, Vedi sopra.
Puoi usare parte dell' indirizzo come identificatore del destinatario
e del mottente: ad esempio i bit [0..3] per l' indirizzo del
destinatario e i bit da [5..7] per l' indirizzo del mittente,
cosi' il destinatario sa a chi inoltrare le proprie risposte...
 >Inoltre c'� da gestire anche il caso di ricezione pacchetti incompleti 
 >e quindi ritrasmessi....
 >E' per quello che ho detto che serve una implementazione di uno stack 
 >completo,
Il CAN si occupa di ritrasmissioni dei messaggi, quindi la congruenza
sul singolo messaggio ed eventuali retry sono coperti dal protocollo
hardware. Pero' puo' essere che i messaggi siano persi dal firmware
sovrastante (magari non fa in tempo a processare i vari pacchetti
e hai un errore di overrun in ricezione).
(Non e' qui si pretenda di sviluppare via ng un protocollo completo:-))
Per mantenere le cose semplici: quando si invia un messaggio 'lungo'
ogni pacchetto sara' confermato dal ricevente con un mesaggio, magari 
vuoto, in cui in parte dei bit di indirizzo si conferma il pacchetto 
ricevuto, oppure si chiede la ritrasmissione o si indica l' abort....
Se i controller lo consentono, si possono anche mischiare messaggi di 
tipo EXTENDED con messaggi di tipo STANDARD (11bit), estendendo
le possibilita' ...
bb.

 su processori ben più complessi?
L'IP all'interno della stessa lan e'un'inutile appesantimento.
Gli indirizzi vengono sempre convertiti in mac-address grazie al 
protocollo arp, cioe' altro traffico sulla rete e necessita' di gestire 
anche l'arp...
ciao
Claudio_F

 Ethernet o CAN
Il CAN bus sostanzialmente � una RS485 pi� robusta, nata per applicazioni 
automotive.
Prima di pensare a come fare a forzare qualcosa nato e ottimizzato per un 
particolare utilizzo, fossi in te mi chiederei come sfruttare al meglio 
l'economica e molto funzionale RS485!!
Ciao
CG