Generatore di traffico periodico

Il generatore di traffico periodico è stato realizzato utilizzando il microcontrollore T89C51CC01 ed il nodo risultante è stato collegato al bus CAN come mostrato in Figura 3.5 dove viene messo in evidenza anche il collegamento seriale fra il nodo CAN ed il PC:

Generatore di traffico periodico Bus CAN Collegamento seriale

Figura 3.5: Struttura e collegamento del generatore di traffico periodico.

Il collegamento seriale avviene, da parte del nodo CAN, attraverso la UART del microcontrollore T89C51CC01 mentre il PC utilizza l’interfaccia seriale RS232. Lo scambio di dati avviene in modo asincrono senza handshake e si verifica in due momenti diversi:

o In fase di programmazione del microcontrollore presente nel nodo CAN. o Durante il passaggio dei parametri del traffico periodico in fase di

esecuzione del programma.

Nel primo caso, il codice contenente le istruzioni da eseguire in formato Hex, viene trasferito dal PC al microcontrollore (e quindi memorizzato nella EEPROM interna) con un bit-rate di 38.4 kbps.

Il passaggio dei parametri forniti dal PC al programma in esecuzione sul nodo CAN avviene invece con un bit-rate di 115.2 kbps in trame di 8 bit con l’aggiunta di 2 bit di stop e senza parità. La velocità di trasmissione in questo caso

non influisce sulle prestazioni del generatore di traffico in quanto il passaggio dei parametri avviene una sola volta all’inizio della fase di esecuzione del programma per impostare le caratteristiche del traffico periodico e quindi non è soggetto a vincoli temporali.

L’applicativo che viene fatto girare sul microcontollore T89C51CC01, chiamato Periodic Traffic Injector, contiene le istruzioni necessarie per la generazione del modello di traffico periodico del sistema. Per analizzare le caratteristiche di tale programma e giustificare la scelta delle soluzioni adottate, faremo riferimento ai listati scritti in linguaggio C2 _{attraverso l’editor}

dell’ambiente di sviluppo “µVision2”.

Il programma principale main( ) permette di inizializzare le periferiche utilizzate attraverso la chiamata di tre funzioni: init_can( ), init_timer1( ), init_uart( ).

La prima di esse imposta il bit-rate del bus CAN assegnando agli appositi SFR un ben preciso contenuto numerico [1]: in questo modo è possibile scegliere la velocità di trasferimento dei dati a cui lavorare. Inoltre init_can( ) configura i canali (message object) 0 e 1 per trasmettere un messaggio con identificatore pari ad 1 e contenuto rappresentato da un solo byte di valore 55 h. Entrambi i canali sono abilitati a generare un’interruzione dopo aver trasmesso un messaggio ma non vengono ancora configurati in modalità di trasmissione. Viene quindi creato un buffer circolare costituito da due locazioni per gestire l’invio dei messaggi sul bus. L’utilità di tale buffer verrà chiarita in seguito.

La funzione init_uart( ) consente di impostare il bit-rate della UART del microcontrollore utilizzando l’overflow del Timer2. In questo caso è possibile ottenere un valore di 111,111 kbps che approssima (come già detto) la velocità di trasmissione massima della SR232 del PC (115.5 kbps).

La funzione init_timer1( ) permette invece di impostare il funzionamento del Timer1 in modalità 8-bit-autoreload. Il contenuto del timer viene controllato attraverso due SFR a 8 bit chiamati TL1 e TH1; nella modalità 8-bit-autoreload, il valore di TL1 viene incrementato ogni 12 cicli di clock (o 6 se il timer lavora a frequenza di funzionamento doppia); al raggiungimento dell’overflow, viene

generata una richiesta di interruzione e quindi trasferito il contenuto di TH1 in TL1. In Figura 3.6 è mostrata la struttura del Timer1 in modalità 8-bit-autoreload; l’ingresso al registro TL1 rappresenta il segnale di clock. Precaricando il contenuto di ambedue i registri a 0 e lavorando a 12 cicli di clock per istruzione, è possibile ottenere una richiesta di interruzione ogni Tint = 256*12*fosc. Se

l’oscillatore esterno lavora a 16 MHz si ottiene Tint = 192 µs.

Figura 3.6: Funzionamento del Timer1 in modalità 8-bit-autoreload.

Senza scendere troppo nel dettaglio, dopo aver inizializzato le periferiche, il programma che gira sul microcontrollore invia la richiesta di inserire i parametri caratteristici del traffico periodico attraverso la UART. Grazie all’applicazione Hyper Terminal è possibile visualizzare sul monitor i dati inviati al PC attraverso un cavo seriale connesso all’intrfaccia RS232. L’utente è quindi invitato a inserire due valori numerici: b.l. espresso attraverso 2 cifre esadecimali (8 bit) e b.p. su 4 cifre esadecimali (16 bit). I simboli digitati sulla tastiera vengono quindi inviati, grazie al collegamento seriale, alla UART del microcontrollore e letti attraverso il registro SBUF. Il contenuto di SBUF, opportunamente convertito, viene utilizzato per trasferire il valore di b.l. nella variabile a 8 bit BurstLength e quello di b.p. in BurstPeriod a 16 bit. Il programma main( ), attraverso la routine di interrupt orologio, permette di contare un numero di interruzioni generate dal Timer1 pari a BurstPeriod e, dopo tale intervallo di tempo, abilita alla trasmissione i canali configurati da init_can( ) secondo le seguenti modalità:

o Se BurstPeriod >= 2 vengono abilitati entrambi i canali.

Nel caso in cui il valore della variabile BurstPeriod sia maggiore di 2, non appena la trasmissione del messaggio relativo ad un canale abilitato termina generando una richiesta di interruzione, viene attivata la routine di interrupt it_can che provvede ad abilitare nuovamente in trasmissione il canale suddetto. Tale routine viene attivata un numero di volte, pari a b.l.-2, in modo da garantire l’invio sul bus di b.l. messaggi dello stesso tipo.

A questo punto è possibile analizzare la struttura del burst di messaggi periodici trasmessi dal generatore di traffico per modellare (come descritto nel capitolo precedente) l’insieme delle trasmissioni periodiche di una rete CAN. Considerando la successione dei comandi che permettono di abilitare in trasmissione i due canali predisposti da init_can( ), è possibile esprimere i parametri caratteristici del modello periodico nel seguente modo:

o B.P. = b.p. * Tint

La trasmissione di messaggi sul bus viene infatti abilitata quando la routine orologio ha contato un numero di interruzioni provenienti dal Timer1 pari a b.p. ; pochè tali interruzioni avvengono ogni Tint, l’intervallo

di tempo scandito da orologio è proprio pari a b.p. * Tint .

o B.L. = b.l. * 58 * Tbit

I due canali predisposti alla trasmissione, vengono infatti abilitati, ogni B.P., un numero tale di volte da garantire l’invio di b.l. messaggi identici sul bus. Ciascuno di questi messaggi, data la struttura dei corrispondenti message object (ID pari a 1, DLC pari a 1, Data pari a 55 h) è lungo complessivamente 58 bit (47 di servizio, 8 di dati e 3 di stuffing) e quindi impiega un periodo di tempo di 58*Tbit per essere trasmesso.

La struttura di tale modello di traffico, costituita dalla successione di b.l. messaggi identici ogni periodo B.P., è mostrata in Figura 3.7:

B.P. … b.l. 2 1 … b.l. 2 1 B.L.

Figura 3.7: Struttura reale del modello di traffico periodico.

Per garantire la consistenza del messaggio periodico inviato, deve necessariamente risultare B.P. > B.L. da cui si ricava il seguente vincolo sui valori (interi) di b.l. e b.p.:

b.p. > b.l.*302084*Tbit

avendo assunto (come sarà fatto in seguito) fosc= 16 MHz.

E’ possibile inoltre esprimere il valore di W.L.periodico in funzione di b.l. e b.p.:

% 100 * . . * 302084 * . . . . _      = p b T l b L W periodico bit

Prima di concludere l’analisi del generatore di traffico periodico, è possibile fare alcune considerazioni per comprendere l’utilità del buffer circolare (costituito dai message object 0 e 1) nella gestione dei messaggi da inviare sul bus. A tal proposito assumiamo che b.l. abbia un valore maggiore di due ed analizziamo le modalità con cui la routine di interrupt it_can gestisce l’attivazione in trasmissione dei due canali del buffer. Poiché b.l. > 2, entrambi i canali vengono attivati durante l’esecuzione del programma principale main( ). Inoltre, poiché il T89C51CC01 assegna priorità maggiore ai canali con indice più piccolo, il messaggio contenuto nel message object 0 inizia la contesa per la trasmissione sul bus CAN (secondo le regole analizzate nel capitolo 1) mentre l’altro rimane semplicemente accodato. Non appena è terminata la trasmissione di tale

messaggio, il canale 1 inizia immediatamente la contesa per l’accesso al bus mentre l’interruzione generata dal message object 0 (attraverso il bit TXOK del suo registro CANSTCH) avvia l’esecuzione della routine di interrupt it_can. Tale routine attiva nuovamente il canale 0 in trasmissione determinando l’accodamento sul bus del messaggio corrispondente. In questo modo l’invio di un messaggio avviene (quasi) immediatamente alla fine della trasmissione del precedente. Il generatore di traffico periodico inizia subito la contesa per l’accesso al bus e non consente quindi ai nodi vocali con priorità minore di effettuare la loro trasmissione.

Se utilizziamo invece un solo message object per gestire l’invio del traffico periodico sul bus CAN, il tempo che intercorre fra la fine della trasmissione di un messaggio e l’inizio del successivo assume un valore decisamente più elevato. Tale canale viene infatti automaticamente disabilitato non appena finisce di trasmettere il proprio messaggio ed invia la richiesta di interruzione settando il bit TXOK. La trasmissione successiva può quindi avvenire soltanto dopo che il message object è stato nuovamente attivato dalla routine it_can. Poiché l’esecuzione di tale routine non inizia immediatamente alla richiesta di interruzione ed inoltre la CPU del T89C51CC01 impiega 375 ns (con fosc = 16 MHz e lavorando a 6 cicli di clock per istruzione) per eseguire

un’istruzione del codice, l’attivazione del canale in trasmissione può avvenire soltanto dopo un certo intrvallo di tempo che chiameremo Taccodamento. E’quindi

possibile che i messaggi vocali a priorità minore vadano ad occupare il bus durante tale intervallo causando l’accodamento di quelli periodici.

In questo modo viene violato il vincolo di progetto che impone ai dati vocali di non alterare il traffico di controllo già presente nella rete.