CAN è largamente usata per automobili e camion ma ha trovato applicazione dappertutto. Ci sono molti livelli di “applicazione” disponibili per CAN come ISO 15765 (automobili), J1939 (camion) e CANopen (automazione in fabbrica) ma è molto semplice sviluppare i propri protocolli che si adattino e semplifichino le vostre necessità. I moderni transceivers CAN forniscono un ambiente fisico CAN stabile ed affidabile senza la necessità di costosi cavi coassiali. La gran parte del mistero su CAN è stata dissipato con lo scorrere degli anni.

Un controller CAN è una apparecchiatura sofisticata. Quasi tutte le ha caratteristiche del protocollo CAN descritte qui sotto vengono automaticamente attuate dal controller con quasi nessun intervento del processore host. Tutto ciò che serve è configurare il controller scrivendo nei suoi registri, scrivere i dati per il controller, ed esso poi narrato tutto il lavoro necessario per mettere il vostro messaggio nel bus. Il controller leggerà anche qualsiasi frame vedrà nel bus si e le conserverà in una piccola memoria FIFO. Esso notificherà al processore host che questi dati sono disponibili e che potrete leggere dal controller. Inoltre il controller contiene un meccanismo di filtro hardware che può essere programmato per ignorare quelle frames CAN che voi non vogliate passare al processore.

CARATTERISTICHE PRINCIPALI DI CAN

Per gli scopi di questo articolo, daremo per assunto che una rete CAN consiste del livello fisico (i voltaggi ed i cavi) e una frame consistente in una ID e un certo numero di byte di dati. CAN ha gli attributi generali seguenti:

• Una ID di 11 o 29 bit e da zero a otto bytes di Suggerimento: questi possono essere cambiati dinamicamente “al volo”.
• Rete Peer to Peer. Ogni nodo può vedere tutti messaggi da tutti gli altri nodi. Un nodo non può leggere i propri messaggi.
• I nodi possono essere aggiunti molto facilmente. Se ne può aggiungere uno alla rete con due cavi più la terra.
• I messaggi di più alta priorità vengono inviati per primi a secondo del valore dell’ID. Una ID di valore più basso ha la priorità più alta.
• Ritrasmissione automatica di frames difettose. Un nodo verrà ”buttato fuori” se causa troppi errori.
• Velocità da circa 10 Kbps a 1 Mbps. Suggerimento: tutti i nodi devono operare alla stessa frequenza.
• Una coppia ritorta differenziale fornisce un eccellente immunità dal rumore e una discreta protezione sugli errori del bus.
• Il sistema CAN funzionerà con la messa a terra a differenti livelli di Suggerimento: oppure senza nessuna messa a terra.

CONFIGURAZIONE DEL SISTEMA CAN

Una rete CAN consiste di almeno due nodi connessi tra loro con una paio di cavi ritorti come mostrato in figura 1.

Figura 1: una rete CAN generica.

La terra può essere inclusa con un cavo alla coppia ritorta o separata come parte dello chassis. Una torsione ogni pollice (o più) sarà sufficiente e l’integrità della terra non è importante per operazioni normali. Come in ogni sistema differenziale, il segnale importante è il livello di voltaggio tra la coppia di cavi e non il loro valore rispetto alla terra. CAN viene completamente descritta nella ISO 11898. La lunghezza massima della rete dipende dalla frequenza, il numero di nodi e la velocità di propagazione del cavo. È relativamente facile avere una rete di 20 nodi (o più) a 500 Kbps lunga 30 o 40 piedi (o più). Suggerimento: le cadute dovrebbero essere lunghe meno di tre piedi e spaziate irregolarmente per ridurre onde fisse. Tali problemi divengono più importanti a velocità di bus più alte. Poiché il cavo ritorto è una linea di trasmissione, è necessario mettere a ciascuna estremità del cavo principale delle resistenze di terminazione da 120 ohm. Non applicare alcuna resistenza ai nodi. Suggerimento: il valore delle resistenza totale misurata tra i due cavi ritorti sarà di 60 ohm. CAN è un sistema di comunicazione. Ogni nodo può inviare un messaggio usando una frame CAN in un bus che sia inattivo. Il messaggio sarà visto da ogni nodo. Un “messaggio” può essere considerato come una frame CAN fino a che non avrete bisogno di usare più di una frame per mandare un messaggio lungo. Suggerimento: dipende da ogni singolo nodo se deve reagire a una frame CAN oppure ignorarla completamente.

