Embed Size (px)
Citation preview
Universita degli studi di PisaCorso di Laurea Specialistica in Ingegneria dell’Automazione
Sviluppo di software in Simulink e Real-TimeWorkshop Embedded Coder
Paolo Tripicchio
Corso di MeccatronicaAnno accademico 2007/2008
Indice
1 The MathWorks 41.1 Il MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Il Simulink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Lo Stateflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Real Time Workshop 82.1 Scelta e configurazione del target . . . . . . . . . . . . . . . . 102.2 File sorgenti generati e dipendenze dei file . . . . . . . . . . . 112.3 Esecuzione del modello . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Modelli per Sistemi Real-Time Single-Tasking . . . . . 132.3.2 Modelli per Sistemi Real-Time Multitasking . . . . . . 14
2.4 Temporizzazione del Programma . . . . . . . . . . . . . . . . 162.5 Differenze tra i Modelli di Esecuzione Rapid Prototyping ed
Embedded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.1 Funzioni del Modello Embedded . . . . . . . . . . . . . 17
2.6 Esecuzione di Modelli Multitasking . . . . . . . . . . . . . . . 182.7 Transizioni della Frequenza di Campionamento . . . . . . . . . 19
2.7.1 Problemi di Trasferimento Dati . . . . . . . . . . . . . 202.7.2 Assunzioni sul Trasferimento Dati . . . . . . . . . . . . 212.7.3 Opzioni del Blocco Rate Transition . . . . . . . . . . . 212.7.4 Automatic Rate Transition . . . . . . . . . . . . . . . . 23
2.8 Utilizzo delle S-Functions . . . . . . . . . . . . . . . . . . . . . 232.8.1 Tipi di S-Function . . . . . . . . . . . . . . . . . . . . 242.8.2 Noninlined S-Functions . . . . . . . . . . . . . . . . . . 242.8.3 Wrapper S-Functions . . . . . . . . . . . . . . . . . . . 252.8.4 Fully Inlined S-Functions . . . . . . . . . . . . . . . . . 252.8.5 MEX S-Function Wrapper . . . . . . . . . . . . . . . . 262.8.6 TLC S-Function Wrapper . . . . . . . . . . . . . . . . 282.8.7 Fully Inlined S-Functions . . . . . . . . . . . . . . . . . 31
2.9 Utilizzo di Blocchi Asincroni di Interruzione in Simulazione eGenerazione del Codice . . . . . . . . . . . . . . . . . . . . . . 32
1
2.9.1 Rate Transitions e Blocchi Asincroni . . . . . . . . . . 33
3 Real Time Workshop Embedded Coder 343.1 Stuttura Dati del Modello Real-Time . . . . . . . . . . . . . . 353.2 Esecuzione di Programmi Stand-Alone . . . . . . . . . . . . . 363.3 Programma Main . . . . . . . . . . . . . . . . . . . . . . . . . 363.4 rt OneStep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.1 Single-Rate Singletasking . . . . . . . . . . . . . . . . . 373.4.2 Multi-Rate Multitasking . . . . . . . . . . . . . . . . . 383.4.3 Rate Grouping . . . . . . . . . . . . . . . . . . . . . . 383.4.4 Multi-Rate Singletasking . . . . . . . . . . . . . . . . . 39
3.5 Linee Guida per la modifica di rt OneStep . . . . . . . . . . . 40
4 Ottimizzazioni fixed-point 414.1 Rappresentazione fixed-point . . . . . . . . . . . . . . . . . . . 41
5 Impostazioni Real Time Workshop 465.1 Block Reduction Optimization . . . . . . . . . . . . . . . . . . 465.2 Conditional Input Branch Execution . . . . . . . . . . . . . . 475.3 Implement Logic Signals as Boolean Data . . . . . . . . . . . 485.4 Signal Storage Reuse . . . . . . . . . . . . . . . . . . . . . . . 485.5 Inline Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 495.6 Application Lifespan . . . . . . . . . . . . . . . . . . . . . . . 495.7 Enable Local Block Outputs . . . . . . . . . . . . . . . . . . . 505.8 Reuse Block Outputs . . . . . . . . . . . . . . . . . . . . . . . 505.9 Ignore Integer Downcasts in Folded Expressions . . . . . . . . 505.10 Inline Invariant Signals . . . . . . . . . . . . . . . . . . . . . . 505.11 Eliminate Superfluous Temporary Variables (Expression Fold-
ing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.12 Loop Unrolling Threshold . . . . . . . . . . . . . . . . . . . . 525.13 Remove Code from Floating-Point to Integer Conversions That
Wraps Out-of-Range Values . . . . . . . . . . . . . . . . . . . 535.14 Parameter Structure . . . . . . . . . . . . . . . . . . . . . . . 535.15 Sottopannello Data Initialization . . . . . . . . . . . . . . . . 535.16 Remove code that protects against division arithmetic exceptions 54
2
Elenco delle figure
2.1 Real-Time Workshop Flowchart . . . . . . . . . . . . . . . . . 112.2 File generati e dipendenze . . . . . . . . . . . . . . . . . . . . 122.3 Task timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4 Configurazione blocco Rate Transition . . . . . . . . . . . . . 222.5 Approccio a doppio-modello . . . . . . . . . . . . . . . . . . . 32
4.1 Rappresentazione fixed-point . . . . . . . . . . . . . . . . . . . 424.2 Simulink fixed-point . . . . . . . . . . . . . . . . . . . . . . . 444.3 Stateflow fixed-point . . . . . . . . . . . . . . . . . . . . . . . 44
5.1 Pannello Hardware Implementation . . . . . . . . . . . . . . . 555.2 Pannello Real-Time Workshop . . . . . . . . . . . . . . . . . . 565.3 Pannello interface . . . . . . . . . . . . . . . . . . . . . . . . . 565.4 Pannello Templates . . . . . . . . . . . . . . . . . . . . . . . . 575.5 Pannello C166 Options . . . . . . . . . . . . . . . . . . . . . . 58
3
Capitolo 1
The MathWorks
La The MathWorks e il principale sviluppatore e fornitore di software peril calcolo tecnico e la progettazione model-based. The MathWorks e statafondata nel 1984 e oggi da lavoro a piu di 1500 persone con uffici e sedi rap-presentative in tutto il mondo.La The MathWorks produce software di calcolo e progettazione per ingegneri,matematici e ricercatori. I prodotti di punta della compagnia sono il MAT-LAB, utilizzato per effettuare calcoli matematici, analizzare e visualizzaredati, scrivere nuovi programmi software; e Simulink, utilizzato per la model-lazione e la simulazione di sistemi complessi. Altri pacchetti sono affiancatiai principali per esigenze particolari.
4
1.1 Il MATLAB
Il MATLAB e un linguaggio ad alto livello ed un ambiente interattivo chepermette all’utente di compiere processi computazionalmente dispendiosi inmaniera piu veloce che con i linguaggi di programmazione tradizionali.E’ possibile utilizzare MATLAB in un largo numero di applicazioni tra lequali il filtraggio di segnali ed immagini, la progettazioni di controllori, laeffettuazione di test e misurazioni, la modellazione finanziaria e la biologiacomputazionale. Toolbox aggiuntivi estendono l’ambiente MATLAB permet-tendo di risolvere particolari classi di problemi.Il MATLAB fornisce una serie di meccanismi per documentare e condivire ilproprio lavoro. Riassumendo il MATLAB fornisce:
• Un linguaggio ad alto livello per il computo tecnico
• Un ambiente di sviluppo per la gestione di codice, files e dati
• Dei tools interattivi per l’esplorazione iterativa, la progettazione e larisoluzione di problemi
• Delle funzioni matematiche per l’algebra lineare, la statistica, l’analisidi Fourier, il filtraggio, l’ottimizzazione e l’integrazione numerica.
• Funzioni grafiche 2D e 3D per visualizzare i dati
• Strumenti per la creazione di interfaccie grafiche peronalizzate
• Funzioni per integrare gli algoritmi di MATLAB con applicazioni elinguaggi esterni.
1.2 Il Simulink
Il Simulink e ua piattaforma per la simulazione e la progettazione model-based dei sistemi dinamici. Esso fornisce un ambente grafico interattivo e uninsieme di librerie di blocchi personalizzabile che permettono di progettareaccuratamente, simulare, implementare e testare sistemi tempo varianti.Dei prodotti aggiuntivi estendono l’ambiente Simulink con strumenti per lamodellazione e la generazione di codice specifica.Simulink e integrato con MATLAB garantendo un accesso immediato ad unnumeroso insieme di strumenti per lo sviluppo di algoritmi, la visualizzazionedei dati, l’analisi dei dati e il calcolo numerico.Riassumendo il Simulink fornisce:
5
• Un numero estensivo ed espandibile di librerie di blocchi predefiniti
• Un editor grafico interattivo per l’assemblamento e la gestione intuitivadei diagrammi a blocchi
• La capacita di trattare progetti complessi segmentando i modelli dentrogerarchie dei componenti del progetto
• La capacita di interfacciarsi con altri programmi di simulazione e diincorporare codice scritto a mano
• Le opzioni per simulare i sistemi tempo-varianti interattivamente conpasso fisso o variabile
• Le funzioni per definire interattivamente gli ingressi e vedere le usciteper valutare il comportamento del modello
• Un accesso completo alle funzionalita del MATLAB
• Strumenti per l’analisi di modello e strumenti diagnostici per assicurarela consistenza del modello ed identificare gli errori di modellazione
1.3 Lo Stateflow
Lo Stateflow e uno strumento per la simulazione e la progettazione interattivadei sistemi ad eventi che si va ad aggiungere al Simulink. Lo Stateflowfornisce gli elementi richiesti per la descrizione della logica complessa in unaforma naturale e comprensibile. Fornisce quindi un ambiente efficiente perla progettazione di sistemi embedded che contengono logica di supervisioneo di controllo.I diagrammi Stateflow permettono una rappresentazione grafica degli statiparalleli o gerarchici e delle transizioni event-driven tra di essi. Con l’utilizzodello Stateflow Coder e anche possibile generare codice C ottimizzato daidiagrammi Stateflow. Riassumendo lo Stateflow:
• Fornisce elementi di linguaggio, gerarchia, parallelismo e semantica diesecuzione deterministica per la descrizione di logica complessa in unaforma naturale e comprensibile
• Offre la possibilta di definire funzioni in maniera grafica attraverso di-agrammi di flusso, in maniera procedurale tramite il linguaggio MAT-LAB e in forma tabellare con le tabelle della verita.
• Schedula le transizioni e gli eventi usando una logica temporale
6
• Supporta le macchine a stati finiti di Mealy e di Moore
• Anima i diagrammi Stateflow e i dati di log durante la simulazione permigliorare la comprensione del sistema e facilitare il debugging
• Include un debugger integrato per impostare breakpoints grafici, pro-cedere a passi attraverso gli schemi e passare in rassegna i dati.
7
Capitolo 2
Real Time Workshop
Real-Time Workshop genera codice ANSI C/C++ ottimizzato dai modelliSimulink per creare implementazioni dei modelli standalone che operano inreal-time o non-real-time in un varieta di ambienti target. Il codice generatopuo essere eseguito su hardware PC, DSP , microcontrollori e tramite sistemioperativi real-time proprietari (RTOS). Il Real-Time Workshop aumenta lavelocita di simulazione, la protezione della proprieta intellettuale e la prototi-pazione su diversi targets. La figura mostra il ruolo del Real-Time Workshopnel processo di progettazione del software.Il Real-Time Workshop e un sistema aperto progettato per essere utilizzato
con una larga varieta di ambienti operativi e tipi di hardware. Il proces-
8
so di generazione dei programmi tramite Real-Time Workshop puo essereconfigurato secondo le proprie esigenze modificando i seguenti componenti:
• Simulink ed il file modello (model.mdl)Simulink fornisce un ambiente di sviluppo con linguaggio ad alto livel-lo(VHLL). Gli elementi del linguaggio sono i blocchi e sottosistemi cheinterpretano visivamente gli algoritmi. Si puo pensare al Real-TimeWorkshop come ad un compilatore che processa programmi sorgen-ti VHLL (model.mdl) e genera codice utilizzabile da un compilatore dilinguaggi ad alto livello tradizionale. Le S-functions scritte in C o C++estendono il linguaggio VHLL di Simulink aggiungendo nuovi blocchie funzionalita.
• La descrizione di modello intermedia (model.rtw)La fase iniziale del processo di generazione del codice consiste nell’ana-lizzare il modello sorgente. Il file di descrizione risultante contiene unastruttura gerarchica di records che descrivono i sistemi, i blocchi e leloro connessioni.L’ S-function API include una funzione speciale (mdlRTW) che per-mette di personalizzare il processo di generazione del codice inserendoparametri dai propri blocchi nel file model.rtw.
• Il programma Target Language Compiler (TLC)Il Target Language Compiler legge la descrizione del modello interme-dia e genera il codice che implementa il modello come un programma.Si possono personalizzare gli elementi del TLC in due modi. Il pri-mo consiste nell’implementare un proprio system target file che ha ilcontrollo completo sui parametri di generazione del codice, il secon-do nell’implementare i block target files che controllano come vengagenerato il codice per i blocchi individuali quali ad esempio i blocchiS-function.
• Il codice sorgente generato dal modelloCi sono diversi metodi per personalizzare il codice generato o interfac-ciarlo a del codice personalizzato:
– Gli entry points esportati permettono di interfacciare il propriocodice scritto a mano al codice generato. Questo rende possibilelo sviluppo di un proprio meccanismo di esecuzione e di temporiz-zazione nonche di combinare il codice generato da piu modelli inun solo eseguibile.
9
– Si puo rendere visibile al codice esterno ogni segnale, parametro ealtra struttura dati rendendo piu facile il tuning dei parametri ela monitorizzazione dei segnali.
– E’ possibile modificare o preparare i files di script del Target Lan-guage Compiler per personalizzare la trasformazione dei blocchiSimulink in codice sorgente.
• File di supporto all’interfaccia run-timeL’interfaccia run-time consiste in un codice che si interfaccia al codicegenerato del modello. Si possono creare una svariata serie di file diinterfaccia ( protocolli di comunicazione, timers, interrupts, etc.).
• Il template makefile e model.mkIl makefile model.mk controlla la compilazione e il linking del codicegenerato. Il Real-Time Workshop genera model.mk da un templatemakefile durante la fase di generazione del codice. E’ possibile creareun template makefile personalizzato per controllare le opzioni di com-pilazione e le variabili del processo di make.
Tutte queste componenti contribuiscono al processo di trasformazione di unmodello Simulink in un programma eseguibile. La figura 2.1 riporta il dia-gramma di flusso di questo processo.
2.1 Scelta e configurazione del target
Il primo passo per impostare un file per la generazione di codice e sceglieree configurare un sistema target. Il processo di creazione di codice specificoper il target e controllato da:
• Un system target file
• Un template makefile
• Un comando make
E’ possibile specificare queste informazioni di configurazione per uno specificotarget in un solo passo usando il System target File Browser. Il browserelenca una serie di configurazioni ottimizzate pronte all’uso. Una volta sceltoil target, Real-Time Workshop modifica le impostazioni della configurazionecorrente per renderla compatibile con il system target file corrispondente.
10
Figura 2.1: Real-Time Workshop Flowchart
2.2 File sorgenti generati e dipendenze dei
file
I file sorgenti e i make files creati da Real-Time Workshop vengono generatidentro la propria build directory che viene creata nella directory corrente.Alcuni file vengono generati incondizionatamente mentre l’esistenza degli al-tri dipende dalle impostazioni del target.Per esempio il pacchetto file del target Real-Time Workshop Embedded coderdifferisce leggermente dal pacchetto descritto qui sotto. Le dipendenze deifile sorgenti generati da Real-Time Workshop sono mostrate in figura 2.2. Lefreccie che partono da un file puntano ai files che esso include. Come mostra-to dalla figura esistono anche altre dipendenze rispetto ai file di intestazionedi Simulink tmwtypes.h, simstruc types.h e rtlibsrc.h e ai file delle librerie Ce C++.Il diagramma mostra le relazioni di inclusione unicamente tra i file generati
11
Figura 2.2: File generati e dipendenze
nella directory di build. Il diagramma mostra anche che il file di intestazionedel sistema genitore (model.h) include tutti i file di intestazione dei sottosis-temi figli (subsystem.h). In modelli a piu livelli naturalmente i sottosistemiincludono similiarmente i file di intestazione di propri figli e cosı via nella ger-archia del modello. Come conseguenza i sottosistemi sono capaci di vederericorsivamente in tutti i sottosistemi discendenti cosı come nel sistema radiceperche tutti i subsystem.c includono model.h e model private.h.
2.3 Esecuzione del modello
Real-Time Workshop genera codice algoritmico cosı come e stato definito nelproprio modello. E’ possibile includere il proprio codice nel modello utiliz-zando le S-functions.Real-Time Workshop e provvisto anche di una interfaccia run-time che es-egue il codice generato del modello. L’interfaccia run-time ed il codice delmodello sono compilati insieme per creare l’eseguibile del modello. A noiinteressa sapere a livello concettuale come funziona l’esecuzione del modelloper sistemi single-tasking e multitasking in fase di simulazione ma soprat-tutto in esecuzione real-time. Per la maggior parte dei modelli un’ambiente
12
multitasking risultera in una esecuzione del modello piu efficiente.I concetti seguenti sono utili nella descrizione di come esegue il modello. Ri-porto qui i nomi delle funzioni usate nei target GRT e ERT con tra parentesile analoghe chiamate GRT-compatibili.
• Inizializzazione: model initialize (MdlInitializeSizes, MdlInitialize-SampleTimes, MdlStart) inizializza il codice di interfaccia run-time eil codice del modello.
• ModelOutputs: Vengono chiamati tutti i blocchi nel modello che han-no il campionamento al tempo corrente e viene prodotta la loro uscita.model outputs (MdlOutputs) puo essere eseguito nei passi temporalimaggiori o minori. Nei passi temporali maggiori l’uscita e data dal pas-so corrente di simulazione, negli intervalli temporali minori l’interfacciarun-time calcola le derivate per aggiornare gli stati continui.
• ModelUpdate: model update (MdlUpdate) chiama tutti i blocchidel modello che hanno il campionamento al tempo corrente e aggiornai loro stati discreti.
• ModelDerivatives: Chiama tutti i blocchi del modello che hanno staticontinui e aggiorna le loro derivate. model derivatives e chiamatosolamente nei passi temporali minori.
• ModelTerminate: model terminate (MdlTerminate) termina il pro-gramma se ha un tempo di esecuzione finito. Distrugge inoltre la strut-tura dati del modello real-time, dealloca la memoria e puo scrivere deidati su di un file.
2.3.1 Modelli per Sistemi Real-Time Single-Tasking
Lo pseudocodice che segue mostra l’esecuzione di un modello in un sistemareal-time single-tasking dove il modello viene eseguito a livello di interrupt.
rtOneStep()
{
Controllo interrupt overflow
Attivazione interrupt "rtOneStep"
ModelOutputs -- passo temporale maggiore.
LogTXY -- Log Tempo, stati e porte di uscita.
ModelUpdate -- passo temporale maggiore.
Integrate -- Integrazione nei passi temporali minori per
13
-- gli stati continui
ModelDerivatives
Do 0 o Piu
ModelOutputs
ModelDerivatives
EndDo (Il numero di iterazioni dipende dal solutore.)
Calcolo derivate per aggiornare stati continui.
EndIntegrate
}
main()
{
Initializzazione (inclusa istallazione di rtOneStep come
interrupt service routine, ISR, per un clock real-time).
While(tempo < tempo finale)
Esecuzione processi in Background.
EndWhile
Mask interrupts (Disattiva rtOneStep dall’esecuzione.)
Completa tutti i Processi in Background.
Shutdown
}
L’esecuzione real-time single-tasking e molto simile all’esecuzione non-real-time (simulazione) eccetto che invece di eseguire liberamente il codice lafunzione rt OneStep e pilotata da un interrupt del timer periodico.Negli intervalli specificati dal tempo di campionamento di base del program-ma l’ interrupt service routine (ISR) blocca i processi in background per es-eguire il codice del modello. Il tempo di campionamento di base e il piu velocenel modello. Se il modello ha blocchi continui allora il passo di integrazionedetermina il tempo di campionamento di base.
2.3.2 Modelli per Sistemi Real-Time Multitasking
Lo pseudocodice che segue mostra come viene eseguito un modello in un sis-tema real-time multitasking quando l’esecuzione e associata ad un interrupt.
rtOneStep()
{
Controllo interrupt overflow
Attivazione interrupt "rtOneStep"
14
ModelOutputs(tid=0) -- passo temporale maggiore.
LogTXY -- Log Tempo, stati e porte di uscita.
ModelUpdate(tid=0) -- passo temporale maggiore.
Integrate -- Integrazione nei passi temporali minori per
-- gli stati continui
ModelDerivatives
Do 0 o Piu
ModelOutputs(tid=0)
ModelDerivatives
EndDo (Il numero di iterazioni dipende dal solutore.)
Calcolo derivate per aggiornare stati continui.
EndIntegrate
For i=1:NumTasks
If (hit in task i)
ModelOutputs(tid=i)
ModelUpdate(tid=i)
EndIf
EndFor
}
main()
{
Initializzazione (inclusa istallazione di rtOneStep come
interrupt service routine, ISR, per un clock real-time).
While(time < final time)
Esecuzione processi in Background.
EndWhile
Mask interrupts (Disattiva rtOneStep dall’esecuzione.)
Completa tutti i Processi in Background.
Shutdown
}
Eseguire modelli a livello interrupt in un ambiente real-time multitaskinge molto simile ad eseguirli nel precedente ambiente single-tasking con l’ec-cezione che interruzioni sovrapposte sono adoperate per l’esecuzione concor-rente dei processi.
15
2.4 Temporizzazione del Programma
I programmi real-time richiedono una temporizzazione attenta per l’invo-cazione dei task per assicurare che il codice del modello termini la sua es-ecuzione prima che avvenga un’altra chiamata del task. Questo include iltempo per leggere e scrivere dati da e verso hardware esterno.La figura 2.3 mostra la temporizzazione dell’interruzione. L’intervallo di
Figura 2.3: Task timing
campionamento deve essere abbastanza grande da permettere l’esecuzionedel codice del modello tra le invocazioni dei task.Nella figura 2.3 il tempo tra due frecce verticali adiacenti e l’intervallo dicampionamento. Il primo diagramma mostra un esempio di come un pro-gramma possa completare un passo all’interno dell’intervallo lasciando anco-ra del tempo per eseguire i processi in background. Il diagramma inferioremostra cosa succede se l’intervallo di campionamento e troppo corto: Si haun’altra invocazione di processo prima che il processo sia completato ovveroavviene un errore di esecuzione.Come mostra l’esempio precedente un programma real-time non puo richiedereil 100% del tempo della CPU. Questo garantisce l’opportunita di eseguire pro-cessi in background nel tempo libero.E’ importante comunque che il programma sia capace di prelazionare i pro-cessi in background al tempo appropiato per assicurare l’esecuzione real-timedel codice del modello.
16
2.5 Differenze tra i Modelli di Esecuzione Rapid
Prototyping ed Embedded
Il Rapid Prototyping fornisce una interfaccia di programmazione delle ap-plicazioni (API) che non cambia tra le definizioni di modello. L’ Embed-ded Coder invece fornisce una API ottimizzata su misura al proprio modello.Quando viene utilizzato lo stile embedded di generazione del codice la model-lazione viene fatta nel modo in cui si vuole che esegua il codice nel sistemaembedded.Una delle maggiori differenze tra lo stile di generazione del codice RapidPrototyping ed Embedded e che quest’ultimo contiene meno funzioni entry-point. Lo stile di codice Embedded puo essere configurato per avere un unicafunzione run-time, model step.Quindi facendo riferimento allo pseudocodice di esecuzione del modello pre-sentato prima si possono eliminare gli statements Loop...EndLoop e rag-gruppare ModelOutputs, LogTXY e ModelUpdate in un singolo statement,model step.
2.5.1 Funzioni del Modello Embedded
Il target Real-Time Workshop Embedded Coder genera le seguenti funzioni:
• model initialize: Si occupa di tutte le inizializzazioni del modelloe deve essere chiamata una volta prima di avviare l’esecuzione delmodello.
• Se e stata selezionata l’opzione di generazione del codice Single out-put/update function allora si avra
– model step(int T tid): Contiene il codice di uscita e di updateper tutti i blocchi del modello.
Altrimenti si avra
– model output(int T tid): Contiene il codice di uscita per tuttii blocchi del modello.
– model update(int T tid): Contiene il codice di update per tuttii blocchi del modello.
• Se l’opzione di generazione del codice Terminate function requirede selezionata si avra anche
17
– model terminate: Questa funzione contiene tutto il codice diterminazione e deve essere chiamato come parte dello spegnimentodel sistema.
Altre informazioni piu specifiche sono nel capitolo 3 relativo al Real-TimeWorkshop Embedded Coder.
Ogni blocchetto Simulink ha un tempo di campionamento. I blocchi nellacategoria inherited acquistano il tempo di campionamento dai blocchi che liprecedono. I blocchi continui hanno un tempo di campionamento nominaledi zero. E’ possibile progettare blocchetti che lavorano a differenti tempi dicampionamento per le porte di ingresso e di uscita, questi blocchi hanno iltempo di campionamento specificato sulle porte. Quindi e possibile avereblocchi con differenti tempi di campionamento nel modello. Un possibilevantaggio di utilizzare tempi di campionamento multipli e l’aumentata effi-cienza che si ottiene quando si esegue il modello in un ambiente real-timemultitasking.Simulink prevede una certa flessibilita nella creazione di sistemi multirate.Tuttavia, la stessa flessibilita permette anche di costruire modelli per i qualiil generatore di codice non e in grado di generare codice real-time correttoper l’esecuzione in un sistema multitasking.Per far eseguire correttamente i modelli multirate in real-time a volte e nec-essario modificare i modelli o istruire Simulink per farli modificare a lui. Ingenerale le modifiche riguardano il piazzamento di blocchetti Rate Transi-tion tra i blocchi con tempi di campionamento differenti.I prossimi paragrafi illustrano le procedure per utilizzare con successo unmodello in un ambiente multitasking.
2.6 Esecuzione di Modelli Multitasking
Nei casi in cui la parte continua del modello esegua ad un rate differente dallaparte discreta oppure un modello abbia blocchi con tempi di campionamen-to differenti Simulink assegna a ciascun blocco un identificatore di processo(tid) per associare il blocco con il processo che va in esecuzione al tempo dicampionamento del blocco.I tempi di campionamento si selezionano nel pannello Configuration Pa-rameters - Solver. Per generare codice con Real-Time Workshop si deveselezionare come tipo di solutore un solutore a passo fisso. Si hanno alcunerestrizioni sui tempi di campionamento che si possono utilizzare.
18
• Il tempo di campionamento di ciascun blocco deve essere un multiplointero del tempo di campionamento base(il piu veloce).
• I blocchi continui vengono eseguiti utilizzando un algoritmo di inte-grazione che gira al tempo di campionamento base. Il periodo di cam-pionamento base e il massimo comun denominatore di tutti i rates delmodello se la dimensione del passo di integrazione e impostata su auto.
• Le parti continue e discrete del modello possono eseguire a rates differ-enti solo se la parte discreta esegue ad un rate uguale o minore dellaparte continua ed e un multiplo intero del rate di campionamento base.
Quando vengono eseguiti dei processi periodici in modalita multitasking, didefault i blocchi con frequenza di campionamento maggiore vengono eseguitidai processi con la piu alta priorita, i successivi blocchi piu veloci vengonoeseguiti da processi con la successiva priorita piu alta. Questo rende l’ese-cuzione del programma efficiente.Quando i processi sono asincroni invece che periodici non c’e necessariamenteuna relazione stretta tra tempi di campionamento e priorita dei processi. Lepriorita per i processi asincroni possono essere specificate utilizzando i bloc-chi Async Interrupt e Task Synchronization.Si puo cambiare il significato del numero di priorita selezionando o deselezio-nando l’opzione Higher priority value indicates higher task prioritynel pannello Solver.Negli ambienti multitasking si possono definire processi separati e assegnareloro delle priorita. Nei target bare-board invece non si possono creare taskseparati. Tuttavia, i moduli di applicazione di Real-Time Workshop im-plementano quello che in effetti e uno schema di esecuzione multitaskingutilizzando interrupts innestati seguiti da cambi di contesto programmatici.
2.7 Transizioni della Frequenza di Campiona-
mento
In un modello Simulink possono avvenire due tipologie di transizione trasample rate periodici:
• Un blocco piu veloce che pilota un blocco piu lento
• Un blocco piu lento che pilota un blocco piu veloce
Le prossime sezioni fanno riferimento esclusivamente a modelli con tempi dicampionamento periodici e senza offset. Altre considerazioni si applicano ai
19
modelli multirate che utilizzano processi asincroni (vedi paragrafo 2.9.1).Nei sistemi single-tasking non ci sono problemi nell’avere piu tempi di cam-pionamento. Nei sistemi multitasking o pseudomultitasking invece differentifrequenze di campionamento possono causare problemi facendo eseguire iblocchi nell’ordine sbagliato. Per prevenire errori nei dati calcolati si devequindi controllare l’esecuzione del modello durante queste transizioni. Quan-do si connettono blocchi piu veloci e piu lenti si devono aggiungere blocchettiRate Transition tra essi (o dobbiamo farli aggiungere da Simulink).
2.7.1 Problemi di Trasferimento Dati
Per capire il funzionamento dei blocchi Rate Transition devo introdurre iconcetti di integrita dei dati e determinismo associati al trasferimento datitra blocchi che eseguono a rates differenti.
• Integrita dei dati: Si ha un problema di integrita dei dati quandoil dato in ingresso ad un blocco cambia durante l’esecuzione di quelblocco. Questo problema puo essere causato dalla preemption.Consideriamo il seguente scenario:
– Un blocco piu veloce fornisce l’ingresso ad un blocco piu lento.
– Il blocco piu lento legge un valore di ingresso V1 dal blocco piuveloce e inizia i calcoli utilizzando quel valore.
– Durante i calcoli si ha preemption da parte di un’altra esecuzionedel blocco piu veloce che genera un nuovo valore di uscita V2.
– A questo punto avviene un problema di integrita dei dati: Quandoil blocco piu lento ritorna ad eseguire continua i suoi calcoli usandotuttavia il nuovo valore di input V2.
Questo tipo di trasferimento dati viene chiamato non protetto. Inun trasferimento dati protetto l’uscita V1 del blocco piu veloce vienemantenuta fino a che il blocco piu lento non finisce di eseguire.
• Determinismo: In un trasferimento dati deterministico la temporiz-zazione del trasferimento dati e completamente predicibile ed e deter-minata dal tempo di campionamento dei blocchi.La temporizzazione di un trasferimento dati non deterministico dipendedalla disponibilita dei dati, dai rates di campionamento dei blocchi edal tempo nel quale il blocco in ricezione comincia ad eseguire rispettoal blocco pilota.
20
Utilizzando il blocchetto Rate Transition e possibile assicurare che i trasferi-menti dati nella propria applicazione siano sia protetti che deterministici. Sequeste caratteristiche non sono desiderate e possibile tuttavia comprometterel’integrita dei dati e il determinismo in favore di una minore latenza.
2.7.2 Assunzioni sul Trasferimento Dati
Quando si processano dei trasferimenti di dati tra i blocchi del modello,Real-Time Workshop assume le seguenti cose:
• Le transizioni di dati avvengono tra un singolo processo in lettura e unsingolo processo in scrittura.
• La lettura o scrittura di una variabile di dimensione del byte e atomica.
• Quando due processi interagiscono tramite uno scambio di dati sola-mente uno di loro puo effettuare preemption sull’altro.
• Per i processi periodici, il processo con il rate piu veloce ha la prioritamaggiore rispetto al processo con il rate piu lento.
• Tutti i processi girano su di un singolo processore. Il time slicing none permesso.
• I processi non vanno in crash ne si riavviano.
2.7.3 Opzioni del Blocco Rate Transition
Molti parametri del blocco Rate transition sono rilevanti all’utilizzo durantela generazione di codice per l’esecuzione real-time. Questo blocco gestisce siatransizioni periodiche che asincrone. Quando viene inserito tra due blocchicon differenti rates di campionamento configura automaticamente i rates dicampionamento del suo ingresso e uscita per l’appropiato tipo di transizione.La decisione importante che viene fatta quando si configura il blocco RateTransition e la scelta del meccanismo di trasferimento dati. Questa sceltadipende da considerazioni sulla sicurezza, utilizzo di memoria e prestazioni.
Facendo riferimento alla figura 2.4 il meccanismo di trasferimento dati econtrollato da due opzioni:
• Ensure data integrity during data transfer: Quando questa opzionee attiva viene garantita l’integrita dei dati trasferiti. Se e disattivata iltrasferimento dati non e protetto.
21
Figura 2.4: Configurazione blocco Rate Transition
• Ensure deterministic data transfer (maximum delay): Questaopzione e supportata per processi periodici con offset zero e rates chesono multipli fra di loro. Quando questa opzione e attiva il blocco RateTransition si comporta come un blocco Zero-Order Hold nel caso ditransizione da veloce a lento o come un blocco Unit Delay nel casodi transizione da lento a veloce. Per le transizioni asincrone questaopzione non puo essere selezionata.
Il blocco Rate Transition offre dunque tre differenti modalita di operazioneper il trasferimento dati.
• Protetta e Deterministica: Questa e la modalita piu sicura ma intro-duce della latenza nel sistema. Per le transizioni da veloce a lentola latenza massima e un periodo di campionamento del processo piulento, per le transizioni da lento a veloce invece e di due periodi dicampionamento del processo piu lento.
• Protetta e Non Deterministica: In questa modalita le transizioni dalento a veloce vengono fatte tramite double-buffer, le transizioni da
22
veloce a lento usano invece un semaforo. La latenza massima in questocaso e minore uguale ad un periodo di campionamento del processo piuveloce.
• Non Protetta e Non Deterministica: In questa modalita e come se ilrate transition non ci fosse. La latenza e uguale a quella della modalitaprecedente ma il codice prodotto e molto inferiore.
2.7.4 Automatic Rate Transition
Simulink puo accorgersi di problemi di transizione dati in un modello mul-titasking ed inseririre automaticamente i blocchi Rate Transition per ge-stirli. Per far questo si deve abilitare l’opzione Automatically handledata transfers between tasks nel pannello Solver dei parametri di con-figurazione. In questo modo Simulink gestira tutte le transizioni tra tem-pi di campionamento periodici e processi asincroni, inserira blocchi RateTransition non visibili nel diagramma del modello e Real-Time Workshopgenerera codice per questi blocchi come se fossero stati inseriti manualmente.Questi blocchi operano nella modalita protetta e deterministica per i processiperiodici e solo protetta per i processi asincroni.
2.8 Utilizzo delle S-Functions
Le S-function aiutano a risolvere molte tipologie di problemi che sorgonolavorando con Simulink e Real-Time Workshop. Questi problemi includono
• L’estenzione dell’insieme di algoritmi forniti da Simulink e Real-TimeWorkshop
• Interfacciare il codice scritto a mano con Simulink e Real-Time Work-shop
• Interfacciarsi all’hardware tramite device driver
• Generare codice altamente ottimizzato per sistemi embedded
Le S-functions sono scritte attraverso una intefaccia di programazione delleapplicazioni(API) che permette di implementare algoritmi generici in Simulinkcon una grande flessibilita. Nello stesso tempo questa flessibilita viene ridot-ta quando si va ad utilizare Real-Time Workshop. Nonostante le S-functionsforniscano una soluzione flessibile e generica per l’implementazione di com-plessi algoritmi in Simulink l’API utilizzata genera overhead in termini di
23
memoria e risorse di calcolo. Nel caso di applicazioni su sistemi embed-ded real-time queste risorse addizionali generalmente non sono disponibili.Si possono pero diminuire i requisiti dell’applicazione utilizzando il TargetLanguage Compiler fornito con il Real-Time Workshop per rendere leS-function inlined.
2.8.1 Tipi di S-Function
L’implementazione delle S-function cambia in base ai propri requisiti. Cisono in generale delle situazioni comuni:
1. ‘Non mi interessa l’efficienza. Voglio scrivere una versione del mio al-goritmo che giri su Simulink e Real-Time Workshop automaticamente.’
2. ‘Ho un sacco di codice scritto a mano che devo interfacciare. Vogliopoterlo richiamare da Simulink e Real-Time Workshop in una manieraefficiente.’
3. ’Voglio implementare un algoritmo altamente ottimizzato che sembraun blocco built-in e genera un codice efficiente.’
Per ognuna di queste richieste c’e una specifica terminologia adottata inMatlab. Facendo riferimento alle situazioni si parlera rispettivamente di:
1. Noninlined S-function
2. Wrapper S-function
3. Fully inlined S-function
2.8.2 Noninlined S-Functions
Una noninlined S-function e un funzione MEX C o C++ che viene trattataallo stesso modo da Simulink e Real-Time Workshop. Sono richiesti calcoli ememoria aggiuntiva per ogni istanza del blocco noninlined S-function. Tut-tavia questo tipo di S-function e tipico durante la fase di prototipizzazionequando l’efficienza non e importante. Il vantaggio guadagnato a sfavore del-l’efficienza e l’abilita di cambiare i parametri del modello rapidamente.Scrivere noninlined S-function non richiede nussun codice TLC.
24
2.8.3 Wrapper S-Functions
Una wrapper S-function e ideale per interfacciare il codice scritto a mano oun grosso algoritmo incapsulato in diverse procedure. In questa situazione disolito le procedure risiedono in moduli separati dalla S-function. Il moduloS-function contiene delle chiamate alle proprie procedure. Poiche l’S-functioncontiene solo chiamate e nessun codice viene chiamata wrapper S-function.Oltre alla wrapper MEX S-function e necessario creare un TLC wrapper checomplementa la funzione. Il codice TLC rispecchia il codice dell’S-functionpresentando solamente chiamate di funzione.
2.8.4 Fully Inlined S-Functions
Per far lavorare correttamente le S-function in ambiente Simulink e neces-saria una certa quantita di codice di overhead. Quando Real-Time Workshopgenera codice da modelli che contegono S-function (senza file sfunction.tlc)inserisce questo codice di overhead nel codice generato. Quindi se si vuolottimizzare il proprio codice real-time e eliminare l’overhead si deve renderele S-function inlined. Questo richiede la scrittura di un file TLC che istruiscaReal-Time Workshop su quali ottimizzazioni fare. Il Target Language Com-piler processa i file sfunction.tlc per definire come inserire l’algoritmo dellaS-function nel codice generato.Una fully inlined S-function realizza il proprio algoritmo in Simulink e Real-Time Workshop in una maniera indistinguibile dai blocchi built-in. Scrivereuna tale S-function richiede quindi di implementare il proprio algoritmo duevolte: una volta per Simulink (C/C++ MEX S-function) e una volta perReal-Time Workshop (file TLC). La complessita del file TLC dipende dallacomplessita dell’algoritmo e dal livello di efficienza che si vuole ottenere.La scrittura di una fully inlined S-function puo richiedere il piazzamento del-la routine mdlRTW nei file MEX sfunction.c o sfunction.cpp. La routinemdlRTW permette di modificare l’informazione contenuta nel file model.rtwche contiene i record del modello. Questo file viene processato dal TargetLanguage Compiler prima di cominciare ad eseguire sfunction.tlc e generarecodice.Includere una routine mdlRTW e utile se si vuole passare parametri non-tunable al file TLC. Questi parametri sono generalmente utilizzati per de-terminare la modalita operativa del nostro algoritmo. Basandosi su questainformazione, il file TLC rispettivo puo generare codice altamente efficientee ottimizzato per la modalita operativa richiesta.
25
Nei prossimi paragrafi voglio mostrare come generare una semplice wrap-per S-function e i vantaggi che conseguono dal rendere tale S-function inlined.
2.8.5 MEX S-Function Wrapper
Creare S-function utilizzando un wrapper permette di inserire algoritmi C/C++in Simulink e Real-Time Workshop con pochi o addirittura nessun cambia-mento alle proprie funzioni C/C++ originali.Supponiamo di avere un algoritmo di nome my alg contenuto nel file my alg.c.E’ possibile integrare tale algoritmo in Simulink creando un MEX S-functionwrapper (ad esempio wrapsfcn.c). Dopo aver fatto questo Simulink puochiamare my alg da un blocco S-function. Nonostante questo la S-functionSimulink contiene un insieme di funzioni vuote richieste da Simulink per variscopi relativi all’API.E’ possibile poi integrare my alg nel codice generato dal Real-Time Work-shop creando una TLC wrapper S-function (wrapsfcn.tlc). Il vantaggio dicreare un wrapper TLC e che le chiamate di funzione vuote possono essereeliminate ed anche l’overhead dell’esecuzione della funzione mdlOutputs cheha l’unico compito di chiamare la funzione my alg.Utilizzare una wrapper S-function per importare algoritmi nel proprio model-lo Simulink significa che l’S-function funziona come un interfaccia che chiamagli algoritmi C/C++ da mdlOutputs.Vediamo ora un semplice esempio di una wrapper S-function:
// File wrapsfcn.c
#define S_FUNCTION_NAME wrapsfcn
#define S_FUNCTION_LEVEL 2
#include "simstruc.h"
extern real_T my_alg(real_T u); /* Dichiaro my_alg come extern */
/*
* mdlInitializeSizes - initializzo le dimensioni degli array
*/
static void mdlInitializeSizes(SimStruct *S)
{
ssSetNumSFcnParams( S, 0); /*numero di argomenti in ingresso*/
if (!ssSetNumInputPorts(S, 1)) return;
ssSetInputPortWidth(S, 0, 1);
26
ssSetInputPortDirectFeedThrough(S, 0, 1);
if (!ssSetNumOutputPorts(S,1)) return;
ssSetOutputPortWidth(S, 0, 1);
ssSetNumSampleTimes( S, 1);
}
/*
* mdlInitializeSampleTimes - questa impostazione indica che il tempo
* di campionamento e derivato dal blocco pilota
*/
static void mdlInitializeSampleTimes(SimStruct *S)
{
ssSetSampleTime(S, 0, INHERITED_SAMPLE_TIME);
ssSetOffsetTime(S, 0, 0.0);
}
/*
* mdlOutputs - calcola l’uscita chiamando my_alg
*/
static void mdlOutputs(SimStruct *S, int_T tid)
{
InputRealPtrsType uPtrs = ssGetInputPortRealSignalPtrs(S,0);
real_T *y = ssGetOutputPortRealSignal(S,0);
*y = my_alg(*uPtrs[0]); /* chiamo my_alg in mdlOutputs */
}
/*
* mdlTerminate - funzione chiamata quando termina il programma.
*/
static void mdlTerminate(SimStruct *S)
{
}
#ifdef MATLAB_MEX_FILE /* e un MEX-file? */
#include "simulink.c" /* meccanismo di interfaccia MEX-file */
#else
#include "cg_sfun.h" /* funzione della generazione di codice */
#endif
27
La routine mdlOutputs dell’S-function contiene una chiamata di funzione amy alg che e la funzione C che contiene l’algoritmo da eseguire. Questo einvece il codice di esempio per my alg.c:
#ifdef MATLAB_MEX_FILE
#include "tmwtypes.h"
#else
#include "rtwtypes.h"
#endif
real_T my_alg(real_T u)
{
return(u * 2.0);
}
La wrapper S-function wrapsfcn chiama my alg che calcola u ∗ 2.0.
2.8.6 TLC S-Function Wrapper
Nell’esempio precedente la chiamata a my alg e inserita nella sezione md-lOutputs come
*y = my_alg(*uPtrs[0]);
Quando si va a creare una TLC wrapper S-function si ha come obbiettivoil far inserire al Real-Time Workshop la stesso tipo di chiamata nel codicegenerato.Il codice generato quando si usa grt.tlc come system target file senza wraps-fcn.tlc e il seguente:
#include <math.h>
#include <string.h>
#include "wrapper.h"
#include "wrapper.prm"
/* Start the model */
void mdlStart(void)
{
/* (no start code required) */
}
28
/* Compute block outputs */
void mdlOutputs(int_T tid)
{
/* Level2 S-Function Block: <Root>/S-Function (wrapsfcn) */
{
/* Le S-functions noninlined creano un oggetto SimStruct e
* generano una chiamata alla routine mdlOutputs dell’S-function
*/
SimStruct *rts = ssGetSFunction(rtS, 0);
sfcnOutputs(rts, tid);
}
/* Outport Block: <Root>/Out */
rtY.Out = rtB.S_Function;
}
/* Perform model update */
void mdlUpdate(int_T tid)
{
/* (no update code required) */
}
/* Terminate function */
void mdlTerminate(void)
{
/* Level2 S-Function Block: <Root>/S-Function (wrapsfcn) */
{
/* Le S-functions noninlined richieddono un oggetto SimStruct e
* la chiamata alla routine mdlTerminate dell’S-function
*/
SimStruct *rts = ssGetSFunction(rtS, 0);
sfcnTerminate(rts);
}
}
#include "wrapper.reg"
/* [EOF] wrapper.c */
In aggiunta all’overhead illustrato sopra il file generato wrapper.reg contienel’inizializzazione della SimStruct per il blocco wrapper S-function.E’ possibile ridurre significativamente questo overhead creando un wrapper
29
TLC per l’S-function.Il codice generato effettua la chiamata alla S-function (wrapsfcn.c) in md-lOutputs attraverso questo codice:
SimStruct *rts = ssGetSFunction(rtS, 0);
sfcnOutputs(rts, tid);
Questa chiamata ha dell’overhead computazionale: Simulink crea una strut-tura SimStruct per il blocco, Real-Time Workshop costruisce una chiamataattraverso un puntatore di funzione per eseguire mdlOutputs e infine md-lOutputs chiama my alg.Utilizzando un file wrapsfcn.tlc e possibile eumentare l’efficienza e ridurrela dimensione del codice generato. Il codice seguente mostra come fare ilwrapper TLC per piazzare la chiamata di funzione nel codice generato.
%% File : wrapsfcn.tlc
%implements "wrapsfcn" "C"
%% Function: BlockTypeSetup
%function BlockTypeSetup(block, system) void
%openfile buffer
extern real_T my_alg(real_T u); /* questa linea viene messa in
wrapper.h */
%closefile buffer
%<LibCacheFunctionPrototype(buffer)>
%endfunction %% BlockTypeSetup
%% Function: Outputs
%function Outputs(block, system) Output
/* %<Type> Block: %<Name> */
%assign u = LibBlockInputSignal(0, "", "", 0)
%assign y = LibBlockOutputSignal(0, "", "", 0)
%% la linea seguente e espansa e messa in mdlOutputs
%% all’interno di wrapper.c
%<y> = my_alg(%<u>);
%endfunction %% Outputs
La prima sezione di questo codice dice a Real-Time Workshop di lavoraresulla wrapsfcn S-function e di generare codice in C:
30
%implements "wrapsfcn" "C"
Il compito successivo e quello di istruire Real-Time Workshop che la rou-tine my alg deve essere dichiarata extern nel file generato wrapper.h. Poichequesta operazione va fatta una sola volta per ogni blocco wrapsfcn S-functionviene utilizzata la funzione BlockTypeSetup. In questa funzione si dice alTarget Language Compiler di creare un buffer e di inserire il buffer che con-tiene la dichiarazione di my alg come extern all’interno del file di intestazionegenerato wrapper.h.Il passo finale e di inserire la chiamata alla funzione my alg. Questo vienefatto nella funzione Outputs. In questa funzione si accede all’ingresso e us-cita del blocco e si piazza una chiamata diretta a my alg che verra inseritain wrapper.c.Il codice generato utilizzando il wrapper TLC e simile al codice generato didefault ma la funzione mdlTerminate non contiene piu una chiamata ad unafunzione vuota e mdlOutputs chiama direttamente my alg.
void mdlOutputs(int_T tid)
{
/* S-Function Block: <Root>/S-Function */
rtB.S_Function = my_alg(rtB.U); /* chiamata a my_alg inserita
nel codice */
/* Outport Block: <Root>/Out */
rtY.Out = rtB.S_Function;
}
Oltre a questo wrapper.reg non crea piu una SimStruct figlia per la S-functionil che fa risparmiare piu di 1 K di memoria.
2.8.7 Fully Inlined S-Functions
Continuando l’esempio della sezione precedente e possibile eliminare comple-tamente la chiamata a my alg specificando il codice esplicito (in questo caso2.0 ∗ u) all’interno di wrapsfcn.tlc. Questo rende l’S-function fully inlined.Per rendere inlined l’algoritmo dell’esempio basta sostituire nella sezioneOutputs del file wrapsfcn.tlc
%<y> = my_alg(%<u>);
con
%<y> = 2.0 * %<u>;
Questo e il codice prodotto in mdlOutputs:
31
void mdlOutputs(int_T tid)
{
/* S-Function Block: <Root>/S-Function */
rtB.S_Function = 2.0 * rtB.U; /* inserzione esplicita
dell’algoritmo */
/* Outport Block: <Root>/Out */
rtY.Out = rtB.S_Function;
}
Il Target Language Compiler ha rimpiazzato la chiamata a my alg con l’al-goritmo stesso.
2.9 Utilizzo di Blocchi Asincroni di Interruzione
in Simulazione e Generazione del Codice
Questa sezione descrive un approccio a doppio-modello allo sviluppo ed im-plementazione dei sistemi real-time che includono ISR. In Questa metodolo-gia si sviluppa un modello che include l’impianto ed il controllore per lasimulazione e un’altro modello che include solamente il controllore per lagenerazione del codice. Utilizzando una libreria Simulink si possono poi im-plementare cambiamenti su entrambi i modelli simultaneamente.La figura 2.5 mostra questo tipo di approccio e come le modifiche fatte nellalibreria si propaghino ai modelli. E’ possibile anche un approccio a modello
Figura 2.5: Approccio a doppio-modello
32
singolo dove la componente dell’impianto e attiva solamente in simulazione.Durante la generazione di codice la componente dell’impianto e effettiva-mente tagliata fuori dal sistema e il codice viene generato solo per il bloccodi interruzione e la parte di controllo del modello.
2.9.1 Rate Transitions e Blocchi Asincroni
Poiche una chiamata di funzione asincrona puo fare preemption o essereprelazionata da altro codice del modello si ha una inconsistenza quando piudi elemento di un segnale e collegato ad un blocco asincrono. Il problemae che il segnale puo essere in processo di essere scritto o letto quando si hala preemption ottenendo qualche dato vecchio e qualche dato nuovo. Questasituazione puo avvenire anche nel caso di un segnale scalare a volte. Peresempio se il segnale e un double le operazioni di lettura e scrittura potreb-bero richiedere due istruzioni di macchina.I problemi che riguardano la preemption possono essere risolti dal bloccoSimulink Rate Transition come spiegato precedentemente. Tale blocco tut-tavia non puo essere usato per garantire il determinismo per i blocchi asin-croni.Simulink non assegna le priorita ai blocchi asincroni per cui quando si creanoblocchi di questo tipo deve essere possibile specificare un livello di priorita.
33
Capitolo 3
Real Time WorkshopEmbedded Coder
Real-Time Workshop Embedded Coder e un prodotto che si aggiunge al Real-Time Workshop ed e utilizzato per lo sviluppo di sistemi embedded.Il Real-Time Workshop fornisce una struttra di lavoro per lo sviluppo dicodice che e ottimizzata per quanto riguarda la velocita, l’utilizzo di memoriae la semplicita. Genera codice ottimizzato in ANSI o ISO C per micropro-cessori a virgola fissa e a virgola mobile.Estende dunque le capacita del Real-Time Workshop per la produzione e iltesting di applicazioni su embedded targets. Il target Embedded Real-Time(ERT) fornito con il Real-Time Workshop e progettato per essere personaliz-zato. E’ una buona base di partenza per sviluppare codice per un particolaremicroprocessore e interfacciarsi ad un sistema di cross-development.In aggiunta alle caratteristiche supportate dal Real-Time Workshop , l’Em-bedded Coder fornisce diverse altre feature tra le quali :
• Genera codice ANSI/ISO C o C++ ed eseguibili a partire da mod-elli Simulink e Stateflow con un’utilizzo di memoria, una velocita diesecuzione e una leggibilita paragonabile al codice scritto a mano.
• Estende Real-Time Workshop e Stateflow Coder con configurazioni delcodice e ottimizzazioni essenziali per una produzione commerciale
• Partiziona in maniera concisa il codice multirate per uno schedulingefficiente con o senza l’ausilio di un sistema operativo real-time (RTOS).
• Fornisce un ricco insieme di possibilita di commento per seguire nelcodice le varie componenti del modello e le richieste.
34
• Fornisce un Model Advisor che controlla la configurazione del modelloe suggerisce consigli per l’ottimizzazione del codice.
• Fornisce una strategia chiamata rate grouping per i modelli multi-ratemultitasking che genera funzioni separate per il processo con rate dibase e i processi con sub-rate nel modello.
• Fornisce la capacita di verificare il codice prodotto permettendo di im-portare il codice nuovamente in Simulink tramite una S-function perun test di tipo software-in-the-loop con un modello di impianto.
• Documenta il codice generato in un report HTML che descrive i mod-uli del codice e le impostazioni di configurazione applicate in fase digenerazione del codice.
3.1 Stuttura Dati del Modello Real-Time
Real-Time Workshop Embedded Coder inserisce le informazioni del modelloradice nella struttura dati rtModel del modello real-time.Per ridurre le richieste di memoria rtModel contiene esclusivamente le infor-mazioni richieste dal modello. Di default rtModel contiene un campo errorstatus per monitorare il codice. Se non utilizzato questo campo puo essererimosso per ridurre l’utilizzo di memoria.Le definizioni dei simboli per rtModel nel codice generato sono le seguenti:
• Definizione di struttura (in model.h):
struct _RT_MODEL_model_Tag {
...
};
• Dichiarazione typedef (in model types.h):
typedef struct _RT_MODEL_model_Tag RT_MODEL_model;
• Dichiarazioni di puntatori e variabili (in model.c o .cpp):
RT_MODEL_model model_M;
RT_MODEL_model *model_M = &model_M_;
• Dichiarazione di variabile esportata (in model.h):
extern RT_MODEL_model *model_M;
35
3.2 Esecuzione di Programmi Stand-Alone
Di default Real-Time Workshop Embedded Coder genera programmi stand-alone che non richiedono sistemi operativi real-time esterni. Un progammastand-alone richiede qualche minima modifica per essere adattato all’hard-ware di interesse. L’architettura di programma supporta l’esecuzione di mod-elli con uno o piu rates di campionamento.Il nucleo di un programma stand-alone e il ciclo main. Ad ogni iterazione ilciclo main esegue un processo di background o un processo vuoto e controllache si verifichi la condizione di terminazione.Il ciclo main e interrotto periodicamente da un timer. La funzione Real-TimeWorkshop rt OneStep o e installata come interrupt service routine (ISR) deltimer o e chiamata da una ISR del timer ad ogni passo di clock.L’attivita di rt OneStep differisce in base al modello generato. In un modellosingle-rate rt OneStep chiama semplicemente la funzione model step. In unmodello multi-rate rt OneStep assegna priorita e schedula l’esecuzione deiblocchi in accordo al loro rate di esecuzione.Real-Time Workshop Embedded Coder genera codice molto differente neimodelli multi-rate a seconda dei seguenti fattori:
• Nel caso in cui il modello esegua in modalita singletasking oppuremultitasking.
• Nel caso in cui venga generato oppure no codice riutilizzabile.
Questi fattori si ripercuotono sull’algoritmo di scheduling utilizzato nel codicegenerato.
3.3 Programma Main
Lo pseudocodice seguente mostra l’esecuzione di un programma main delReal-Time Workshop Embedded Coder.
main()
{
Inizializzazione (include l’installazione di rt_OneStep come
interrupt service routine per un clock real-time)
Inizializza e avvia timer hardware
Attiva interrupts
While(not Error) and (time < final time)
Background task
EndWhile
36
Disattiva interrupts (Disattiva rt_OneStep)
Completa tutti i background tasks
Shutdown
}
Lo pseudocodice e una guida per un programma tipo che serve a pilotare ilproprio modello. Naturalmente il file ert main.c o .cpp deve essere modificatoin accordo alle proprie specifiche.
3.4 rt OneStep
Le operazioni di rt OneStep differiscono se il modello e single-rate o multi-rate e in base alla modalita del solutore(SingleTasking o MultiTasking).
3.4.1 Single-Rate Singletasking
L’unica modalita del solutore valida per un modello single-rate e SingleTask-ing.Lo pseudocodice seguente mostra il design di rt OneStep in un programmasingle-rate.
rt_OneStep()
{
Controlla overflow dell’Interrupt o altri errori
Attiva "rt_OneStep" (timer) interrupt
Model_Step() -- Passo temporale con output,logging,update
}
Per il caso single-rate rt OneStep e progettata per eseguire model step all’in-terno di un singolo periodo di clock. Per assicurare questa temporizzazionert OneStep mantiene e controlla un flag di timer overrun.All’inizio le interruzioni sono disabilitate fino a che non e stato controllatoil flag di overrun e le altre condizioni di errore. Se il flag e clear rt OneSteplo setta e procede con gli interrupt del timer attivati. Il flag viene poi pulitosolamente in seguito ad un ritorno con successo da model step.Quindi se rt OneStep e riinterrotto prima di aver completato model stepla nuova interruzione viene scoperta attraverso il flag di overrun. Questae una condizione di errore che puo essere gestita a piacimento. Di defaultrt OneStep segnala un errore e ritorna immediatamente.
37
3.4.2 Multi-Rate Multitasking
Il seguente pseudocodice mostra il design di rt OneStep in un programmamultitasking multi-rate.
rt_OneStep()
{
Controlla base-rate interrupt overrun
Attiva "rt_OneStep" interrupt
Determina quali rates devono eseguire in questo passo
Model_Step0() -- esegui codice con il passo base-rate
For N=1:NumTasks-1 -- itera i sub-rate tasks
If (sub-rate task N e schedulato)
Controlla sub-rate interrupt overrun
Model_StepN() -- esegui codice passo sub-rate
EndIf
EndFor
}
L’esecuzione di blocchi aventi differenti rates di campionamento e divisa inpiu processi. Ad ogni blocco che esegue ad un certo rate di campionamentoviene assegnato un identificatore di processo (tid) che lo associa con un taskche esegue a quel rate.Ai processi vengono assegnate le priorita in ordine decrescente con il rate. Ilprocesso con il rate base e il processo che esegue piu velocemente nel sistemae gli viene assegnata la piu alta priorita (tid 0). Il processo piu lento avra diconseguenza la priorita piu bassa (tid NumTasks-1).
3.4.3 Rate Grouping
In un modello single-rate tutti i calcoli dei valori di uscita dai blocchi sonoeffettuati in una funzione sola, model step. Nel caso di modelli multi-ratemultitasking Real Time Workshop adotta un’altra strategia chiamata RateGrouping. Questa genera funzioni model step separate per il rate base eciascun processo sub-rate nel modello. La convenzione per la nomenclaturadi queste funzione e model stepN dove N e l’identificatore del processo.Ciascuna funzione model stepN esegue tutti i blocchi che condividono il tidN.Ad ogni tick del clock rt OneStep e model step0 gestiscono i contatori dellaschedulazione e i flag di evento per ogni processo sub-rate. I contatori ven-gono implementati nei campi Timing.TaskCounters.TIDn di rtModel, i flagdi evento sono invece implementati come array indicizzati dal tid. I contatori
38
della schedulazione sono gestiti dalla funzione rate monotonic scheduler cheviene chiamata da model step0. I contatori sono in effetti divisori del clockrate che contano fino al periodo di campionamento associato con ciascun pro-cesso sub-rate.I flag di evento indicano se un determinato processo e schedulato per l’ese-cuzione. rt OneStep gestisce i flag di evento con la funzione model SetEventsFor-ThisBaseStep. Quando un contatore indica che il tempo di campionamentodi un processo e passato model SetEventsForThisBaseStep imposta il flag dievento per quel processo.Ad ogni invocazione rt OneStep aggiorna la struttura dati del suo schedu-latore e esegue un passo del processo base-rate. Successivamente itera tra iflag dello schedulatore in ordine di tid chiamando incondizionatamente mod-el stepN per ogni task il cui flag e impostato. Questo assicura che i processisono eseguiti in ordine di priorita.Naturalmente le interruzioni devono essere disabilitate prima della chiamataa rt OneStep. L’array dei flag di evento e le variabili di loop usate sonosalvate come variabili locali nello stack cosı da assicurare che il codice siarientrante.L’ rt OneStep per modelli multi-rate gestisce anche un array di flag per iltimer overrun. La logica con cui si controlla l’overrun di ogni singolo processoe la stessa usata per i modelli single-rate.
3.4.4 Multi-Rate Singletasking
In un programma multi-rate singletasking tutti i tempi di campionamen-to nel modello devono essere multipli interi della dimensione del passo fissodel modello. Il funzionamento di rt OneStep in questo caso e una versionesemplificata di quella multi-rate multitasking. Il Rate Grouping non e utiliz-zato. L’unico processo e il processo base-rate quindi viene generata una solafunzione model step:
void model_step(int_T tid)
Ad ogni tick del clock rt OneStep controlla i flag di overrun e chiama mod-el step passando come argomento tid 0. La funzione di scheduling per un pro-gramma multi-rate singletasking e rate scheduler. Lo schedulatore gestisce icontatori di schedulazione ad ogni tick del clock. I contatori sono implemen-tati in un array indicizzato da tid ovvero per ogni rate di campionamento c’eun contatore e l’array e contenuto nella struttura Timing dentro rtModel.Anche in questo caso i contatori si comportano da divisori del rate del clocke contano fino ai periodi di campionamento associati ai processi sub-rate.Quando un contatore raggiunge il periodo di un dato rate rate scheduler
39
azzera il contatore. Questa condizione indica che tutti i blocchi che girano aquel rate devono essere eseguiti nella prossima chiamata a model step. mod-el step e responsabile per il controllo dei contatori.
3.5 Linee Guida per la modifica di rt OneStep
rt OneStep non richiede una modifica estensiva. Le uniche modifiche richiestesono le riattivazioni delle interruzioni dopo che si sono controllati i flag dioverrun e le condizioni di errore. Se possibile si dovrebbe anche
• Salvare e ripristinare il contenuto della FPU in ingresso e uscita dart OneStep.
• Impostare gli ingressi del modello associati con il rate base prima dichiamare model step0.
• Acquisire le uscite del modello associate al rate base dopo la chiamataa model step0.
• Se il modello e multi-rate multitasking ripetere le ultime due procedureper ogni sub-rate e rispettiva chiamata model stepN.
I commenti generati in rt OneStep mostrano le posizioni appropiate per ag-giungere il proprio codice.Volendo e possibile gestire differentemente il comportamento in caso di er-rore di overrun. Le strutture dati ed il funzionamento logico dei contatorie flag non possono pero essere modificati perche sono critici per il corret-to funzionamento di qualsiasi programma Real-Time Workshop EmbeddedCoder.
40
Capitolo 4
Ottimizzazioni fixed-point
Questo capitolo fornisce alcuni consigli per lo sviluppo di modelli fixed-pointe la generazione di codice da tali modelli.Seguendo questi consigli e possibile ridurre le richieste di ROM, RAM, tempodi esecuzione del codice generato e aumentare l’accuratezza dei risultati nelleoperazioni a virgola fissa.
4.1 Rappresentazione fixed-point
La rappresentazione fixed-point permette di esprimere un numero reale comeun intero specificando la sua lunghezza (in bits) e la locazione del suo pun-to binario. La figura 4.1 mostra la rappresentazione del numero 6.5 nellanotazione fixed-point in un tipi di dati ad otto bit.
Convertire un numero decimale in un suo equivalente fixed-point e moltosemplice:
• La parte intera del numero fixed-point e l’equivalente binario della parteintera del numero decimale. Nell’esempio 6 viene convertito in 110.
• La parte frazionaria del numero fixed-point e l’equivalente binario dellafrazione decimale divisa per la risoluzione. La risoluzione e 2−E doveE e il numero di bit alla destra del punto binario. Nell’esempio larisoluzione e 2−4 = 0.0625. Quindi la parte frazionaria del numerofixed-point sara 0.5/0.0625 = 8 che in binario diventa 1000.
La frazione determina la risoluzione che e il piu piccolo valore diverso da zeroche il numero fixed-point puo rappresentare. La parte intera invece determinail range di valori del numero fixed-point. Quindi cambiare la locazione del
41
Figura 4.1: Rappresentazione fixed-point
punto binario in un numero fixed-point causa un tradeoff tra il range di valoriassumibili e la risoluzione.Termini addizionali nel contesto fixed-point sono lo scaling , il bias e lo slope.Lo slope ed il bias insieme formano lo scaling di un numero fixed-point. Lalocazione del punto binario cambia lo scaling. Quindi possiamo scrivere V=S*Q + B dove Q e il valore fixed-point quantizzato, V e il valore reale, S elo slope, B e il bias.Si deve dunque scegliere uno slope ed un bias tali che il valore quantizzatoQ sia correlato al valore reale V con un range e una risoluzione ragionevoliper l’applicazione.E’ altresı importante scegliere un buon metodo di arrotondamento. Quando ilmicrocontrollore converte un numero fixed-point da una risoluzione maggioread una inferiore si devono trattare i bit in esubero. Se il microcontrollorescarta questi bit extra la conversione puo risultare imprecisa. Questo e quelloche succede se si scegliere il metodo di arrotondamento floor. Tuttavia questometodo e il piu semplice, il piu comune ed il piu efficiente dei metodi diarrotondamento.Alternativamente e possibile scegliere altri metodi di arrotondamento perconservare i bit extra per l’accuratezza. Simulink a tal proposito supportaquattro metodi di arrotondamento: Floor, ceiling, zero e nearest.Ci possono essere situazioni dove sia importante gestire bene il possibileoverflow del valore quantizzato. Per questo simulink fornisce due metodi di
42
gestione dell’overflow: Wrap e saturate. L’overflow avviene quando il numeroche deve essere salvato come risultato di una operazione matematica supera ilnumero di bit che il tipo dati del risultato puo contenere. Il metodo saturatedeve essere utilizzato solo nel caso in cui sia essenziale per la sicurezza poicheaumenta l’uso della ROM e il tempo di esecuzione.
Per ciascuna uscita dei blocchi nel modello e possibile specificare la lunghez-za della parola e la locazione del punto binario. In base al tipo di operazionimatematiche eseguite su uno o piu numeri fixed-point il risultato potrebberichiedere una lunghezza di parola maggiore. Per prima cosa e necessariosimulare il modello cercando le uscite che approssimano nel miglior modo ivalori ottenuti da una simulazione floating point dello stesso modello. Unascelta inappropiata del range e della risoluzione puo fornire un risultato in-accurato e aumentare la dimensione del codice. Nel caso peggiore si possonoanche ottenere risultati errati a causa di underflow e overflow.
Quando si sceglie un tipo di dati si deve tenere in considerazione il rangenumerico, la risoluzione, l’errore di quantizzazione e un metodo per gestirele condizioni aritmetiche eccezionali. La scelta dipende dalle richieste dellapropria specifica applicazione ( accuratezza , tempo di risposta) , dal proprioembedded target (dimensione di parola, velocita del processore, etc..) e daaltri fattori.
E’ piuttosto semplice specificare tipi di valori fixed-point all’interno diSimulink e di Stateflow. Entrambi supportano due metodi di scaling: Apunto binario e [Slope Bias]. Le figure 4.2 e 4.3 mostrano come impostaretali valori.
Se si vuole progettare il proprio modello per ridurre il consumo di RAM,di ROM e il tempo di esecuzione richiesto per eseguire il codice genera-
43
Figura 4.2: Simulink fixed-point
Figura 4.3: Stateflow fixed-point
to dal modello da Real-Time Workshop Embedded Coder ci sono numerosiaccorgimenti da prendere. Tra questi:
1. Utilizzare tipi di dati base per conservare RAM e ROM e tempo diesecuzione
2. Minimizzare il numero di tipi di dati che non combaciano (ROM , tempodi esecuzione)
3. Minimizzare il numero di scaling che non combaciano (ROM , tempodi esecuzione)
4. Evitare di utilizzare lo scaling fixed-point con bias (ROM, tempo diesecuzione)
5. Arrotondare con floor e non saturare se possibile (ROM, tempo diesecuzione)
44
6. Ottimizzare l’ordine delle operazioni di divisione e moltiplicazione dan-do come primo ingresso l’ingresso di moltiplicazione al blocco apposito(ROM, tempo di esecuzione)
7. Limitare l’utilizzo di tabelle di lookup spaziate irregolarmente (RAM,ROM, tempo di esecuzione)
8. Utilizzare sottosistemi riutilizzabili (ROM vs RAM)
9. Utilizzare l’operatore ’C’ in Stateflow (ROM, tempo di esecuzione)
10. Attivare l’opzione Real-Time Workshop Embedded Coder Local blockoutputs (RAM)
11. Attivare l’opzione Real-Time Workshop Embedded Coder Parameterinlining (RAM)
Se invece il nostro interesse e quello di preservare l’accuratezza ci dovremocomportare diversamente.
45
Capitolo 5
Impostazioni Real TimeWorkshop
Passiamo adesso a vedere le opzioni di compilazione usate in Real TimeWorkshop per la generazione del codice.Per accedere alle finestre di configurazione di Real Time Workshop dobbiamoselezionare sul file modello Simulink Simulation - Configuration Param-eters , si aprira dunque una finestra con tutta una serie di opzioni: mostrerole opzioni di interesse per la generazione di codice embedded ottimizzato.
In figura e mostrato il pannello Solver. Dobbiamo tener conto che il codicedovra eseguire su di un microcontrollore per cui e importante impostare trale opzioni come Type Fixed-Step e come Solver un solutore discreto.Il secondo pannello di configurazione importante e il pannello di ottimiz-zazione del codice Optimization per cui mi soffermero sul significato dialcune impostazioni.
5.1 Block Reduction Optimization
Quando viene attivata questa impostazione Simulink riduce certi gruppi diblocchi in un singolo blocco piu efficente e li rimuove completamente. Questogarantisce una esecuzione del modello piu veloce durante la simulazione e nelcodice generato. L’aspetto del modello Simulink non cambia. I blocchi percui e possibile questa ottimizzazione sono di tre tipologie.
• Accumulator Folding. Simulink riconosce determinate strutture comeaccumulatori e le riduce ad un singolo blocco.
46
• Rimozione di Conversioni di Tipo Ridondanti. Blocchi di con-versione di tipo non necessari sono rimossi. Per esempio un blocco diconversione di tipo int con ingresso e uscita di tipo int e ridondante eviene rimosso.
• Dead Code Elimination. Tutti i blocchi o segnali in un percorsodi codice non utilizzato sono eliminati. (nota: perche un blocco siaconsiderato parte di un percorso di codice non utilizzato deve rispettaredeterminate condizioni).
5.2 Conditional Input Branch Execution
Questa ottimizzazione taglia fuori il codice non necessario generato da unflusso in ingresso ad un blocco Switch. Quando questa opzione e attiva, invecedi eseguire ad ogni passo temporale tutti i blocchi che pilotano le porte diingresso del blocco Switch, vengono eseguiti solamente i blocchi che servonoa calcolare l’ingresso di controllo e l’ingresso dati selezionato dall”ingresso dicontrollo.
47
5.3 Implement Logic Signals as Boolean Data
Simulink e impostato per non segnalare un errore quando un segnale di tipodouble va a pilotare un blocco con ingresso booleano. Questo e stato fattoper mantenere la compatibilita con precedenti versioni di Simulink che sup-portavano solo i tipi double. Spuntando questa opzione invece si seleziona uncontrollo rigido sul tipo booleano. Questa opzione e raccomandata : il codicegenerato richiede meno memoria in quanto un segnale booleano e tipicamentedi un byte mentre un segnale double richiede otto bytes di memoria.
5.4 Signal Storage Reuse
Questa opzione istruisce Real Time Workshop a riutilizzare la memoria deisegnali. Questo fa diminuire le richieste di memoria del programma real-time.Disattivare questa opzione rende tutte le uscite dei blocchi globali e unicheche in molti casi accresce significativamente l’utilizzo di RAM e ROM.
48
5.5 Inline Parameters
Selezionare questa opzione ha due effetti:
• Real-Time Workshop utilizza nel codice generato il valore numerico deiparametri del modello anziche il loro nome simbolico. Se il valore di unparametro e una variabile del workspace o una espressione contenenteuna o piu variabili dello spazio di lavoro, la variabile o l’espressionesono valutati al tempo di generazione del codice. Un parametro inlinedviene in effetti trasformato in una costante e non e piu visibile dalcodice scritto esternamente ne e piu modificabile a run-time.
• Il pulsante Configure viene attivato. Cliccando su questo pulsante siapre il dialog box Model Parameter Configuration. Questo dia-log pemette di rimuovere parametri individuali dall’essere inlined e didichiararli tunable o costanti globali. Diachiarare un parametro tun-able fa generare al Real-Time Workshop una dichiarazione di memo-ria che permettera di interfacciare il parametro con codice esterno.Questo permette inoltre al codice di modificare il valore del parametroa run-time.
L’opzione Inline Parameters istruisce anche Simulink a propagare i tempidi campionamento costanti. Simulink calcola il segnale di uscita dei blocchicon tempo di campionamento costante una volta durante l’avviamento delmodello. Questo migliora le prestazioni perche questi blocchi non devonocalcolare le loro uscite ad ogni passo del modello.Quando il parametro Inline parameters e attivo e possibile anche attivarel’opzione Inline invariant signals che inserisce anch’esso valori costantinel codice.
5.6 Application Lifespan
Il campo Application lifespan permette di specificare per quanto tempo unaapplicazione che dipende dal tempo trascorso puo eseguire prima che si abbiaoverflow del timer. Questa impostazione determina dunque la dimensione inbytes usate dai timers nel codice generato e permette di diminuire l’utilizzodella RAM. Utilizzare 64 bits per memorizzare i dati temporali permette amodelli con un passo di 0.001 microsecondi di eseguire per piu di 500 anni,cosa che difficilmente e richiesta. Per eseguire un modello con dimensionedel passo di un millisecondo per un giorno e richiesto un timer a 32-bit ( epuo continuare ad eseguire per 49 giorni).
49
5.7 Enable Local Block Outputs
Quando questa opzione viene attivata i segnali dei blocchi sono dichiarati lo-calmente nelle funzioni invece di essere dichiarati globalmente quando questoe possibile.E’ possibile attivare questa opzione solo quando viene attivata l’0pzioneSignal Storage Reuse.
5.8 Reuse Block Outputs
Quando questo check box e selezionato Real-Time Workshop riutilizza lamemoria dei segnali quando possibile. Se disattivato i segnali vengono salvatiin locazioni uniche. Anche questa opzione e selezionabile solo se e attival’opzione Signal Storage Reuse.
5.9 Ignore Integer Downcasts in Folded Ex-
pressions
Questa opzione specifica come Real-Time Workshop debba gestire le oper-azioni a 8-bit sui microprocessori a 16-bit e le operazioni a 8 e 16 bit neimicroprocessori a 32-bit. Per assicurare la consistenza tra simulazione e gen-erazione di codice i risultati delle espressioni intere a 8 e 16 bit devono essereesplicitamente castate su 8 o 16 bit. Questa opzione migliora l’efficienza delcodice eliminando le variabili intermedie.
5.10 Inline Invariant Signals
Un segnale invariante e un segnale di uscita da un blocco che non cambiadurante la simulazione Simulink. Con questa opzione ci si assicura che talesegnale sia inlined.
5.11 Eliminate Superfluous Temporary Vari-
ables (Expression Folding)
Questa opzione attiva l’Expression Folding. L’expression folding e una tecni-ca di ottimizzazione del codice che minimizza il calcolo dei risultati intermediin uscita dai blocchi e il salvataggio di questi risultati in buffers o variabili
50
temporanee. Quando questa opzione e attiva Real-Time Workshop riuniscei calcoli dei blocchi in una singola espressione invece di generare espressioniseparate e dichiarazioni di memoria per ogni blocco del modello.Questa riduzione puo aumentare notevolmente l’efficienza del codice gener-ato generando codice molto simile al codice scritto a mano. In molti casiinteri gruppi di calcolo vengono ridotti in una linea di codice altamente ot-timizzata. Molti blocchi Simulink supportano l’expression folding.Un semplice esempio di come l’expression folding modifica il codice generatoda un modello e il seguente.
Con l’expression folding attivato questo modello genera una singola linea dicalcoli per l’uscita come mostrato nella funzione di uscita.
static void exprfld_output(int_T tid)
{
/* local block i/o variables */
/* Outport: ’<Root>/Out1’ incorporates:
* Gain: ’<Root>/k1’
* Gain: ’<Root>/k2’
* Product: ’<Root>/Product’
*/
exprfld_Y.Out1 = exprfld_U.i1 * exprfld_P.k1_Gain *
(exprfld_U.i2 * exprfld_P.k2_Gain);
}
I commenti generati indicano i calcoli dei blocchi che sono stati combinatiin una singola espressione. I commenti documentano anche i parametri deiblocchi che appaiono nell’espressione.
51
Se l’expression folding e disattivata lo stesso modello calcola i risultati tempo-ranei sia dei guadagni dei blocchi che dei valori dei prodotti prima dell’uscitafinale come mostrato nel codice seguente.
static void exprfld_output(int_T tid)
{
/* local block i/o variables */
real_T rtb_k2_i;
real_T rtb_Product_i;
/* Gain: ’<Root>/k1’ */
rtb_Product_i = exprfld_U.i1 * exprfld_P.k1_Gain;
/* Gain: ’<Root>/k2’ */
rtb_k2_i = exprfld_U.i2 * exprfld_P.k2_Gain;
/* Product: ’<Root>/Product’ */
rtb_Product_i *= rtb_k2_i;
/* Outport: ’<Root>/Out1’ */
exprfld_Y.Out1 = rtb_Product_i;
}
5.12 Loop Unrolling Threshold
Il campo Loop unrolling threshold nel pannello di ottimizzazione determinaquando un segnale o parametro ampio(con piu di un elemento) debba essereinserito in un ciclo for o se debba essere generato con degli statements sepa-rati per ogni elemento del segnale. Il valore di default e 5. Questo vuol direche se un parametro ha 5 o piu elementi verra utilizzato un ciclo for , se unparametro ha 4 elementi verranno prodotti 4 differenti statements nel codicedel modello.
52
5.13 Remove Code from Floating-Point to In-
teger Conversions That Wraps Out-of-
Range Values
Questa opzione fa rimuovere a Real-Time Workshop il codice che assicura chel’esecuzione del codice generato produca gli stessi risultati della simulazionequando avviene una conversione che va fuori range. Questo riduce la dimen-sione e aumenta la velocita del codice prodotto a scapito della possibilitadi produrre risultati che non corrispondono a quelli della simulazione se sihanno valori fuori scala.
5.14 Parameter Structure
Il menu Parameter structure permette di controllare come vengono generati idati dei parametri per i sottosistemi riutilizzabili. Questo menu viene attivatoquando si attiva l’opzione Inline Parameters. Le opzioni del menu sonodue:
• Hierarchical : Quando e attiva questa impostazione Real-Time Work-shop Embedded Coder genera per ogni sottosistema riutilizzabile unfile di intestazione separato che definisce una struttura di parametriindipendente.
• Non-hierarchical : Con questa configurazione attiva Real-Time Work-shop Embedded Coder genera una unica struttura dati dei parametri.Questa e una struttura dati di tipo piatto che puo ridurre in molti casiil padding del compilatore tra le word risultando in un codice compilatopiu efficiente.
5.15 Sottopannello Data Initialization
Queso sottopannello contiene delle opzioni relative all’inizializzazione deidati.
• Remove root-level I/O zero initialization : Il codice di inizial-izzazione per le porte di ingresso e di uscita al livello root non vienegenerato.
• Use memset to initialize floats and doubles to 0.0 : Se nonsi utilizza memset per inizializzare floats e doubles viene generato delcodice aggiuntivo apposito.
53
• Remove internal state zero initialization : Se l’opzione e disattivaviene generato del codice che inizializza a zero le strutture di lavorointerne.
• Optimize initialization code for model reference : Se un bloccoin un sitema puo resettare i suoi stati interni Real-Time Workshopgenera codice di inizializazione run-time per il blocco in questione.
5.16 Remove code that protects against divi-
sion arithmetic exceptions
Questa opzione rimuove il codice che protegge dalla divisione per zero a vir-gola fissa. Attivando questa opzione i risultati della simulazione potrebberodifferire da quelli prodotti dal codice generato in esecuzione.
Un’altro pannello importante per la corretta generazione del codice em-bedded e il pannello Hardware Implementation mostrato in figura 5.1.Questo pannello ci permette di selezionare la famiglia di dispositivi a cuiappartiene il nostro microcontrollore target. Se non disponibile e anche pos-sibile usare un device generico e impostare manualmente la tecnologia e lecaratteristiche del dispositivo. Nel caso di interesse e sufficiente selezionaresotto la voce Device type la famiglia Infineon C16x. L’emulazione hardwarenon ci interessa dato che utilizziamo Matlab solo per generare il codice.
Il pannello piu importante e il pannello Real-Time Workshop(figura 5.2).Qui viene specificato il System target file da utilizzare nel processo dicreazione del codice. Il pulsante Browse permette di selezionare alcuni tar-get gia ottimizzati per la generazione del codice.Il sottopanello Build process specifica inoltre il make command da es-eguire ed il Template makefile. E’ possibile passare anche delle opzioni alTLC per personalizzare la produzione del codice e la compilazione. Per quan-to riguarda la mia configurazione ho scelto l’Embedded target per InfineonC166 quindi il system target file c166.tlc e il template makefile c166.tmf (an-che se di fatto non lo utilzzo dato che non genero l’eseguibile tramite Matlab).Ho anche spuntato il check box Generate Code only poiche sono interes-sato solo alla generazione del codice.
54
Figura 5.1: Pannello Hardware Implementation
In figura 5.3 e riportato il pannello Interface. In questo pannello e possibileselezionare numerose opzioni. Prima di tutto si puo scegliere lo standard digenerazione del codice matematico floating-point, nel mio caso l’ ANSI-C, masoprattutto e qui che si sceglie se il codice puo supportare o no determinatefeature.In figura sono selezionati i supporti per i numeri a virgola fissa e per il tempoassoluto. Il floating-point e attivo solo perche necessario in fase di debug pervisualizzare correttamente le informazioni. Puo essere quindi disattivato infase di produzione del codice finale una volta eliminati i blocchi di debug.Nel sottopannello Code interface ci sono numerose altre opzioni. L’unicaselezionata e Single output/update function che fa generare una solafunzione che comprende uscita e update degli stati dato che non siamo intempo continuo e non dobbiamo derivare nulla.
Nel pannello subito sotto(figura 5.4), Templates, ci interessa solo il sot-topannello Custom templates. Qui andiamo ad impostare come file ditemplate per la personalizzazione il file modificato precedentementemyc166customfiles.tlc e chiediamo di generare un file main di esempio di tipoBareBoardExample.
L’ultimo pannello a cui siamo interessati e il pannello C166 Options dove
55
Figura 5.2: Pannello Real-Time Workshop
Figura 5.3: Pannello interface
andiamo a deselezionare tutto e attiviamo solamente use prebuilt RTWlibraries (in realta potremmo deselezionare tranquillamente anche questa
56
Figura 5.4: Pannello Templates
opzione). La figura 5.5 mostra il pannello in questione.
57
Figura 5.5: Pannello C166 Options
58
