Newsgroup: it.hobby.elettronica.digitale
Titolo: CAN bus al posto di una RS485

Volevo passare da un bus RS485 a singolo master, ad un bus CAN 
multi-master. Sembra che il CAN risolva facilmente le problematiche 
relative ai conflitti dovuti alla presenza di più master sul bus.
 
Quello che non mi è chiaro è quanto semplice è, alla fine della giostra, 
inviare pacchetti "arbitrariamente" lunghi da un nodo della rete ad un 
altro nodo della rete.
 
Infatti sembra che il CAN sia limitato a messaggi di 8 byte e non esiste 
un indirizzamento, piuttosto una priorità del messaggio. Con la RS485, 
invece, io scambio pacchetti arbitrari di 100-200 byte.
 
Oltre al CAN servirà qualche altro layer software, tipo il CANOpen? Mi 
sembrano protocolli molto più complicati della classica RS485.

 Mi sembrano protocolli molto più complicati della classica RS485.
Proprio perche' sei limitato da 8byte di messaggio...
ma e' un limite solo apparente: dipende tutto da cosa vuoi
fare. Giostrando opportunamente l' ID a 29bit si possono
implementare un sacco di cose ;-)
Ovviamente, richiede uno strato di 'protocollo' un poco
piu' complesso per pacchettizare dati lunghi :-)
Puoi guardarti questo:
http://www.kvaser.com/en/about-can/higher-layer-protocols/40.html
 
Bye
AA
 

 
http://www.kvaser.com/en/about-can/higher-layer-protocols/40.html
 
 
Darò un'occhiata, grazie.

 Il contenuto di entrambi i pacchetti è abbastanza variabile.
 
 
Questo è abbastanza tipico.
Io attualmente sto implementando qualcosa di simile anche se su un'altra 
rete.
 
Secondo il mio parere dipende soprattutto dalla probabilità delle 
collisioni e dalle conseguenze che ne derivano.
Se sono pacchetti piccoli (come tempo di trasmissione) e sporadici è ben 
diverso da stream di dati più consistenti.
 
Nel mio caso ho inserito un nodo "arbitro" che mi evita completamente le 
collisioni e mi ottimizza le latenze pur non essendo tecnicamente un 
multimaster.
 
Il nodo arbitro ciclicamente (e secondo una certa priorità) da la parola 
a ciascun nodo pseudo-master. Se questi ultimi hanno qualcosa da dire lo 
dicono subito altrimenti dicono "passo".
 
I client destinatari del pacchetto rispondono immediatamente con un ack 
o con il contenuto della risposta se ce l'hanno pronta così da liberare 
il bus. Altrimenti rispondono con una richiesta di prenotazione a x ms. 
L'arbitro li inserisce quindi in coda e gli darà il permesso di parlare 
allo scadere degli x ms.
 
 
Sembra complesso ma nella pratica è molto facile da gestire e molto 
adattabile (es. puoi leggere una temperatura ogni 10 secondi ma un 
sensore di pressione ogni 100 ms). Soprattutto ti permette di avere sia 
i vantaggi di una rete multi-master sia quelli di un protocollo 
fisico/logico molto semplice.
 
I miei 0.02$
Marco
 
 

 Il contenuto di entrambi i pacchetti è abbastanza variabile.
 
Il modo piu' semplice e' di incapsulare i tuoi frame, protocollo 
compreso, in messaggi CAN.
Nell' ID ci metti il tuo destination/source giusto per sfruttate qualche 
funzionalità del CAN :-)
Nel resto dell' ID messaggio puoi metterci un contatore di sequenza: con 
8bit numeri 256 pachetti da 8byte(max) e puoi trasmettere
pacchetti fino a 2048bytes.
Esempio:
ID[0..7] = Destination (da 1 a 255,ad esempio: 0=Broadcast)
ID[8..15]= source (mai zero)
ID[16..23]= contatore pacchetto:0,n, 0=START, ... n=255
ID[24..28]= Usate per discriminare il tipo di messaggi..se serve
             se no usa il protocollo RS485...