SCHEMA DI UN NODO

In figura 2 è riportato il diagramma dello schema tratto dalla scheda di valutazione Keil MCBSTM32E. IC1 è un transceiver CAN della Texas Instruments che attua la conversione tra i segnali CAN Tx e CANRx del controller CAN single-ended e il paio differenziale bidirezionale del bus CAN chiamati CANH e CANL (High e Low).

Figura 2: lo schema di collegamento del transceiver CAN.

Questo schema è completo. L’I/O CAN STM32 è TTL, CMOS e a 5 volt, allo stesso tempo rende estremamente facile il disegno dell’interfaccia. Il transceiver IC1 si connette al microprocessore IC2 STM32 che contiene un controller integrale CAN con due piedini: D (entrata Driver) e R (uscita Receiver). La nomenclatura corrispondente del STM32 è CAN Rx e CAN Tx. CAN Tx si connette a D. CANRx si connette a R. È veramente semplice. Alcuni processori hanno controller multipli CAN. Essi sono normalmente usati in routers, gateways o per creare più memoria di ricezione FIFO per CPU intenzionalmente rallentati (per ragioni EMI). Per un uso generale un nodo normalmente necessita soltanto di un controller. Se ne avesse almeno due potrebbe parlare a se stesso. RS di IC1 (slope control) viene usata per controllare i tempi di salita e discesa dei terminali di output per limitare EMI dal cavo ritorto. Da notare R4, una resistenza di terminazione da 120 ohm. Questa scheda di valutazione è stata concepita per essere usata con un’altra scheda come piccola rete di test. Se questa scheda viene usata come nodo, e non è ad una delle estremità, questa resistenza deve essere rimossa, ed usate resistenze esterne. P17 corrisponde a uno standard generalmente accettato per CAN su connettori DB9. Il piedino 7 di P17 è la linea bus CAN Hi e il piedino 6 è CAN Lo. Suggerimento: se CAN Hi e CAN Lo vendono invertiti, la rete non opererà correttamente. Potrebbe anche non funzionare affatto.

LIVELLO FISICO: I CAVI E I VOLTAGGI...

In CAN vengono usati tre livelli fisici: Hi-Speed, Fault Tolerant e Single Wire. Hi-Speed è il più comune ed è il solo che useremo in questo articolo. Fault Tolerant offre maggiore robustezza come implica il suo nome e viene usato più spesso nelle automobili europee. Single Wire viene usato dalla General Motors come rete a bassa velocità unita a una rete principale Hi-Speed. Hi-Speed nelle automobili a una velocità di 500 Kbps, nei camion di 250 Kbps. CANopen viaggia fino a 1 Mbps. Failt Tolerant generalmente va a 125 Kbps e GM Single Wire di solito va a 33,33 Kbps. Suggerimento: in un grosso sistema 1 Mbps è difficile da maneggiare, più semplice invece 500 Kbps. Cambiare dall’uno all’altro richiede solo la sostituzione del chip del transceiver e probabilmente il cambio della velocità. Questi tre livelli non possono essere connessi fisicamente l’uno all’altro poiché i livelli di voltaggio sono diversi. Per unire insieme diverse reti CAN bisogna usare un router o una gateway. Potrà essere usato tranquillamente qualsiasi controller CAN in ognuno dei tre livelli di CAN. Il livello fisico CAN Hi-Speed è costituito solamente da una coppia di cavi ritorti con una resistenza di terminazione da 120 ohm ad ogni estremità e cadute di cavi ritorti ad ogni nodo CAN. Si può collegare il proprio nodo direttamente al bus. Il voltaggio CAN Hi rispetto alla terra può cambiare tra 2,5 e 4 volts. CAN Lo invece tra 2,5 e 1 volt. Quindi la differenza tra i due è sia 0 volt (è il logico”1”) o 2 volt (è il logico”0”). Zero volt è conosciuto come lo stato “recessive”e 2 volt è lo stato “dominant”. Questi due segnali, CAN Hi e CAN Lo sono sfasati di 180 gradi come indicato in figura 3. Il bus è inattivo quando la differenza di voltaggio è zero.

Figura 3: tipici segnali su bus CAN.

Suggerimento: come determinare la frequenza di un segnale CAN: quanto segue è la migliore ed a volte l’unica maniera per determinarlo.

