5 Sviluppo software, realizzazione ed integrazione
del sistema
In questo capitolo parleremo di come è possibile realizzare il firmware per caricarlo nel microcontrollore scelto. Saranno esaminati gli strumenti di sviluppo disponibili e/o selezionati, quindi esamineremo come sia stato configurato l’ambiente di sviluppo. In particolare vedremo una procedura automatizzata che consenta di sviluppare il firmware utilizzando il real-time workshop di Matlab.
5.1 L’ambiente Mplab
L’ambiente di sviluppo MPLAB è disponibile in forma gratuita, direttamente sul sito della Microchip [9]; tale programma consente la simulazione, il debug e lo sviluppo di programmi assembler per tutte le famiglie dei processori di produzione microchip, dai più datati PIC12, ai recenti dsPIC. Inoltre il sistema può facilmente essere integrato con tools esterni per fornire funzionalità aggiuntive (compilatori C, C++) altri programmatori e debugger. Di particolare interesse nel nostro caso è stata l’aggiunta di un tool per dotare il programma di un compilatore C. La microchip stessa, mette a disposizione, la versione dimostrativa, con limite di utilizzo di sessanta giorni, di un compilatore chiamatato mcc18, che come evidenzia il nome, è stato creato appositamente per la famiglia PIC18. Tra le varie caratteristiche questo compilatore, presenta una numerosa quantità di funzioni per l’accesso diretto ai dispositivi di IO, e alle periferiche come gli ADC, ed i timers. Con l’utilizzo del C18 è quindi possibile sviluppare in maniera molto rapida ed intuitiva codici C contenti ingressi ed uscite dati, ma al tempo stesso si hanno delle difficoltà (seppur sia sempre possibile) se si vuole riferirsi direttamente ai registri del microcontrollore, che non sono riferibili mediante un nome intuitivo (tipicamente simile al nome vero e proprio del registro )
limite di utilizzo di venti giorni, presso il sito della casa produttrice [9]. Tale programma ha il pregio di consentire un facile ed intuitivo accesso ai registri del controllore, ed è stato da noi utilizzato per la creazione e lo sviluppo del firmware. Anche l’Hitech C consente una facile integrazione con l’ambiente mplab. Grazie alla facile riconfigurabilità di questo ultimo è infatti possibile aggiungere moduli di sviluppo esterni che lavorano nei progetti mplab ed integrarli per lo sviluppo e il debug del codice.
5.2 Struttura dell’embedded real-time target
Matlab mette a disposizione uno strumento, chiamato real-time workshop, che consente di creare dei codici C, dei modelli Simulink creati. Tale strumento necessita che venga specificato il tipo di target, selezionabile, da una lista, variabile in riferimento alla versione di Matlab [7]; di particolare interesse è il target embedded real-time, che consente la creazione di un codice C, strutturato ed organizzato al fine di minimizzare l’occupazione di program memory e data memory. Usando pertanto tale strumento si ha un notevole vantaggio nello sviluppo del codice di programma, anche se si dovrà stare attenti ad alcuni accorgimenti per interfacciarlo in maniera corretta con l’ Mplab. Il funzionamento è molto semplice: una volta opportunamente configurato, il Real Time Workshop consente attivare un builder dai menù. Una volta lanciato il builder, che ha il compito di creare i file di codice, vengono creati sei file:
• ert_main.c • nome_modello.c • nome_modello.h • nome_modello_data.h • nome_modello_private.h • nome_modello_types.h
rt_OneStep, che implementa il modello simulink da noi realizzato. Questo file viene fornito a titolo di esempio e mostra una struttura molto semplice e personalizzabile cosicché il programmatore possa modificarlo per adattarlo alla struttura del sistema target di sviluppo (ovvero gestire l’input/output e la schedulazione degli eventi).
Le variabili, i parametri e le costanti vengono dichiarate nel file nome_modello_data.h, mentre le varie dichiarazioni di tipo typedef, vengono scritte nel file nome_modello_types.h . Nel file nome_modello_private.h sono esplicitate le varie dimensioni dei tipi di dato (ad esempio interi su 16 bit), e infine, in nome_modello.c, viene scritto il vero e proprio corpo della funzione rt_OneStep, mentre le varie dichiarazioni per il preprocessore saranno scritte nel nome_modello.h. La funzione rt_OneStep rappresenta il cuore degli schemi di controllo sviluppati in quanto essa racchiude in un'unica funzione tutto il codice necessario per eseguire l’aggiornamento degli schemi di controllo ad un passo di campionamento.
5.2.1 Modifiche da apportare per il corretto interfacciamento
Per generare una procedura automatizzata che consenta di poter riscrivere il firmware semplicemente lanciando il real-time workshop di Matlab, sarà necessario che i file generati dal builder non vengano minimamente modificati.
I file sopra citati andranno quindi lasciati così come sono, e non necessiteranno di modifiche, con l’esclusione dell’ert_main, che verrà discusso in seguito, e del file nome_modello.h .
Il compilatore Hitech-C, lavora con interi a 16 bit, e con double e float a 32 bit (tali dimensioni sono specificate nel file limits.h), mentre il real-time workshop lavora di default con interi su 32 bit; sarà pertanto opportuno modificare il file nome_modello_private.h, settando le giuste dimensioni dimensione massime per gli interi con segno e senza segno (ovvero inserendo i valori 0x7FFF ed 0xFFFF) onde evitare incongruenze con i file di libreria. Tale modifica dovrà essere fatta una volta soltanto visto che il nome_modello_private.h , tipicamente rimane invariato cambiando il modello simulink, e non necessita di essere cambiato ogni volta.
Oltre ai sei file creati dal real-time workshop, nella cartella di progetto andranno inseriti anche i seguenti file di libreria, direttamente copiabili dalle directory di Matlab:
• tmwtypes.h • simstruct_types.h • rtlibsrc.h
nel file tmwtypes.h, tramite numerose definizioni per il preprocessore vengono definiti i tipi di dato usati: nell’implementazione del codice infatti i tipi di dato vengono riferiti con nomi generici (ad esempio Real_T) e si dovrà pertanto associare a tali nomi il giusto tipo di dato. Tale associazione sarà fatta tenendo in considerazione le dimensioni scritte nei file file_name_private.h e limits.h .
Nel file simstruct_types.h troviamo invece le definizioni di tipo delle varie strutture usate per la descrizione del modello Simulink, ed infine nel rtlibsrc.h, sono definite alcune funzioni utili, quali le operazioni tra matrici.
Non vi sono modifiche da apportare a questi file, e la loro grandezza non deve spaventare: infatti le numerose direttive di preprocessore fanno sì che di tutta l’estensione del file, venga compilata solo una piccola parte.
I file di libreria matematica, sono già presenti nelle librerie dell’ HT-PIC18, e pertanto non necessitano di essere inclusi.
5.2.2 Modifiche al main
Le modifiche sostanziali che il programmatore deve fare sono al file ert_main.c. Qui si dovranno implementare le funzioni necessarie all’ingresso ed uscita dati, o eventualmente aggiungere degli include ai file dove sono implementate tali funzioni, ed associare i giusti valori agli ingressi della funzione rt_OneStep. Inoltre si potrà eventualmente cambiare la modalità con cui chiamare questa funzione (a controllo di programma o d’interruzione).
Abbiamo aggiunto in tale file due strutture che contengono i dati d’ingresso e di uscita chiamate rispettivamente packet_in e packet_data : la prima conterrà i valori letti dagli accelerometri, la seconda invece implementerà il protocollo di comunicazione descritto nel capitolo precedente, strutturando un pacchetto dati composto da due byte di Start, 2 valori short int (rispettivamente la posizione x e y), e due byte di stop.
Riportiamo in tabella le funzioni da noi aggiunte, con le relative descrizioni:
FUNZIONE descrizione InitComms Inizializza le comunicazioni della porta seriale settando i
registri SPBRG,TXSTA,RCSTA
Serial_Interrupt Lancia la funzione InitComms e setta il registro INTCON ed il bit TXIE
ADCSetup Setta il registro ADCON1
Timer0( ) Setta il valore del registro T1CON e dei flag INT0IE ed INT0IF
ADCChan(X) Seleziona il canale X dell’ADC settando il registro ADCON1
interrupt isr In base al tipo di flag che ha generato l’interrupt lancia o la funzione packet_send() oppure la funzione
timer_proc()
packet_send Scrive nel registro TXREG l’i-esimo byte della struttura packet_data ed incrementa il valore di i.
Timer_proc Lanciata ogni 640 µs, alternativamente setta a 1 il bit GO/DONE, e legge i registri ADRESH,ADRESL del canale INDEX, incrementando il valore di INDEX.
Il main provvederà a lanciare le funzioni di inizializzazione, ed implementerà un ciclo infinito in cui vengono assegnati i valori dei dati del pacchetto packet_in ai rispettivi
ingressi della funzione rt_OneStep, e le uscite di tale funzione al pacchetto packet_data.
Si osservi come il tempo in cui vengono letti i convertitori A/D sia salito rispetto alle specifiche citate nel capitolo 4, la motivazione è semplice: si chiami con N il numero di passi necessari per una lettura dall’ADC, e con la frequenza del clock del microprocessore. Il numero di passi al secondo sarà pertanto
c f c f N⋅ , ed essendo: 4 c f FLOP=
il carico computazionale della lettura degli ADC sarà pertanto calcolabile come:
FLOP T N Cc c⋅ =
Chiamando pertanto la funzione ogni 40 µs, e supponendo un valore di N pari a 80, avremmo in un secondo l’esecuzione di circa 8 istruzioni atte alla lettura degli ADC, ovvero l’80% del calcolo totale (supponendo che il microcontrollore lavori ad una velocità di 10 MIPS). Impostando un fattore di divisione per 16 nel tempo di lettura scendiamo invece al 4% circa. Tale divisione fa pertanto scendere la frequenza di campionamento che rimane però ampiamente nelle nostre specifiche.
6 10 ⋅
Da notare infine che nel main viene fatto riferimento soltanto agli ingressi/uscite della funzione rt_onestep, e pertanto se si ha l’accortezza di non cambiare i loro nomi ed il loro numero durante un eventuale upgrade del modello simulink, non si ha necessità di modificare tale file. In tale modo, una volta ottenuto un modello simulink con funzionalità aggiuntive o migliori, si potrà lanciare il builder, e copiare i file prodotti nella cartella di progetto, senza necessità di effettuare alcun tipo di modifica.
5.3 Gestione dello schema in base ai vincoli tecnici
La procedura automatizzata appena descritta porta come è facile immaginare ad un notevole risparmio di tempo nella scrittura ed aggiornamento del firmware, dovremo
generare il modello simulink, onde evitare spiacevoli sorprese al momento della compilazione e della generazione del file esadecimale.
5.3.1 Accorgimenti nella creazione del modello simulink
Nell’implementazione del nostro modello dovremo: • Minimizzare il numero di costanti
• Far abbondante uso di blocchi vettoriali
• Evitare se possibile l’uso di blocchi di librerie non standard (ad esempio DSP, Aereospace Blockset, e via dicendo)
Due costanti, anche se di valore identico verranno dichiarate nel file C con nomi diversi ed andranno ad occupare due spazi di memoria differenti, si dovrà pertanto cercare di usare il minor numero di costanti possibile al fine di evitare inutile spreco di memoria.
Similmente si dovrà anche far un’abbondante uso di blocchi vettoriali, in modo da evitare di avere due blocchi identici i cui parametri verranno dichiarati due volte.
2 Out2 1 Out1 1 s Integrator1 1 s Integrator 2 In2 1 In1 2 Out2 1 Out1 1 s Integrator em 2 In2 1 In1
Fig 5.3.1 : uso dei blocchi vettoriali
La mancata osservanza di questi due accorgimenti può portare non soltanto ad un peggioramento delle prestazioni, ma anche a veri e propri problemi nella compilazione del codice sorgente per la generazione del codice oggetto. Infatti per minimizzare l’occupazione di memoria, il builder inserisce tutti i parametri in un'unica struttura, le cui dimensioni possono in questo modo diventare notevoli. Questo effetto può causare problemi al linker dal momento che la memoria sui microcontrollori è frazionata in banchi come nel caso del PIC18F6621. In questa situazione può quindi accadere che la struttura dati non rientri nelle dimensioni di un banco generando un errore del tipo Fixed-up.
L’ultima precauzione da prendere è quella di evitare, se possibile, l’uso di blocchi appartenenti a librerie di tipo non standard ad esempio i blocchi per dsp: tali blocchi infatti, non essendo nativi del sistema Target, necessitano l’inserzione nella cartella di progetto di ulteriori file di libreria, quali ad esempio il dsp.h/c, che possono causare un inutile aumento dell’occupazione della memoria.
5.3.2 Risultati della compilazione dello schema di controllo
Ad una prima compilazione dello schema di controllo finale, visto in figura 3.5.1, abbiamo ottenuto numerosi errori di fixed-up dovuti, come già detto, all’eccessivo numero di costanti, alla ripetizioni di blocchi funzionalmente identici, nonché alla presenza di alcuni blocchi provenienti dalla libreria DSP. Utilizzando gli
accorgimenti citati nel paragrafo precedente siamo riusciti a compilare con successo il codice ottenendo i seguenti risultati
• 35 Kbyte di occupazione di program memory • 2.5 Kbyte di data memory