Cosi' te la cavi con la sola gestione dell' ID :-)
Certo che non sfrutta granche' delle particolarita' del CAN
ma e' semplice da implementare...
Bye
AA.
 
 
 
 
 
 
 
 
 
 
 
 

 I miei 0.02$
 
Grazie dei tuoi commenti.
 

 ma e' semplice da implementare...
 
Visto che l'appetito vien mangiando, che tipo di particolarità del CAN 
si potrebbero sfruttare a proprio vantaggio?
 
 
Un'altra domanda, sempre a proposito della gestione delle collisioni sul 
CAN. Immagino che un controller CAN, che automaticamente risolve le 
collisioni eventualmente ritrasmettendo il frame a più bassa priorità, 
abbia internamente almeno un buffer grande quanto la dimensione massima 
di un messaggio (8 byte di payload, non considerando l'ID). A livello 
più alto (da implementare software), considerando la trasmissione di 
pacchetti ben più grandi divisi in messaggini CAN da 8 byte, come va 
gestita la collisione?

 gestita la collisione?
Te ne sbatti, ci pensa il CAN controller. Tu ricevi un messaggio
o un errore di comunicazione, non ti devi preoccupare di altro.
Puoi attaccare un interrupt all' evento RX e pucci il tutto
in un buffer circolare, quindi il tuo processo esterno provvede ad
utilizzarli, ricostruendo il tuo pacchetto dati etc...
Se ti mancano pacchetti dati (perdita di sequenza) dovrai gestire
l' errore: La perdita di pacchetti, piu' che a errori del bus, puo' 
essere dovuta ad un overrun del buffer di ricezione, causata da
lettezza nel servire l'evento o altri problemi software TBD.
Ovviamente un sistema robusto dovra' tenere in debita considerazione
le anomalie che possono capitare ;-)
 
AA.

nodo A, dandoglielo soltanto dopo i 10 secondi.
 
Se sa che il dato va letto ogni 10 secondi la scansione interrogher� il device
solo ogni 10 secondi, evitando di impegnare la linea inutilmente.
 
In definitiva, se hai bisogno di risposte veloci dalle periferiche, e i dati in
transito non sono molti allora ha senso implementare il CAN, se viceversa le
risposte non sono necessariamente immediate i magari i pacchetti sono di qualche
centinaio di bytes, allora meglio una RS485.
 
Dopotutto il CAN � nato per uso in campo automotive, dove le priorit� sono la
velocit� e la sicurezza e i pacchetti sono di solito brevi.
 
 
--
ciao
  Stefano

 nodo A, dandoglielo soltanto dopo i 10 secondi.
 
 
Si, proprio perché risulta che non ha bisogno di frequenti 
interrogazioni. Ma questo lo deve sapere prima il progettista :)
 
Marco
 
 

 le anomalie che possono capitare ;-)
 
Ovviamente, grazie mille dei suggerimenti.
 
 
Un'ultimissima domanda. Se proprio volessi andare su un protocollo 
"standard" di livello superiore al CAN per gestire pacchetti di 
lunghezza maggiore, mi potresti indicare qualcosa di semplice ed 
efficace (CANKingdom? CANOpen? DeviceNet?) oppure è molto meglio 
implementare quello da te suggerito, cioè prendi il pacchetto RS485 e lo 
dividi in tanti messaggini da 8 bytes?
 

 dividi in tanti messaggini da 8 bytes?
Direi la seconda, ma una scorsa ai protocolli citati non fa mai
male :-)
 
CANKIndom e' il piu' aderente alle particolarita' del CAN.
CANopen e' orientato all' automazione e relativi attuatori
con supporto alla configurazione standardizzata di vari
'profili' d'uso (che so, schede digitali/analogiche/Motion control..)
Per messaggi lunghi usa il protocollo 'segmented SDO', che
e' abbastanza semplice, ma (IMHO) abbastanza poco efficiente.
DEVICEnet e' abbastanza simile al CANopen,, un po' piu' limitato,
ed e' usato sopratutto negli USA, mentre CANopen e' piu' World-wide.
Se devi proprio aderire ad uno standard, meglio CANopen, mentre
se sei libero di sbizzarrirti ti consiglio di ridisegnare ex novo
un protocollo semplice ed adeguato alle particolarita' del CAN
e alle tue necessita'.
 