1. Connettere il puntale positivo di un oscilloscopio a CAN Hi e della terra a CAN Lo. La terra dell’oscilloscopio deve essere isolata dalla terra CAN. Si può andare dalla terra ad uno dei terminali CAN ma i segnali saranno più piccoli e rumorosi.
2. Mostrare una traccia. Probabilmente sarà necessario un’oscilloscopio con memoria per vedere solo una traccia e questo è dovuto alla natura non ripetitiva di CAN.
3. Prendere un impulso della più piccola ampiezza e misurare il suo periodo in secondi il più accuratamente possibile.
4. Invertire questo valore (dividere per 1) e si avrà la velocità di CAN in bits per secondo.

LA FRAME CAN

La frame CAN ha molti campi ma possiamo semplificarla in un modello di programmazione come mostrato in figura 4.

Figura 4: modello di frame CAN.

Questi campi sono quelli che il vostro software dovrà scrivere o leggere dai registri del controller CAN. I registri di configurazione CAN non sono inclusi.

• IDE: Identifier Extension:
  1 bit-specifica se il campo ID è di 11 o 29 bits
  Se IDE = 0 allora ID è di 11 bits Se IDE = 1 allora ID è di 29 bits

• DLC: Data Length Code:
  4 bits-specifica il numero di bytes di dati nella frame, da 0 fino a 8

• ID Identifier:
  11 o 29 bits come specificato da IDE. Questa parte della frame CAN stabilisce la priorità.

• Data Bytes: da 0 fino a 8
  Suggerimento: una frame CAN con soltanto un campo ID e senza data bytes è valido e utilizzabile.

• ID Identifier: 11 o 29 bits
  L’Identifier può essere usato per qualsiasi scopo. Spesso viene usato come indirizzo di un nodo o per identificare domande e risposte. CAN non specifica che cosa ID debba essere. 11 bit viene qualche volta chiamato Standard CAN e 29 bit viene chiamato Extended CAN.

• Se due o più messaggi CAN vendono inseriti nel bus nello stesso momento quello con la più alta priorità ID (il valore più basso) avrà accesso Gli altri verranno posposti e verranno riinviati il più presto possibile.

• Un ID di valore 0 ha la più ampia priorità e verrà sempre Una ID di 11 bit ha priorità rispetto qualsiasi ID di 29 bit.

• Si può cambiare la grandezza della ID in ogni momento e di avere una mescolanza di ID di 29 bit. Il controller potrà facilmente selezionarle.

• I messaggi tendono ad iniziare la trasmissione nello stesso momento. Per un nodo CAN non è permesso iniziare la trasmissione se un altro sta già trasmettendo. Questo causerà un errore di bus. I controller CAN non fanno questo errore.

• Suggerimento: notare che i controller CAN possono essere configurati in modo da passare solo certi messaggi al loro processore host. Scegliete con attenzione i vostri valori ID per avvantaggiarvi di questo fatto, se Questo può grandemente alleggerire il lavoro del processore di un nodo.
• Potete usare l’ID per dati, indirizzamento di nodi, comandi e sequenze di domande e I protocolli commerciali in pratica ne usano in qualsiasi modo. Potete scegliere qualsiasi metodo oppure crearne di vostri che meglio soddisfino le vostre necessità.

• Suggerimento: assicuratevi che due nodi non mandino mai gli stessi valori di ID nello stesso momento. Non è legale ma possibile farlo. Se due messaggi inviati nello stesso momento sono identici verranno visti come uno solo. Se i data bytes sono diversi ciò risulterà in un errore di bus e le frames verranno riinviate in continuazione. Ciò crea un disastro nel bus fino a che non avviene un arresto.

DATA BYTES

Si può selezionare da 0 a 8 data bytes usando il campo DLC da 4 bit.

• Si può avere qualsiasi numero di data bytes mescolati insieme sul bus Il controller potrà facilmente selezionarli.
• Suggerimento: se userete sempre soltanto un numero di data bytes il vostro software sarà molto più semplice da scrivere ed a mantenere.
• I data bytes possono contenere qualsiasi cosa. Non verranno priorizzati come accade con ID. CAN non specifica il contenuto dei dati.
• I protocolli commerciali come il J1939 li usano per i gatti così come bit di controllo per schemi di trasmissione multi-frame.

FRAMES REMOTE

