Il microcontrollore di casa Fujitsu MB90340E, contiene anche un’interfaccia CAN bus. Vediamo in questo articolo quali sono le sue caratteristiche.
Il Controller Area Network (CAN) è un protocollo utilizzato per la maggiore nelle applicazioni di tipo automotive. L’implementazione dello standard da parte di Fujitsu risulta conforme alle specifiche 2.0 parte A e B. La figura 1 mostra il diagramma a blocchi di questo CAN Controller.
Figura 1: diagramma a blocchi del controllore CAN.
Dalla figura possiamo notare la varietà dei registri che il componente propone al programmatore. I nodi che rispondono alle specifiche 2.0A e 2.0B comunicano tra loro solo se non utilizzano la modalità estesa, ovvero Extended Frame. Qui di seguito vediamo alcune caratteristiche di questo componente:
➤ Il componente prevede la ritrasmissione automatica, e praticamente trasparente, in caso di errori.
➤ Supporta, in trasmissione e in ricezione, frame estesi e standard.
➤ Supporta i messaggi multipli.
➤ Permette la trasmissione automatica come risposta ad un remote frame
➤ Consente di configurare in maniera flessibile il meccanismo di filtering e di masking. I filtri e le maschere permesse dal protocollo, e di conseguenza dal componente, consentono di determinare l’identificatore e il data frame per elaborare successivamente le informazioni associate. Infatti, nel CAN bus ogni messaggio è individuato dal data frame e da un identificatore.
➤ Il componente è in grado di gestire fino a 16 message buffers nelle due modalità di funzionamento, ricezione e trasmissione.
➤ Il bit rate è programmabile da un valore di 10 kbps fino a 1 Mbps. In caso del rate massimo occorre prevedere, al minimo, un clock di 8 MHz.
I registri del componente sono raggruppati in tre famiglie: gli overall control register, i registri di controllo per i message buffer e i registri di gestione dei message buffer. Il gruppo Overall control register comprende il Control Status Register (CSR), Last Event Indicator Register (LEIR), il Receive and transmit error counter (RTEC) e, per finire, il bit timing register (BTR). Sono 14 poi i registri di controllo utilizzati per controllare i message buffer. Accanto ai registri classici utilizzati per la ricezione e la trasmissione, sono presenti:
➤ IDE register, predispone il formato del frame utilizzato dal message buffer associato durante la trasmissione o ricezione.
➤ Transmission Request register, è utilizzato per iniziare la sequenza di trasmissione e visualizzare lo stato associato del message buffer.
➤ Remote Trasmission Request register, grazie a questo registro è possibile selezionare la trasmissione di un frame di un message buffer associato o come data frame o remote.
➤ Remote frame receiving wait register, attraverso questo registro è possibile determinare la tipologia della trasmissione richiesta, o una trasmissione immediata (scrivendo il valore “0”) o una trasmissione di tipo differita.
➤ Transmission Cancel Register, l’uso di questo registro permette di eliminare una richiesta di trasmissione pendente al message buffer associato.
➤ Transmission Control Register, il registro conserva memoria della trasmissione effettuata. Al termine della trasmissione del message buffer associato il bit relativo viene messo a 1.
➤ Transmission Interrupt Enable Register, attraverso l’uso di questo registro è possibile abilitare o no gli interrupt sulla trasmissione. La generazione di un interrupt si verifica solo al termine della trasmissione (quando il bit associato del message buffer del control register risulta essere a 1).
➤ Reception Complete Register, al termine della memorizzazione dei dati ricevuti dal message buffer, il bit RCx, associato al message buffer stesso, è posto a 1.
➤ Reception Interrupt Enable Register, anche in questo caso, come per la trasmissione, è possibile associare ad ogni data buffer ricevuto un interrupt. In questo caso occorre abilitare l’interrupt.
➤ Remote Request Receiving Register, in caso di ricezione di un remote frame di un message buffer, il componente segnala l’evento attraverso un bit di questo registro.
➤ Receive Overrun REgister, l’uso di questo registro permette di rilevare le segnalazioni di overrun in ricezione.
➤ Acceptance Mask Register, è un insieme di registri utilizzati per fare, in maniera trasparente rispetto all’applicazione, la comparazione tra gli identifier dei messaggi ricevuti con quelli del message buffer associato.
➤ IDE register, per mezzo di questo registro è possibile definire il formato del frame utilizzato dal message buffer sia in ricezione che in trasmissione.
➤ Message Buffer Valid Register , Il registro è utilizzato per definire il valore di validità del message buffer o anche per visualizzarne lo stato.
Esistono poi un insieme di registri utilizzati per gestire i message buffer. Ogni message buffer risulta costituito da una tripletta di registri: il registro ID, DLC e il data register.
Can bus
Il CAN bus è estremamente flessibile; è possibile, per esempio, aggiungere o rimuovere periferiche e modificare la topologia del bus. Questa particolarità è permessa grazie alla possibilità di interagire con le periferiche (nodi) senza ricorrere agli indirizzi. In questo modo le informazioni sono scambiate utilizzando un sistema denominato message oriented. Il CAN bus è un protocollo multi-master con la possibilità di associare una priorità al messaggio. I messaggi trasmessi da ogni periferica (nodo) possiedono una priorità legata alla struttura del messaggio. L’identifier o ID (identificatore) è la parte del messaggio a cui è legata la priorità. Il ruolo della priorità del nodo è assume un aspetto rilevante qualora il nodo stesso acquisisca il dominio del bus. Infatti, il nodo quando acquisisce il dominio del bus trasmette come master. Può succedere che più nodi possono tentare di trasmettere un messaggio, in questo caso la priorità del messaggio regolerà la politica di trasmissione: il messaggio che ha la priorità più alta verrà inviato sul bus. Il protocollo CAN bus è costituito da due parti che, in linea di massima, sono interoperabili a meno di utilizzare le sue estensioni. Il CAN è, in sostanza, un bus seriale di tipo multicast. Da un punto di vista logico è possibile suddividere il CAN bus in tre strati. Ogni strato sovrintende ad un particolare compito definito in sede di specifica e la figura 2 mostra la stratificazione proposta. Lo strato object layer è quella parte del bus più vicino con l’applicazione utente.
Figura 2: stratificazione del CAN bus.
In questo strato trovano posto anche le varie operazioni che deve fare l’utente per configurare correttamente il componente. Il programmatore deve, per esempio, impostare le maschere e i filtri per gestire correttamente i vari frame. Il transfer layer sovrintende alle operazioni di flusso e di indirizzamento. In questo strato, il microcodice Fujitsu si deve occupare di diverse incombenze; per esempio, gestire gli errori del protocollo, deve occuparsi della validazione del messaggio, dell’arbitraggio, delle temporizzazioni. In definitiva, il componente si occupa di assicurare il regolare invio/ricezione dei messaggi con tutte le implicazioni hardware e software richieste. Il physical layer è lo strato più vicino all’hardware del componente. In questo strato sono definite le risorse fisiche che il componente utilizza per trasmettere il frame. Tipicamente come mezzo fisico si utilizza un doppino elettrico o, a volte, la fibra ottica.
Trasmissione di un data frame
Ma come si trasmette un Data Frame? La struttura di un Data Frame è evidenziata in figura 3.
Figura 3: struttura di un data frame.
Dalla figura vediamo che questo è composto da sette campi: Start Frame, Arbitration Field, Control Field, Data Field, CRC field, ACK field, End Of Frame. In prima analisi occorre configurare il bit timing, il formato del frame, l’identificatore (ID), e la configurazione dei filtri. Successivamente si passa a definire il data length code attraverso il registro DLC (Data Length Code). Questo registro è utilizzato per definire la lunghezza dei dati; la lunghezza massima è di 8 byte. La profondità di questo registro è di 4 bit (da DLC3 a DLC0). Per i data frame il bit RTR deve essere messo a 1, altrimenti, in caso contrario, deve assumere un valore 0. Se vogliamo trasmettere un Data Frame abbiamo la necessità di predisporre il Data Field; questo è il contatore di byte trasmessi dal data register. È possibile definire per i Frame di tipo Data delle condizioni di funzionamento. Vale a dire, a fronte di un evento legato a un Remote Frame possiamo associare l’invio di un Data Frame, ricorrendo al registro RFWT. Oppure possiamo decidere di attivare immediatamente la trasmissione, configurando opportunamente il registro deputato alla trasmissione, registro TREQR. Il remote frame è simile a un data frame, con una differenza importante: non contiene nessun dato, ma solo un identificatore (ID). La sua priorità è poi più bassa di un data frame. La trasmissione di un message buffer ha luogo quando viene abilitato il bit TREQ del registro TREQR (Transmission Request Register). La figura 4 mostra il flowchart della trasmissione di un message buffer.
Figura 4: flowchart della trasmissione di un message buffer.
Come vediamo dalla figura, al termine della trasmissione il bit TCx del registro Transmission Complete Register (TCR) assume il valore 1. E’ possibile associare al termine della trasmissione un interrupt, in questo caso è necessario intervenire sul bit TIEx (Transmission Interrupt Enable) del registro TIER. Una richiesta di trasmissione può essere interrotta ricorrendo o al registro TCANR o intervenendo sul messaggio memorizzato in memoria.
Frame
I messaggi che sono trasmessi con il protocollo CAN sono strutturati in maniera univoca. Ogni messaggio è chiamato Frame. In particolare, il dispositivo supporta quattro tipi di frame in accordo con lo standard. Il Data Frame è utilizzato per trasmettere dati. Ogni Data Frame ha un suo identificatore e per questa ragione è determinato in maniera univoca. L’utente, attraverso i filtri, ha la possibilità di identificare il frame. Non è possibile indirizzare un singolo nodo perché il CAN bus, come abbiamo detto, è di tipo multicast, ecco perché sono necessari i vari filtri e maschere. Il Remote Frame è un particolare Data Frame senza dati. Il componente permette di discriminare un Remote Frame da un Data Frame per mezzo di un registro, come abbiamo visto in precedenza. L’Error Frame è un Frame utilizzato in caso di errori in trasmissione ed è inviato dal nodo che ha rilevato un errore. Per ultimo abbiamo l’overload Frame. Questo frame è inviato solo, quando un nodo non è in grado di gestire un messaggio ricevuto. In questo caso, chiede al sistema di ritardare la ricezione di altri frame fino a quando non è in grado di riprendere la gestione corretta.
