Newsgroup: it.hobby.elettronica.digitale
Titolo: CAN bus

Nessuno ha mai utilizzato a livello hobbistico il
protocollo CAN.
Dove si possono aquistare dispositivi come il MCP2551
della Microchip (a prezzi onesti).
CIAO

 ha scritto nel messaggio
news:FDoZb.20083$Kc3.6...@twister2.libero.it...


 ha scritto nel messaggio
news:FDoZb.20083$Kc3.6...@twister2.libero.it...

Usare il CAN a livello obbistico mi sembra un'assurdità!
Il protocollo è molto complesso e in amatorialmente non ha alcun senso
usarlo.
Molto probabilmente i tuoi interessi vanno fuori del livello Hobbistico ...
Io ci sto lavorando e non è semplice per niente ma dipende anche molto da
quello che devi fare.
il MCP2551 non è l'unica soluzione. Dipende molto, sia a livello HW che a
livello SW, da quello che devi ottente e dalla complessità.
Ciao
FACE ONE

 usarlo.
Beh, non direi proprio. Ovviamente non stiamo parlando di implementare
l'intero protocollo CAN (livello fisico, dati e rete), ma semplicemente
di usare gli appositi controller CAN che fanno gia` tutto loro, a te non
resta che impostare le maschere e ricevere gli interrupt. Di fatto
utilizzare un 82527 e` facile quanto usare un UART...
-- 
Lorenzo

 ha scritto nel messaggio
news:tmLZb.23264$FJ6.8...@twister1.libero.it...


?
Un momento ... mi sfugge qualcosa.
Le soluzioni per usare un CAN sono diverse.
Prendiamo ad esempio il PIC 18F458 con il CAN 2.0B già integrato.
Praticamente ha il controller già integrato e basta attaccagli un
Transceiver (non ricordo la sigla) che ha funzioni analoghe ad un max232 per
la RS232 ma in questo caso relativa al CAN.
Il problema ora è come faccio a inviare dati sul CAN secondo le specifiche
del protocollo ?
Che io sappia fare questo non è poi così semplice. Se è così vuol dire che
non c'ho capito niente!
Tra le application note della Microchip c'è parecchio materiale relativo
alla gestione del CAN bus in C.
Anche la motorola ha qualcosa di analogo. Prendiamo la serie HC12. Le
routine di gestione le sforna il CW ma non sono affatto banali.
Una cosa curiosa è che tutti i produttori implementano il CAN solo su micro
a 16 bit. Non che ad 8 non si possa fare ma ...
Tutto questo ovviamente è valido se si vuole implementare il CAN secondo le
specifiche.
Se poi si usa il CAN solo a livello elettrico (facendoci passare qualsiasi
tipo di dato) ovviamente è tutto un altro discorso.
In questo caso potrei suggerire l'uso di una 485 o simili.
Il CAN è pur sempre un bus di campo e come tale di non facile gestione.
Comunque sarei felice di discutere in maniera più approfondita
sull'argomento che, in questo perido,  mi interessa molto.
Ciao
FACE ONE


L'HC08 è un 8 bit: l'abbiamo usato su diverse centraline per un famoso
produttore di auto di lusso con protocollo Can Bus.
E secondo me, studiare non fa mai male (forse un pò al portafoglio ......).
Ciao
Drugo

 ha scritto nel messaggio
news:c18a6f$giv$1...@lacerta.tiscalinet.it...