Queste non sono molto usate ma vale la pena menzionarle. Una frame remote è un metodo veloce per ricevere una risposta da un altro nodo (o nodi). È una richiesta di dati. In nodo richiedente manda una frame CAN accorciata con solo un numero specifico di ID utente e il numero di data bytes che si aspetta di ricevere (il DLC è stabilito). Non viene inviato il campo dati. In nodo (o nodi) che risponde vede sia l’ID che il DLC, riconosce di avere l’informazione desiderata e rimanda indietro una frame CAN standard con lo stesso ID, DLC e con i propri data bytes allegati. Tutto questo (tranne che il nodo rispondente riconosce ID e DLC) è implementato nell’hardware del controller CAN. Qualsiasi altra cosa deve essere configurata dal software dell’utente.

• Campi di altri bit: in questo articolo verrà menzionato soltanto il bit ACK: è un campo di 1 bit nella frame CAN creato dal nodo trasmittente ma implementato da tutti gli altri nodi.
  Suggerimento: la principale ragione per cui la gente non riesce a far funzionare il proprio nodo CAN è che, per funzionare, sono necessari almeno due nodi. Quando un nodo invia un messaggio sul bus, aspetterà il riconoscimento del bit ACK da ogni altro nodo che ha visto messaggio e lo considera valido. Se è così, in nodo che trasmette terminerà il messaggio e andrà in stato inattivo oppure manda il prossimo messaggio. Se non è così, comincerà immediatamente a riinviare in messaggio per sempre fino a che non viene inserito un ACK o il controller viene resettato. Questo nodo che trasmette non andrà mai in modo bus-off. Da notare che uno strumento di test standard CAN di solito funzionerà come un secondo nodo.
  Suggerimento: questo rappresenta un’ottima opportunità per fornire una semplice situazione test. Se non riuscite a far funzionare la vostra rete provate questo:

• Connettete il vostro nodo CAN. Il transceiver deve essere connesso al controller CAN con una resistenza di terminazione.
• Non connettete altri nodi o strumenti di Solo un nodo che funzioni da solo con almeno una resistenza da 120 ohm.
• Connettete il puntale positivo di un oscilloscopio a CAN Hi e la terra a CAN La terra dell’oscilloscopio deve essere isolata dalla terra di CAN. Non c’è bisogno di un oscilloscopio ad alta velocità, sarà sufficiente uno qualsiasi. Potete anche connettere un oscilloscopio al piedino di output del controller CAN e a terra. Se commettete CAN Hi o CAN Lo e la terra, il vostro segnale sarà più piccolo.
• Configurate il controller CAN e scrivete IDE, ID, DLC e qualsiasi byte di dati nei registri
• Adesso sull’oscilloscopio verrà mostrata in continuazione qualsiasi frame CAN. Resettate il processore per ricominciare da capo.
  Suggerimento: potete misurare la frequenza di CAN con il metodo descritto nel suggerimento dato nel precedente paragrafo Livello fisico.

CARICAMENTO DEL BUS

parecchie reti CAN lavorano con un carico di bus tra il 15% e il 35% e ciò è in ascesa. Un carico di bus più alto può causare un ritardo di messaggi a bassa priorità, tali messaggi verranno comunque passati tempestivamente. È molto difficile raggiungere un carico di bus del 100% sebbene qualcuno possa arrivarci molto vicino. Le performance del sistema in totale nomina diminuiscono grandemente a questi atti carichi di bus. Suggerimento: è possibile ottenere carichi di bus molto alti in qualsiasi reti CAN per periodi di tempo molto corti. CAN non intervalla automaticamente i messaggi. È possibile avere una serie di messaggi back-to-back che eguaglino quasi un carico di bus del 100%. Dovete essere preparati a questo. Una soluzione è selezionare soltanto quei messaggi necessari a un nodo programmando i suoi filtri di eccitazione. Un’altra è che il vostro software determini l’intervallo dei messaggi. Questo problema è molto difficile da diagnosticare.

VELOCITÀ DEL BUS

In un sistema la velocità del bus è un atto di bilanciamento tra cose quali i ritardi di propagazione (dalla lunghezza del bus) e le emissioni EMI e il necessario throughput di dati. Fate funzionare la vostra rete il più velocemente possibile per avere operazioni stabili e con sufficiente throughput. Non fatela funzionare più velocemente del necessario ma lasciate un po’ di spazio per espansioni successive. Suggerimento: se la vostra rete non è stabile assicuratevi di avere due buone resistenze di terminazione a ogni capo della rete. Provate a rallentare la velocità CAN per vedere se questo aiuta. Le resistenze possono essere del normale tipo a carbone da 120 ohm ½ watt. Ciò non è critico.

