Table of Contents Table of Contents
Previous Page  64 / 84 Next Page
Information
Show Menu
Previous Page 64 / 84 Next Page
Page Background

EMBEDDED

59 • FEBBRAIO • 2016

SOFTWARE

|

PIL TEST

64

funzioni del codice sorgente. Nel passo successivo

i parametri possono essere collegati, a livello di

modello, alle loro controparti a livello di codice

sorgente.

Dopo che l’utente ha completato la configurazio-

ne dell’interfaccia, vengono generati automati-

camente degli opportuni wrapper per l’ambien-

te target, come collegamenti fra le funzioni-S e

il codice sorgente (Fig. 5). Nella simulazione il

compito dei wrapper è implementare le uscite

delle callback attraverso il blocco PIL, in modo

da richiamare le funzioni assegnate e impostare

le variabili ai valori corretti. Inoltre, in base alla

configurazione dell’interfaccia, viene generato il

codice sorgente della funzione-S del blocco PIL.

Il metodo descritto è caratterizzato da un elevato

grado di portabilità, dal momento che può essere

utilizzato sia in combinazione con dei generatori

di codice sia con codice sorgente scritto a mano.

Le differenze strutturali dovute a processi diver-

si di generazione di codice possono essere tenute

in considerazione mediante l’interfaccia di con-

figurazione. Affinché la nuova interfaccia d’in-

tegrazione possa essere effettivamente usata in

un’ampia gamma di ambienti, nello sviluppo è

necessario porre la massima attenzione sull’ana-

lisi automatica della struttura del codice.

Connessione uniforme all’ambiente target -

Il secondo importante fattore per un’agevole por-

tabilità dell’interfaccia d’integrazione è l’utilizzo

di un debugger con un’interfaccia API. Ciò per-

mette a piattaforme target diverse di collegarsi

all’ambiente di modellazione su un’interfaccia

generica. Nessun altra personalizzazione del

software è richiesta per questo scopo. Utilizzan-

do interfacce speciali, come per esempio JTAG,

il debugger può dunque controllare l’esecuzione

del programma nell’ambiente target e accedere

ai parametri del modello. In linea di principio è

possibile assicurare che il debugger offra suppor-

to all’ambiente target fin dalla prima fase di pro-

getto del software.

Progetto di un prototipo dell’interfaccia

d’integrazione -

Per implementare la proposta

attuale in una vera applicazione è stato svilup-

pato un prototipo dell’interfaccia d’integrazione.

Il prototipo consiste in una struttura dotata di

interfaccia grafica (Fig. 6) per la generazione

dell’infrastruttura PIL.

L’utente può così specificare una dopo l’altra

tutte le impostazioni necessarie per conver-

tire un blocco del modello in un blocco PIL.

Se non sono richiesti tutti i passi è possibile

disabilitarli individualmente.

L’avvio della simulazione fa partire l’esecu-

zione automatica di una simulazione PIL con

l’aiuto dell’ambiente target. Il prototipo è in

grado di analizzare il codice sorgente scrit-

to nel linguaggio di programmazione C, e di

processare le funzioni con argomenti scalari.

Per eseguire la simulazione PIL è stato im-

plementato un supporto per l’interfaccia API

TRACE32. Inoltre il processo di produzione

può essere modificato per integrare il wrap-

per generato automaticamente e caricare poi

l’applicazione in ambiente target.

Grazie al suo progetto modulare, l’approccio

proposto realizza un elevato grado di scala-

bilità.

I blocchi PIL possono essere combinati flessi-

bilmente con gli altri elementi dell’ambiente

di modellazione così da poter estendere gra-

dualmente i modelli esistenti e integrare fa-

cilmente i blocchi PIL in nuovi modelli.

Inoltre l’utilizzo dell’interfaccia API del de-

bugger permette anche di collegare simulta-

neamente più ambienti target.

Fig. 6 Interfaccia grafica per l’utente (GUI)