Ciao Drugo,
questo che dici conferma quello che ho detto ovvero che su un 8 bit si può
fare.
Conosco anche persone che hanno sviluppato il CAN sul 6809.
Non è un problema di studio (anch'io sono d'accordo sul fatto che non faccia
mai male ... anzi) ma più un problema di tempi.
Sono dell'idea che con un buon lavoro si può ottenere praticamente di tutto
ma il problema è:
quanto tempo impieghi per sviluppare su di un micro già predisposto per una
certa funzione rispetto ad uno in cui devi fare tutto da zero ?
Se la cosa è per puro diletto è un conto ma se fa parte di un lavoro
commissionato dove il tempo  (e il budget) è ridotto sei praticamente
costretto ad usare la soluzione più semplice anche se didatticamente non sia
il massimo.
Questa è la mia idea ma non è detta che sia giusta.
Tornando al tuo esempio ... anch'io lavoro sui HC08 che considero ottimi
sopratutto in unione al CW e con questi ci fai vermanet di tutto. il fatto è
che la Motorola stessa ha deciso di sviluppare una serie di micro con
supporto nativo per il CAN bus solo per facilitare il compito. La scelta è
ricaduta sulla serie HCS12.
Comunque, visto che tu/voi avete affrontato già il problema mi piacerebbe
confrontarmi con voi. Qualsiasi suggerimento e/o dritta sarebbe estremamente
gradito.
Ciao e Grazie
FACE ONE

 Il CAN è pur sempre un bus di campo e come tale di non facile gestione.
No, il CAN è facilissimo da usare. Discorso diverso è se vuoi realizzare
un controllor CAN. Ma perché farlo? Usane uno già fatto :-)))
Ciao

 sull'argomento che, in questo perido,  mi interessa molto.