ERRORI DEL BUS

Ricordiamo che è stato detto che tutti nodi (incluso il nodo che trasmette) controllano ogni frame CAN per trovare errori. Se viene trovato un errore ecco che cosa succede:

• Ognuno dei nodi segnalerà questo fatto portando il bus allo 0 logico (stato dominant) per almeno 6 bit CAN.
• Ciò viola la regola del Bit Stuffing (la stessa polarità non deve mai essere più grande di 5 bit) quindi ogni nodo vede questo fatto come un errore.
• Questa cosiddetta “Error Frame” segnala a tutti nodi che è accaduto un errore grave, se essi non se non sono già accorti.
• Il bus che trasmette abbandona la frame corrente e raggiungere 4 alla proprio registro da 8 bit (Contatore di errore di trasmissione).
• Se questo TEC è uguale a 0xFF, il nodo che trasmette va BUS OFF e si esclude dal (È zero al RESET).
• Se non lo è, prova a ritrasmettere il suo messaggio. Deve comunque passare attraverso il processo di priorità con gli altri messaggi.
• Anche tutti gli altri nodi smettono di leggere la frame corrente, e aggiungono 4 ad ogni registro (Contatore di errore di ricezione).
• Tutti nodi che hanno messaggi in coda per essere trasmessi trasmetteranno Tutti gli altri cominciano ad ascoltare il bus.
• Se tutto va bene, questa volta i messaggi verranno trasmessi e ricevuti senza errori. Ogni volta che una frame è trasmessa e/o ricevuta con successo, i corrispondenti registri TEC e REC vengono decrementati (di solito di solo 1).

SuperSuggerimento: Contatori di Errore? Questi sono due registri da 8 bit in ogni controller CAN e potete leggerli con il vostro software. Questa è una buona idea perché da alcune indicazioni della salute e della stabilità generale del bus. In una buona rete CAN, TEC e REC saranno uguali a 0. Se cominceranno ad avere valori più alti vuol dire che alla vostra rete è successo qualcosa. Il sospetto più ovvio è un cattivo hardware. Il problema di solito eco usato dai cavi o dal chip del transceiver.

Suggerimento: non dimenticate che se succede qualcosa all’integrità del vostro cavo ritorto, tipo la disconnessione di CAN Lo, potrebbe ancora funzionare ma con un’immunità al rumore molto ridotta (che è quello che i segnali differenziali fanno meglio). Se la vostra rete è in un ambiente molto rumoroso, potranno esserci molti più errori di bus transienti. A questo molto difficile fare il debug senza la conoscenza dei contenuti dei registri REC e TEC. Leggete REC e TEC con il vostro software e comunicatelo alle vostre routine di diagnostica. In generale TEC rappresenta gli errori di un dato nodo, REC indica gli errori di altri nodi. Bus Off: come già detto, se un nodo che trasmette si accorge di aver messo troppe frames cattive nel bus, si autodisconnetterà. Darà per assunto che c’è qualcosa di molto sbagliato in sé. Ritornare a connettersi al bus dipende da come configurate il controller. Potrà essere necessario fare un RESET del controller, o ricevere un certo numero di frames buone, o quello che configurate per rientrare nel bus.

DIFETTI DEL BUS

Questo è in qualche maniera diverso da un errore di bus. Normalmente pensiamo che un difetto del bus come qualcosa che è successo ai “cavi” o ai transistor di uscita del chip del transceiver. Non tutti i difetti del bus risulteranno come errori del bus. Un errore del bus può essere considerato come la reazione del controller CAN a un problema nel bus come un rumore, un nodo difettoso che include un difetto del bus. Cosa succede se uno dei due cavi ritorti si disconnette o va a massa? CAN ha un meccanismo automatico per questo problema. Non tutti i chip di transceiver si implementano tutti. Di solito potete mandare a massa CAN Lo (ISO 11898 dice che potete mandare a massa anche CAN Hi) o aprire una linea CAN. Perché queste funzionino la terra deve essere connessa. Non potete mandare in corto Hi e Lo insieme (un Fault Tolerant funzionerà) o aprirle tutte due. Potete tagliare la terra o avere un grande ground loop e CAN continuerà a funzionare. Tutto questo verrà considerato come un errore di bus come descritto prima. Un nodo deve almeno cercare di trasmettere una frame in una condizione di difetto di bus per scatenare un errore di bus. Un bus in modo inattivo non può scatenare un errore di bus. Quando il difetto del bus viene rimosso, in molti sistemi la rete ridiventerà attiva, se è stata così configurata CAN ha un’eccellente immunità al rumore a causa della coppia di cavi ritorti. Il rumore comune viene cancellato e il segnale CAN non è assolutamente influenzato (perché è fuori fase di 180°). La terra: strettamente parlando, la terra non è necessaria per l’operatività di CAN se la coppia di cavi ritorti è intatta. Ciò è presto dimostrato con semplici esperimenti. Un esperimento ha dimostrato che una piccola rete funzionava ancora bene con due nodi aventi una differenza da terra di 40 volt DC! Ciò nonostante nel disegnare il vostro sistema è una buona idea includere una buona terra. Alcuni difetti di bus hanno bisogno della terra per permettere al transceiver di compensarli.

