Capitolo 5
Firmware
5.1 IntroduzioneLa parte firmware è stata progettata prendendo come riferimento un lavoro presentato nel 2002 e realizzato presso il laboratorio di sistemi elettronici del dipartimento dell’informazione dell’ Università di Pisa, riguardante un prototipo X9 Piaggio equipaggiato con una rete CAN [1] Sullo scooter è stata montata una rete costituita da quattro nodi ognuno dei quali controlla una zona di competenza, in modo tale da gestire tutte le funzionalità tipiche dello scooter originale.
Il nuovo nodo è invece dedicato al controllo della sospensione posteriore.
Per la preparazione del firmware è stato utilizzato l’ambiente Keil, che tra le altre contiene anche le librerie del microcontrollore scelto per l’applicazione [14].
Questo ambiente consente anche di eseguire un debug molto dettagliato grazie alla possibilità di inserire simulazioni di segnali elettrici costruite mediante funzioni appositamente realizzate.
Il programma è stato scritto in C, e nel capitolo sono anche riportate alcune delle funzioni più significative.
5.2 Il protocollo CAN
Questo paragrafo non vuole essere una guida esaustiva del protocollo CAN (Controller Area Network), ma solo una breve panoramica su quelli che sono i vantaggi dell’utilizzo di una rete basata su tale protocollo che sono stati alla base della scelta effettuata.
Il mercato delle due ruote ha presentato negli ultimi anni motoveicoli che associano alle funzionalità classiche sistemi elettronici sofisticati come antifurti, immobilizzatori, centraline per la gestione del motore, ecc.
Questa tendenza è ancora più marcata per gli autoveicoli.
L’impianto elettrico ha quindi subito un aumento del volume occupato e della complessità di cablaggio che ne limitano le possibilità di sviluppo ulteriore.
A soluzione di questo problema sono stati sviluppati a partire dagli anni ottanta sistemi di comunicazione multiplexati basati su unità decentralizzate gestite da microcontrollori, dislocate in diversi punti del motoveicolo.
Le varie unità comunicano tra di loro mediante un bus seriale. Oggi lo standard è costituito dal protocollo CAN.
Questo protocollo nacque agli inizi degli anni ottanta con particolari applicazioni nel settore automobilistico. Fu standardizzato a livello internazionale nel 1993 (ISO 11898) e trova ormai le più svariate applicazioni, dall’industria tessile al settore biomedico. Questo avviene anche per la possibilità di rivedere e correggere, mediante ritrasmissione,
un errore nella trasmissione di un messaggio tramite alcune modalità previste nel protocollo.
5.2.1 Lo standard 2.0 A
Lo standard prevede all’interno del sistema dotato di rete CAN (in tal caso un motoveicolo) il passaggio di un unico cavo bifilare intrecciato che costituisce il bus, con alle estremità la presenza di due resistenze da
120 Ω (utili per eliminare la riflessione delle onde) e dei cavi di
alimentazione.
La lunghezza massima del bus dipende dalla velocità di trasmissione usata. È richiesto che il fronte di salita di un bit possa viaggiare lungo tutto il bus e poi tornare indietro prima che il bit sia campionato.
In tabella 5.1 è riportata la lunghezza del bus in funzione della velocità di trasmissione.
Lunghezza del bus [m] Max bit rate [b/s]
40 1 Mb/s
100 500 Kb/s
200 250 Kb/s
500 125 Kb/s
6000 10 Kb/s
Le unità da gestire vengono collegate poi, con cavi di lunghezza sensibilmente inferiore a quella utilizzata nei cablaggi tradizionali, ai nodi di competenza.
Una rete CAN riesce a trasmettere dati con un bit rate fino a 1 Mb/s , caratteristica che rende queste reti particolarmente indicate per applicazioni real time. Ciò è anche dovuto all’assegnazione delle priorità ed al meccanismo di arbitraggio.
Altra caratteristica che è stata determinante per il successo di questo protocollo è la possibilità di aggiornare la rete, aggiungendo un nodo o qualche funzionalità semplicemente modificando il firmware.
Questa modalità di aggiornamento risulta essere molto importante per un eventuale sviluppo del sistema o per la correzione di bug che dovessero essere riscontrati in futuro.
La trasmissione dei dati avviene sotto forma di messaggi, ognuno dei quali non contiene né l’indirizzo del nodo trasmittente, né quello del nodo ricevente.
Ad ogni messaggio è invece associato un identificatore a 11 bits (nel caso della versione standard CAN 2.0A, ma esistono anche identificatori a 29 bits per il protocollo Extended CAN versione 2.0B) che lo caratterizza per l’intera rete.
Ogni nodo presente sulla rete riceve tutti i messaggi, ma utilizza solo quelli di sua competenza.
5.2.2 Tecnica di arbitraggio
L’identificatore del messaggio indica anche la priorità dello stesso, ovvero quale messaggio debba essere trasmesso prima nel caso in cui diversi nodi tentino di inviare il proprio. La priorità massima è assegnata all’identificatore numerico più basso.
La tecnica di arbitraggio dei messaggi è non distruttiva, in quanto i conflitti vengono risolti con l’invio del messaggio a priorità più alta. La tecnica non distruttiva di arbitraggio del bus è basata sul metodo CSMA/CD (Carrier Sense Multiple Access with Collision Detect) e garantisce l’occupazione ottimale del bus, con sensibile riduzione dei tempi di latenza delle informazioni.
La codifica prevede uno stato “dominante” e uno stato “recessivo”, corrispondenti rispettivamente allo 0 e all’1 logico.
Quando si verifica un conflitto sul bus, esso viene risolto in accordo all’AND cablato e lo stato dominante soprascrive lo stato recessivo. In pratica tutti i nodi iniziano a trasmettere i propri messaggi, e quando durante la stessa trasmissione di un bit recessivo incontrano un bit dominante abbandonano la competizione, con il risultato di avere la trasmissione del messaggio a priorità maggiore.
In figura 5.1 è riportato un esempio di competizione tra tre nodi che tentano di trasmettere allo stesso istante e il segnale che è possibile leggere sul bus.
Il nodo 1 perde la competizione al bit 7, mentre il nodo 3 perde al bit 3. I nodi perdenti diventano subito ricevitori e non tenteranno una ritrasmissione prima che il bus sia diventato libero.
Figura 5.1: esempio di competizione nella trasmissione di un messaggio da parte di tre nodi e relativo
messaggio trasmesso sul bus
5.3 Descrizione del firmware
Il nodo realizzato è dedicato al controllo della sospensione posteriore dello scooter.
È previsto un task ciclico ogni 10 ms durante il quale il nodo legge gli ingressi, in particolare l’accelerazione anteriore e la variabile assetto
impostata dal pilota (sport o comfort), calcola l’accelerazione media su cinque valori, calcola i parametri necessari alle funzioni di controllo e aggiorna lo stato della sospensione.
L’ingresso è rappresentato dall’ accelerazione lungo l’asse z, acquisita mediante un accelerometro e inviata al convertitore ADC presente sul microcontrollore. I dati così ottenuti vengono sfruttati per calcolare la media delle accelerazioni. L’accelerazione è una variabile a otto bits, quindi la scelta sul modulo dell’accelerazione viene effettuata sui due bits più significativi.
In tal modo si ottiene una stima della tipologia di strada che lo scooter sta percorrendo.
In base all’accelerazione media viene definita l’accelerazione utile, utilizzata poi nella funzione che aggiorna lo stato della sospensione.
Stabilito il nuovo stato che la sospensione deve assumere, viene fatto aumentare o diminuire il duty cicle di un’onda PWM realizzata utilizzando un modulo PCA (Programmable Counter Array) presente sul microcontrollore che prevede tale funzione.
Per tenere conto del tempo che la tipologia di ammortizzatore considerato impiega per adeguare lo smorzamento effettivo a quello richiesto (40 ms al massimo) è stata creata una variabile che si resetta nel momento in cui avviene un cambio di stato della sospensione , e che non consente una nuova regolazione prima che l’ammortizzatore abbia raggiunto il nuovo stato. A questo punto la stessa variabile viene posta a “1” e una nuova regolazione può avvenire.
È anche stata prevista la possibilità da parte del pilota di impostare un assetto sportivo.
La regolazione avviene come descritto in precedenza ma le soglie sono leggermente spostate per rendere le sospensioni un po’ più smorzanti, con conseguente maggior trasmissione di accelerazione al pilota.
5.4 Principali funzioni realizzate
In questo paragrafo vengono riportate solo le funzioni più significative realizzate (o parti di esse) per eseguire l’algoritmo di controllo della sospensione.
In particolare viene riportato solo il corpo delle funzioni, omettendo tutta la parte di dichiarazione delle stesse, ad eccezione di alcune dichiarazioni fondamentali per la comprensione del listato.
5.4.1 aggiorna_stato_sospensione
È la funzione che si occupa di discriminare il nuovo stato della sospensione in base all’accelerazione utile determinata dalla funzione “definisco” riportata al paragrafo 5.4.4.
La variabile “acc_sosp_ant_utile” è di tipo type_acc_sosp_ant_utile, un tipo enumerato dichiarato come segue:
typedef enum { bassa = 0, medio_bassa = 1, medio_alta = 2, alta = 3 } type_acc_sosp_ant_utile; void aggiorna_stato_sospensione() { switch(acc_sosp_ant_utile) { case 0: nuovo_stato_sosp = 3; break; case 1: nuovo_stato_sosp = 2; break; case 2: nuovo_stato_sosp = 1; break; case 3: nuovo_stato_sosp = 0; break; default: ; } }
Sono stati scelti quattro stati della sospensione in modo tale da farli corrispondere con le quattro tipologie di strada prese in considerazione per le simulazioni
5.4.2 calcola_parametri
Questa è una funzione importante del programma in quanto determina se è possibile effettuare una nuova regolazione o se è necessario attendere che quella precedente sia portata a termine.
Il numero di cicli di attesa dopo il quale è possibile aggiornare lo stato della sospensione è stato determinato mettendosi nelle peggiori condizioni per un ammortizzatore di tipo CDC, che prevedono un massimo tempo di intervento pari a 40 ms.
void calcola_parametri() { cicli++; switch (vecchio_stato_sosp) { case 3: if (nuovo_stato_sosp == 3) { if (cicli==4) { possibilita=1; vecchio_stato_sosp=3; cicli--; } else possibilita = 0; } if (nuovo_stato_sosp == 2) { if (possibilita==1) { vecchio_stato_sosp=2; possibilita=0; cicli=0; } else if (cicli==4) { possibilita=1; cicli--; } } if (nuovo_stato_sosp == 1) { if(possibilita==1) { possibilita=0;
cicli=0; } else if (cicli==4) { possibilita=1; cicli--; } } if (nuovo_stato_sosp == 0) { if(possibilita==1) { possibilita=0; vecchio_stato_sosp=0; cicli=0; } else if (cicli==4) { possibilita=1; cicli--; } } break; case 2: if (nuovo_stato_sosp == 2) { if (cicli==4) { possibilita=1; vecchio_stato_sosp=2; cicli--; } else possibilita = 0; } if (nuovo_stato_sosp == 3) { if (possibilita==1) { vecchio_stato_sosp=3;
} else if (cicli==4) { possibilita=1; cicli--; } } if (nuovo_stato_sosp == 1) { if(possibilita==1) { possibilita=0; vecchio_stato_sosp=1; cicli=0; } else if (cicli==4) { possibilita=1; cicli--; } } if (nuovo_stato_sosp == 0) { if(possibilita==1) { possibilita=0; vecchio_stato_sosp=0; cicli=0; } else if (cicli==4) { possibilita=1; cicli--; } } break; . . .
Ovviamente questa funzione prosegue prevedendo gli altri valori della variabile “vecchio_stato_sosp” pari a 0 e 1 , ma il modo di ragionare è identico ai casi sopra esposti, quindi non riporto tutta la funzione che risulterebbe lunga e alla fine scarsamente leggibile.
5.4.3 pilota_motore
Questa è la funzione che agisce sul registro del PCA del microcontrollore.
Come è possibile notare effettua una regolazione differente in base al valore della variabile assetto impostata dal pilota.
Il registro CCAP4L è quello responsabile di stabilire la soglia di scatto dell’uscita PWM, e quindi di determinare il duty cicle dell’onda stessa. La prima istruzione condizionale è necessaria per come è stata creata la funzione “calcola_parametri”. Infatti questa rendeva uguali le variabili “nuovo_stato_sosp” e “vecchio_stato_sosp” solo se la variabile “possibilita” valeva 1.
void pilota_motore() {
if( nuovo_stato_sosp== vecchio_stato_sosp) { switch (nuovo_stato_sosp) { case 0: if (assetto == 1) CCAP4L = 0x20;
case 1: if (assetto == 1) CCAP4L = 0x40; else CCAP4L = 0x50; break; case 2: if (assetto == 1) CCAP4L = 0xC0; else CCAP4L = 0xD8; break; case 3: if (assetto == 1) CCAP4L = 0xF0;
else CCAP4L = 0xE8; break;
default: CCAP4L = 0x80; }
} }
In caso di malfunzionamenti il valore del registro corrispondente al default impostato dovrà essere tale da far coincidere la caratteristica dell’attuatore con quello della sospensione attualmente montata dalla casa.
5.4.4 definisco
La funzione “definisco” serve per determinare la variabile
“acc_sosp_ant_utile” utilizzata nella funzione “aggiorna_stato_sospensione”. Il numero di tipologie di strada
considerato è quattro, quindi sarebbero stati sufficienti i due bits più significativi per effettuare la scelta.
Le specifiche di ingresso relative all’accelerazione proveniente dalla strada fornivano però degli intervalli differenti per ogni tipologia stradale, quindi si è reso necessario utilizzare i quattro bits più significativi. void definisco() { acc_sosp_ant_media &= 0xC0; switch(acc_sosp_ant_media) { case 0xF0 : acc_sosp_ant_utile = 3; break;
case 0xE0 : acc_sosp_ant_utile = 3; break;
case 0xD0 : acc_sosp_ant_utile = 3; break;
case 0xC0 : acc_sosp_ant_utile = 3; break;
break;
case 0xA0 : acc_sosp_ant_utile = 3; break; case 0x90 : acc_sosp_ant_utile = 2; break; case 0x80 : acc_sosp_ant_utile = 2; break; case 0x70 : acc_sosp_ant_utile = 2; break; case 0x60 : acc_sosp_ant_utile = 2; break; case 0x50 : acc_sosp_ant_utile = 1; break; case 0x40 : acc_sosp_ant_utile = 1; break; case 0x30 : acc_sosp_ant_utile = 1; break; case 0x20 : acc_sosp_ant_utile = 1; break; case 0x10 : acc_sosp_ant_utile = 0; break; case 0x00 : acc_sosp_ant_utile = 0; break; default: ; } }
