Home
Accesso / Registrazione
 di 

Can bus Debug con l'oscilloscopio digitale

CAN nell'automotive

Il CAN (Controller Area Network) era stato inizialmente sviluppato negli anni ’80 dalla Robert Bosch GmbH come un bus low-cost per le comunicazioni tra dispositivi in ambienti elettronicamente rumorosi. Mercedes-Benz è diventato il primo produttore nell’automotive, nel 1992, ad implementare il CAN nei propri sistemi. Oggi, quasi tutti i produttori di auto utilizzano controller CAN per controllare una varietà di dispositivi presenti nelle automobili. Un nuovo e più economico bus, chiamato LIN (di cui si parla più avanti), fu sviluppato per prendere il posto di CAN quando quest’ultimo risultava meno veloce, versatile e più costoso. Nonostante questo, CAN è ancora è ancora il bus primario utilizzato, tra gli altri, per il controllo del timing del motore, degli ABS e del power train. E grazie alla sua tolleranza al rumore, ad un circuito elettrico ridotto, ad eccellenti capacità di individuazione dell’errore e all’alta velocità nel trasferimento di dati, il CAN si sta rapidamente espandendo in altre applicazioni, tra cui l’industria spaziale, marina e medica.

CanBus: come funziona

Il bus CAN è un’interfaccia bilanciata (differenziale) a due fili che opera su STP (Shielded Twisted Pair) o su un UTP (Un-shielded Twisted Pair). Ogni nodo usa un connettore maschio D a 9 pin. Per assicurare messaggi compatti con un numero minimo di transizioni ed un’alta immunità al rumore, viene utilizzata una codifica di bit NRZ con bit stuffing.

L’interfaccia di bus CAN utilizza una schema di trasmissione asincrono in cui ogni nodo può iniziare a trasmettere in qualunque momento il bus è libero. I messaggi sono trasmessi a tutti i nodi sul network. Nei casi in cui più nodi danno avvio a messaggi nello stesso tempo, viene utilizzato l’arbitraggio bitwise per determinare quale messaggio ha la priorità più alta.

I messaggi possono essere di quattro tipi: Data Frame, Remote Transmission Request (RTR) Frame, Error Frame, o Overload Frame. Ogni nodo sul bus che individua un errore trasmette un error frame che permette a tutti i nodi sul bus di vedere il messaggio corrente come incompleto e al nodo trasmittente di rinviare il messaggio.

Gli Overload Frame vengono avviati dai dispositivi riceventi per indicare che non sono ancora pronti a ricevere dati.

I Data Frame vengono utilizzati per trasmettere i dati mentre i Remote Frame richiedono i dati.

I frame Data e Remote sono controllati da bit start e stop all’inizio e alla fine di ogni frame e includono i seguenti campi: Arbitration field, Control field, Data field, CRC field e un ACK field, come mostrato in figura.

Debuggare il CAN BUS con l'utilizzo dell'oscilloscopio digitale

I moduli di applicazione DPOxAUTO e DPO4AUTOMAX Serial Triggering and Analysis della serie MSO/DPO abilitano simili caratteristiche di triggering e di analisi per il bus CAN.

Utilizzando i tasti del pannello frontale del bus, è possibile definire un bus CAN semplicemente inserendo i parametri base del bus, quali il tipo di segnale CAN, il bit rate, il punto di soglia, ecc. La figura mostra quanto appena detto.

Immaginate di avere bisogno di prendere delle misurazioni di tempo associate con la latenza da quando viene spinto lo switch Passenger Window Down a quando il modulo CAN nella porta del guidatore manda il comando, e poi lo switch realmente comincia a muoversi.

Specificando l’ID del modulo CAN nella porta del guidatore e i dati associati ad un comando ‘roll the window down’, è possibile innescare l’esatto data frame che si sta cercando. Esaminando contemporaneamente lo switch Window Down sulla porta del guidatore e il motor drive nella porta del passeggero, questa misurazione temporale diventa eccezionalmente facile, come mostrato in figura.

I triangoli bianchi nella figura sono segni messi sulla linea come punti di riferimento e si possono aggiungere o rimuovere sullo schermo premendo il tasto Set/Clear Mark sul pannello frontale dell’oscilloscopio. Premendo i tasti Previous e Next sul pannello frontale si può passare facilmente da un segno ad un altro.

Adesso immaginate di ripetere quanto illustrato finora senza le capacità appena descritte. Senza il CAN triggering bisogna innescare lo switch, ottenere quello che si spera sia uno spazio temporale di attività abbastanza lungo e poi iniziare manualmente la decodifica frame dopo frame sul bus CAN fino a quando si trova quello giusto.

Ci potrebbero volere anche delle ore. Un modo semplice per vedere i contenuti di messaggi multipli in un’acquisizione è tramite la Tabella Eventi della serie MSO/DPO, come mostrato in.

Gli oscilloscopi digitali Tektronix sono disponibili da Farnell


L'articolo è tratto da Debugging Serial Buses in Embedded System Designs di Gina Bonini Technical Marketing Manager @Tektronix.

Oscilloscopio digitale Tektronix MSO2024

L'oscilloscopio Tektronix (4 canali, display TFT color, 200Mhz di banda e campionamento a 1Gsps) è disponibile subito qui nello store.

 

 

 

Scrivi un commento all'articolo esprimendo la tua opinione sul tema, chiedendo eventuali spiegazioni e/o approfondimenti e contribuendo allo sviluppo dell'argomento proposto. Verranno accettati solo commenti a tema con l'argomento dell'articolo stesso. Commenti NON a tema dovranno essere necessariamente inseriti nel Forum creando un "nuovo argomento di discussione". Per commentare devi accedere al Blog
ritratto di alessandro piazza

di aiuto..

dopo quello in rs232 vedo quest'altro articolo interessantissimo. a quando uno sull'USB?
grazie

ritratto di Emanuele

USB debugging

Lo facciamo lo facciamo, continua a seguirci ;)

ritratto di ilDavide

Piccola inesattezza

I Remote Frame non hanno il Data Field, al contrario di come viene descritto.

ritratto di Emanuele

CanBus Remote Frame

Esatto, infatti come puoi notare nell'immagine incriminata abbiamo eliminato la didascalia in basso che riportava "Can Data/Remote Frame".

 

 

Login   
 Twitter Facebook LinkedIn Youtube Google RSS

Chi è online

Ci sono attualmente 7 utenti e 39 visitatori collegati.

Ultimi Commenti