Suggerimento: come si può creare un errore di bus per fare un test? Facile: basta che un nodo mandi un messaggio alla frequenza sbagliata. Quando questa frame cercare di entrare nel bus è certo che si creerà una condizione di errore di bus. Alcuni controller CAN possono inviare una frame one-shot.

Suggerimenti BONUS: ecco qui alcuni punti che non fanno parte delle specifiche CAN ma che potranno essere di aiuto nei vostri sistemi:

1. Trasmissione di data sets più grandi di 8 bytes: chiaramente, la trasmissione di data sets più grandi di 8 bytes avrà bisogno di frames multiple e ciò richiederà una certa Tali schemi possono divenire molto complicati poiché hanno a che fare con molti imprevisti di varia natura. È possibile il disegno di un protocollo più semplice se potete concentrarli su uno stretto insieme di richieste. Di schemi più comuni usano il primo byte di dati per contenere il numero dei bytes totali che seguono più un contatore che aiuti a determinare il significato di ogni byte di dati. Di solito l’ID identifica il nodo più se è il messaggio di richiesta o di risposta. Se volete usare un protocollo già esistente consultate ISO 15765. Questo è ciò che usano le automobili. Ciò include le diagnostiche OBDII che sono pubblica informazione. Questo buon esempio quando un messaggio può essere costituito da molte frames CAN.
2. Periodic, Request/Response e Command Frames Periodic: questa tecnica invia periodicamente una frame - di solito diverse volte ogni secondo. Questa frame conterrà dati che potranno essere usati da qualsiasi nodo, se si vuole, e viene identificata dalla propria ID. Alcuni esempi sono la velocità, la posizione, la pressione e eventi. Request/Response: un nodo invia una frame per richiedere una certa specifiche informazione. Qualsiasi altro nodo che abbia l’informazione richiesta la mette nel bus. L’ID identifica la frame Request o Response cambiando un bit della ID Request. Per esempio ID 0x248 è una frame Request e 0x648 è la sua Response. I bytes di dati della frame Request specificheranno quale informazione viene richiesta. La frame Response conterrà l’informazione richiesta oppure un messaggio di errore. Command: una frame che comandi che venga eseguito un certo evento. La ID di solito contiene l’indirizzo del nodo a cui si fa il comando e i bytes di dati il comando vero e proprio. Alcune volte viene restituita una frame Aknowledge.
   Suggerimento: a seconda delle necessità del vostro sistema potreste prendere in considerazione una mescolanza di questi tre tipi di traffico.
3. Time-Outs:
   Le reti CAN automobilistiche usano i time-outs e questo concetto è facilmente ed efficacemente trasferito ai sistemi di altri campi. Un time-out accade quando un nodo fallisce nel rispondere a una richiesta tempestivamente. I time-outs vengono trattati completamente dal software. Le specifiche CAN non forniscono questo meccanismo. I time-outs sono utili per rimediare a problemi della rete, quali severi errori di bus, difetti di bus catastrofici, nodi difettosi o connessioni intermittenti. Il risultato di solito un modo limp-home in cui un nodo cercherà di funzionare senza informazioni dal resto della rete. In alcuni casi, viene introdotto un modo limp-home punitivo il che forza l’utente ad effettuare delle riparazioni. Un buon esempio è se la trasmissione è difettosa e diventa impossibile un cambio accurato. In questo caso il modulo andrà in modo limp-home e la trasmissione potrebbe essere messa in una marcia come la seconda per permettere che il veicolo possa comunque essere guidato. Ciò può essere fatto per ragioni di sicurezza o per prevenire ulteriori danneggiamenti alla forza motrice. Heart-beats e Address Claiming: l’altro lato del time-out è un heart beat. Possono essere inviare i messaggi periodici per determinare che tutti nodi siano sul bus ed attivi. CANopen usa questi heart-beats. J1939 ha un meccanismo software in cui ogni nodo può dichiarare di essere sul bus ed essere riconosciuto dagli altri nodi. Questo si chiama “Address Claiming” e succede durante l’inizializzazione del sistema. Nessuno di questi meccanismi viene fornito dalle specifiche CAN ma dal vostro software.