Come linee guida terrei solo alcune del tipo:
- Messaggi ad alta priorita' (real-time/urgenze) limitati a 8byte
   (event/driven o a tempo se non ci sono variazioni)
- Messaggi di configurazione/upgrade software >8byte a bassa
   priorità e pacchettizati con protocollo il piu' semplice
   possibile (numero di sequenza).
- Se usi un approccio event-driven, prevedi un messaggio di
   watch-dog di qualche tipo.
- se serve, aggiungi un messaggio 'annuncio' ogni volta che
   un nodo si aggiunge dinamicamente al bus.
 
Buye
AA.
 
 
 

 invece, io scambio pacchetti arbitrari di 100-200 byte.
 
avevo lo stesso problema. Ho fatto una pazzia e ho usato arcnet. 
Elettricamente e' una 485. Ora devo dire che sono piu' che soddisfatto e 
la uso dove posso farlo.


Bello, ma Arcnet ha pochissimo supporto e richiede un chip
dedicato che aumenta il costo, non lo trovi integrato come
il CAN praticamente ovuque a bassisimo costo.
A questo punto meglio una Ethernet, gia' integrara in molti
micro con uno switch davanti per fare una catena :-)
AA.
 
 
 
 

 uno switch davanti per fare una catena AA.
 
tutto vero, c'e' l'smsc che fa dei chip molto facili da usare. Sbatti il 
pacco di bytes in una ram e poi si arrangia a negoziare e a far partire. 
Pero' in ambito industriale e' molto piu' efficace di ethernet, sia per 
costi che per resistenza agli ambienti disturbati. Poi a livello di 
performance e' gestibile da processori che lavorano in real time che non 
necessitano di "forze" particolari. Non ha bisogno di stack e ne' di 
tcpip. Basta una buona routine che gestisca gli interrupt in maniera 
adeguata. L'ho appena implementato in una scheda con atmega8, per capirci.
Il can e' quello piu' usato, vero.... pero' come ti dicevo avevo una mole 
di dati piuttosto corposa da far transitare. 

 di dati piuttosto corposa da far transitare.
Si, e' facile da usare ma rimane un prodotto di nicchia,
l'ho utilizzato una decina d'anni fa ma poi e' sparito il
chip e si rifece il tutto con CAN integrato in un ARM.
Sarebbe interessante vedere se FlexRay prima o poi si
affermi in campo Automotive: di sicuro potrebbe avere
una diffusione piu' massiccia... ma ormai e' qualche
anno che gira e non sembra decollare ...
AA.
 
 
 
 
 

 FlexRay
 
questo fleaxray in particolare, non lo conoscevo. Grazie. Questo ng mi 
piace :).

 dedicato che aumenta il costo,
 
Non è pensabile implementarlo solo via sw su una semplice RS485?
 

 tcpip.
 
Tempo fa avevo pensato di usare Ethernet... ma *solo* Ethernet, senza 
protocolli applicativi o di trasporto (TCP/IP). In pratica utilizzerei 
il MAC Ethernet giusto per risolvere, senza troppi sbattimenti, il 
problema dell'accesso condiviso alla rete.
 
Microchip fa (o faceva) un controller Ethernet (mi sembra MAC+PHY) 
10Mbps (più che sufficiente, direi, visto che lo paragoniamo a RS485 o 
CAN) con interfaccia SPI con il controllore.
Non ho approfondito gli aspetti, ma penso basti dire al chip di inviare 
N bytes (trasferendoli su SPI) in un frame Ethernet e il chip dovrebbe 
risolvere il problema dei conflitti.
Bisognerebbe aggiungere soltanto un RJ45 con trasformatori integrati e 
un hub/switch. Sicuramente è una soluzione più costosa.

 problema dell'accesso condiviso alla rete.
 
sai che come idea non era poi malvagia?

 Non è pensabile implementarlo solo via sw su una semplice RS485?
 
a dirti la verita' non saprei proprio da dove cominciare. E' una token 
ring, simularla al 100% sarebbe un casino. Pensa che con l'oscilloscopio 
faccio fatica a capire "cosa passa". Vuoi mettere la pura 485 master 
slave....