Io sono un sostenitore del bus CAN, lo metterei dovunque! ;-)
Per ora l'ho usato solo per cose "ortodosse" (interfacciamento a
centraline motore e altre cose "tipiche" che usano la CAN), ma non
escludo in futuro di considerare anche altre applicazioni. Su
free.it.discussioni.domotica ad esempio si e` accennato a utilizzarlo
appunto per scopi di controllo domotico.
-- 
Lorenzo

> Io sono un sostenitore del bus CAN, lo metterei dovunque! ;-)
Potresti descrivermi brevemente di cosa si tratta? Questo post ha suscitato
la mia curiosità... :)
Avevo cercato qualcosa sul CAN tempo fa, ma non sono arrivato neanche a
capire se è un protocollo, uno standard elettrico o entrambi...
--
...:::Zmaster:::...
DSL powered
zmast[ANTISPAMSYSTEM]@
freemail.it
www.zmaster.tk
Collaboratore del Media Player Project


Ciao Lorenzo,
mi rivolgo a te ma in realtà mi rivolto a tutti quelli che stanno seguendo
questo thread.
Avete dei siti da indicarmi per reperire informazioni, esempi o quant'altro
possa essere utile a capire meglio il protocollo ma sopratutto il suo
utilizzo.
Tutti voi state grossomodo dicendo che usare un CAN è come usare una UART.
Mi date qualche dritta per vedere qualcosa di già funzionate, anche se molto
semplice. Giusto per avere un confronto con altri che ci hanno già sbattuto
i denti.
Io non riesco a vederlo così semplice. Probabilmente mi sto complicando la
vita.
E' vero che basta andare a scriver sui registri ma non mi venite a dire che
basta dare un'occhiata al maniale del controller, buttare giù due righe e
riuscire di botto ad inviare dati su CAN.
Grazie a tutti
Ciao
FACE ONE

 riuscire di botto ad inviare dati su CAN.
Non te lo posso dire, ma posso scrivertelo :-P
"basta dare un'occhiata al maniale del controller, buttare giù due righe e
riuscire di botto ad inviare dati su CAN."
Senza scherzare, é veramente facile come una UART. Ma molto più
versatile :-)
Puoi anche collegarti ad una rete esistente SENZA CONOSCERE
IL BITRATE e poterlo detettare in automatico con un ciclo for!
--
***** By The Overkill !!! *****


???
Mi prendi in giro ?
Non ti chiedo di darmi schemi e sorgenti ma potresti fare un esempio ?
Quale micro e/o controller e/o transceiver usi ?
Con cosa sviluppi ? In che linguaggio ?
Io sto studiando il PIC 18F458 con controller CAN BUS 2.0B integrato usando
le routine che la Microchip mette a disposizione sul loro sito come
application notes.
Sto valutando anche la soluzione con i Motorola della serie HCS12 anch'essi
con il controller integrato. Il codewarrior genera le routine relative alla
gestione del CAN BUS.
Hai qualche sito di riferimento dove prendere spunto o altro materiale utile
?
Grazie e buona lavoro.
Ciao
FACE ONE

 ha scritto nel messaggio
news:c18a6f$giv$1...@lacerta.tiscalinet.it...

In alternativa puoi usare i micro della NEC moooolto usati ed omologati da
tutte le maggiori case automobilistiche,
il Motorola va molto bene, le differenze principali fra i due micro sono nel
numero e nel modo con cui sono gestiti i buffer
interni per il CAN bus, inoltre si hanno possibilità differenti per
mascherare determinati messaggi (ID) impostando alcune
maschere predefinite. In questo modo molto del lavoro viene eseguito dal
micro che ti avvisa e rende disponibili solo i
messaggi che sono in accordo con il criterio di selezione specificato.
In alternativa al CAN puoi usare il LIN che è un sotto dialetto del primo
(molto usato nelle auto francesi per servizi di importanza secondaria).
Ciao
Pow


Del CAN solo una cosa è piuttosto sgradevole, azioni le frecce  e la
segnalazione della
spia del cruscotto non è sincrona con il lampeggio delle frecce (cosa a cui
ci ha abituato il buon vecchio controllo tramite relay) ;-)
Ciao
Pow

 Hai qualche sito di riferimento dove prendere spunto o altro materiale
utile
Se vuoi lavorare con il CAN ti serve anche il transceiver esterno, quindi il
dispositivo che
ti permette di interfacciare la tua applicazione con la rete CAN esistente,
esistono sostanzialmente due tipi di driver maggiormente utilizzati:
1) PHILIPS TJA1054A Fault-Tolerant CAN transceiver (low-speed application up
to 125 kBaud)
2) INFINEON TLE6250 Fault-Tolerant CAN transceiver (high-speed application
up to 1MBaud)
Se vuoi qualche doc sulle applicazioni cerca il documento della PHILIPS sui
fault-tolerant transceiver serie PCA82C252/TJA1053/TJA1054/TJA1054A il cui
titolo dovrebbe essere: FTCAN 3_1.PDF per la versione 3.1 del 23/11/2001.
Il CAN inoltre presenta un'interfaccia che può essere di due tipi differenti
il dual-CAN (differenziale) ed il single-CAN (single ended), il primo usato
per le trasmissioni ad alto baud rate il secondo per le trasmissioni a basso
baud-rate (33.33 Kbits/s oppure 83.33 kbits/s per le trasmissioni di
servizio).
Tieni presente che i valori che ti ho riportato sono quelli citati nei
capitolati automotive, in ogni caso il bus è veramente versatile,
sicuramente molto più semplice del Profibus, altro bus di campo molto usato
nell'industria, il CAN è nato essenzialmente per applicazioni automotive
(BOSCH).
Se vuoi leggere un libro che introduca al CAN puoi fare riferimento al
seguente testo:
"Controller Area Network" Basic, Protocol, Chip and Applications di Konrad
Etschberger
edito dalla IXXAT Automation GmbH
ISBN: 3-00-007376-0
Io lo acquistai su Amazon per 80$ circa 1 anno fa.
Ciao
Pow

Dimenticavo ...
come micro puoi fare anche riferimento al uPD78F9850(A) micro molto piccolo
30 pin, ed anche parecchio usato nelle applicazioni automotive (supporta CAN
controller a bassa velocità), oppure uPD78F0818 che supporta il full CAN ad
1 M ma 64 pin TQFP.
Per il Microchip leggiti la AN754, AN815.
Per info sul LIN bus leggi la AN729 sempre Microchip, un transceiver adatto
è il TLE6258 della Infineon.
Per maggiori info sul CAN vai al seguente link:
http://www.hitex.co.uk/CAN/canarticle.html
Ciao
Pow

 Grazie e buona lavoro.
Di nulla buon lavoro a te.
Vedrai che quando avrai fatto funzionare la tua epriferica CAN dirai:
Beh, tutto qui!
:-))
Ciao.


 ha scritto nel messaggio
news:Gru_b.12496$gk.5...@news3.tin.it...

Fantastico! Grazie per le info!
Ciao
FACE ONE

 ha scritto nel messaggio
news:1Bu_b.12542$gk.5...@news3.tin.it...

Non ho parole ... sei stato utilissimo.
Ciao
FACE ONE

 ha scritto nel messaggio
news:fvw_b.852$ND4...@tornado.fastwebnet.it...

Per il momento ti ringrazio enormemente per le info.
Spero che tra un pò di giorni possa tornare a postare sul tema dicendo ...
"Avevi ragione !"
Grazie ancora
Ciao
FACE ONE

 entrambi...
E` entrambi, definisce sia il livello fisico che il livello dati (usando
i termini dell'astrazione ISO-OSI). Esistono standard "superiori", tipo
CANopen, che definiscono anche i livelli rete e trasporto, ma non fanno
strettamente parte dello standard CAN.
CAN e` uno standard progettato dalla Bosch, il cui scopo originario (e,
nella stragrande maggioranza dei casi, anche lo scopo attuale) era
quello di fornire un collegamento fra i vari componenti di un
autoveicolo, piu` o meno intelligenti: sensori, sistemi di controllo,
centraline di qualsiasi genere. Gli obiettivi sono quindi:
-Robustezza e velocita`: a livello fisico la CAN e` simile all'RS485,
trasmissione differenziale su doppino twistato, con distanze da qualche
decina di metri nel caso che si trasmetta alla velocita` massima (1
Mbps) fino ad oltre un chilometro per bit rate piu` basse;
-Determinismo: si possono assegnare diverse priorita` ai pacchetti,
garantendo una latenza massima nel caso che il bus sia usato per scopi
di controllo realtime;
-Multipoint e failure detection: si possono collegare piu` endpoint
contemporaneamente (non c'e` un limite fissato dal protocollo, per i
transceiver piu` comuni e` attorno al centinaio); nel caso che un
endpoint sia malfunzionante, il bus e` in grado di escluderlo
autonomamente;
-Protocollo affidabile: viene effettuato il controllo+correzione degli
errori, ed e` garantito che ciascun messaggio sia ricevuto da tutti
oppure da nessun endpoint. In caso di errore viene effettuata la
ritrasmissione automatica non appena possibile;
-Connectionless: i messaggi non sono diretti a destinazioni specifiche,
hanno un ID che li identifica e ogni endpoint decide autonomamente (in
base a delle maschere che si possono impostare) se il messaggio gli
"interessa" oppure no. Questo ovviamente implica che si possano spedire
messaggi anche a piu` endpoint contemporaneamente. La semantica degli ID
e del contenuto dei messaggi non fa parte dello standard CAN - anzi, in
molti casi e` la parte piu` rognosa quando ti devi interfacciare a
qualcosa e il produttore (carogna) non ti allunga il protocollo. :)
Sul sito che ho citato (
http://www.can.bosch.com/
) puoi trovare molta
documentazione aggiuntiva. Altra documentazione interessante la trovi
con una ricerca mirata:
http://www.google.com/search?q=
"CAN%20bus"%20CSMA
CSMA e` il tipo di arbitraggio utilizzato dalla CAN, che ti garantisce
che Google ti mostri solo dei link privi di fuffa. :)
-- 
Lorenzo

 che Google ti mostri solo dei link privi di fuffa. :)
Grazie per le delucidazioni... in effetti sembra molto interessante, anzi,
complesso forse č una parola migliore: senza appositi driver gestire un bus
del genere deve essere piuttosto... rognoso ^__^ .
Tutto sommato per quello che ho dovuto fare io mi basta anche la 485, perň
mi sono dovuto fare un protocollo proprietario e sono ricorso a varie
semplificazioni... probabilmente si tratta anche di una soluzione piů
economica perchč basta un semplice MAX485, cmq puň darsi che in futuro ci
dia un'occhiata, sempra molto piů potente ;)
Grazie.