SEQUENZA DI TRASMISSIONE DATI SUL BUS CAN

1. Qualsiasi nodo, vedendo che il bus è inattivo per un minimo tempo richiesto, può cominciare a inviare una frame CAN.
2. Tutti gli altri nodi cominciano a riceverla tranne quelli che stanno cominciando a trasmettere un messaggio (Tutti in cominciano nello stesso momento).
3. Se qualsiasi altro nodo incomincia a trasmettere, inizia il processo di priorità - il nodo con la più alta priorità continua e quelli con una minore priorità smettono di inviare, si tramutano immediatamente in un ricevitore e ricevono il messaggio a più alta priorità.
4. A questo punto, soltanto un nodo sta trasmettendo messaggio e nessun altro comincerà in questo momento.
5. Quando il nodo che trasmette ha completato la trasmissione del suo messaggio, aspetta un momentino in modo che il campo ACK venga portato a logica 0 da ogni altro nodo (o di solito tutti) per comunicare che la frame è stata ricevuta senza errori.
6. Se ciò accade, in nodo che trasmette assume che in messaggio abbia raggiunto la propria destinazione, invia i bits di end-of-frame si pone in modo ricezione oppure comincia ad inviare il prossimo messaggio, se ne ha I nodi che ricevono passano il messaggio ricevuto al loro processore host per essere processato a meno che il filtro di accettazione non prevenga questa azione.
7. A questo punto, qualsiasi nodo può iniziare ad inviare qualsiasi messaggio oppure il bus va in stato Andare al punto 1.
8. Se tutto questo non accade (il bit ACK non viene usato) allora il nodo che trasmette ritrasmettere il messaggio appena viene permesso. Se il bit ACK non viene mai usato, il nodo che trasmette continuerà a trasmettere il messaggio per sempre.

NOTE DI TRASMISSIONE

• Come fa un nodo a sapere quando deve trasmettere un messaggio? Semplice: create la frame CAN che volete inviare caricando IDE,ID,DLC e qualsiasi registro byte di dati nel controller CAN e poi, nella maggior parte dei controller, attivate un bit che faccia scattare l’invio della frame appena sia legalmente possibile. Dopo di ciò, sarà il controller ad occuparsi di inviare tutti i bits della frame. Potrete dare per scontato che il messaggio è stato inviato fino a che il controller non segnalerà diversamente al processore.
• Cosa succede se c’è un errore? Tutti i nodi, compreso il nodo che trasmette, tengono d’occhio il bus per qualsiasi Se viene rivelata una condizione di errore, il nodo può i nodi segnalano agli altri nodi che c’è un errore mantenendo il bus a 0 logico per almeno 6 cicli di bus. A questo punto, tutti nodi prendono i provvedimenti opportuni. Il messaggio che era in trasmissione (e che ora è abortito) verrà ritrasmesso ma solo per un certo numero di volte. Vedere Errori di Bus, i registri TEC e REC qualche paragrafo più indietro.
• Cosa succede se nessun nodo vuole o usa il messaggio? Niente. Il bit ACK dice solo che la frame CAN è stata trasmessa senza errori e almeno un nodo ha visto la frame senza errori. Ricordate che la frame che viene trasmessa non può darsi ACK da sola. CAN non fornisce alcun meccanismo di riconoscimento che una frame venga usata o meno dal ricevente di destinazione. Se ciò fosse necessario, dovrete fornirlo nel vostro software così come fanno diversi sistemi. Suggerimento: in un sistema periodico, se un nodo manca un messaggio, non importa molto perché in poco tempo ne arriverà un’altra copia.

SEQUENZA DI RICEZIONE DI DATI DAL BUS CAN

1. Tutti nodi tranne quelli che stanno al momento trasmettendo frames, sono in modo ascolto.
2. Una frame CAN viene inviata usando la procedura descritta più sopra: Sequenza di Trasmissione Dati sul bus
3. Questa frame viene ricevuta da tutti i nodi in Se è giudicato essere un messaggio CAN valido senza errori, viene usato il bit ACK. Nella terminologia CAN questo lo porta allo stato “dominant” come opposto allo stato recessive.
4. La frame viene inviata attraverso il meccanismo di filtro di accettazione del Se la frame è rigettata viene scartata. Se accettata, viene mandata alla memoria FIFO del controller. Se FIFO è piena, la frame più vecchia viene perduta.
5. Il processore host viene avvertito del fatto che una frame valida è pronta per essere eletta dalla memoria FIFO. Questo viene fatto sia con un interrupt o con un bit attivato in un registro del controller. Questa frame deve essere letta il più presto possibile.
6. Il processore host decise cosa fare di questo messaggio così come è stato stabilito dal vostro software.

NOTE DI RICEZIONE

Suggerimento: dovete decidere se usare il polling con gli interrupts per avvertire il processore host che è disponibile una frame. Polling è quando il processore host “polls” o testa in continuazione il bit menzionato al punto 5. Polling fa correre il rischio di perdere o “dropping” una frame ma talvolta è più facile da implementare e debuggare. Gli interrupts fanno sì che il processore salti a un gestore di interrupts in cui la frame viene eletta dal controller. Il metodo raccomandato è usare gli interrupts.

• Cosa succede se un messaggio è “dropped”? Ciò può causare alcuni problemi poiché CAN in se stesso non ha un meccanismo per riconoscere una frame Se volete che ciò avvenga dovete aggiungerlo al vostro software. Nel caso di messaggi Priodic di solito non importa molto perché un messaggio di rimpiazzo verrà inviato in poco tempo.
• Quanto velocemente devo leggere alla memoria FIFO per non perdere messaggi? Dipende dalla velocità di CAN, la grandezza della frame, e il carico del bus. È una buona idea leggere tali frames il più presto possibile perché una volta che una frame sia perduta non verrà recuperata automaticamente o riinviata dal nodo che trasmette. Viene persa per sempre a meno che nel vostro software non forniate un meccanismo affidabile per riinviarla.

CONTROLLER CAN E I LORO ERRATA SHEETS

Come detto precedentemente i controller CAN sono moduli molto sofisticati. Molte volte qualcuno può avere guai cercando di far funzionare qualcosa oppure ha un crash o un risultato inaspettato, e cerca disperatamente nel proprio codice l’errore che ne è causa. A volte la risposta è contenuta nell’errata sheet e non nel vostro software. Questo documento che elenca tutti i comportamenti che deviano da quelli pretesi nel datasheet dell’apparecchiatura. Alcuni controller CAN hanno dei bug e voi dovreste provare quali essi siano. Da notare che le statistiche del personale del supporto tecnico dimostrano che la maggior parte degli errori sono nel codice del software dell’utente quindi controllate tutto ciò con cautela. Dovete avere tutti i più recenti error sheets e leggerli. Potenzialmente potreste risparmiare un’enorme quantità di tempo. A volte i problemi più strani sono causati da questi difetti. E quindi, naturalmente, dovreste anche prepararvi per il giorno in cui questi difetti verranno risolti e mostrati in vero silicio sulle vostre schede. La maggior parte dei problemi saranno nei controller e non nei più semplici transceivers.

BIT DI RIEMPIMENTO

Il protocollo CAN stabilisce che quando ci sono 5 bit della stessa polarità consecutivi, verrà inserito un bit della polarità opposta per mantenere l’accuratezza del contatore. Questi bits rendono la frame CAN più lunga e sono molto comuni. Questi bit vengono inseriti e rimossi automaticamente dal controller CAN e sono visibili soltanto quando viene collegato un controller al bus. Suggerimento: quando vengono aggiunti (o no) bits alla frame CAN mentre vengono inviati veri messaggi nel bus, la mutevole lunghezza della frame apparirà sul bus come un jitter. Naturalmente non c’è nessun jitter: è solo CAN che funziona in questo modo. È soltanto qualcosa di cui essere consapevoli.

Ti potrebbe interessare anche:

Le innovazioni di Conrad alla Fiera electronica di Monaco

XMEGA clock system

Comunicazione solida ed economica

Articoli Correlati

Profibus

Reti CAN: strumenti di progettazione e diagnosi