UNIVERSITÀ DEGLI STUDI DI GENOVA. Facoltà di Ingegneria. Sviluppo di servizi di controllo remoto della scheda DSP DM355 EVM per il laboratorio ISILab

Transcript

1 UNIVERSITÀ DEGLI STUDI DI GENOVA Facoltà di Ingegneria Dipartimento di Ingegneria Biofisica e Elettronica Sviluppo di servizi di controllo remoto della scheda DSP DM355 EVM per il laboratorio ISILab Relatori: Anna Marina Scapolla Giancarlo Parodi Correlatori: Paolo Buschiazzo Davide Leoncini Candidati: Gabriele Campodonico Emanuele Fumeo Genova, 11 Marzo 2011

2 Alla Commissione di Laurea e di Diploma Alla Commissione Tirocini e Tesi Sottopongo la tesi redatta dagli studenti Gabriele Campodonico ed Emanuele Fumeo dal titolo: Sviluppo di servizi di controllo remoto della scheda DSP DM355 EVM per il laboratorio ISILab. Ho esaminato, nella forma e nel contenuto, la versione finale di questo elaborato scritto, e propongo che la tesi sia valutata positivamente assegnando i corrispondenti crediti formativi. I Relatori Accademici Anna Marina Scapolla Giancarlo Parodi

3 Abstract This thesis is concerned with the realization of plug-in and programs for the remote control of the evaluation board DM355 EVM within ISILab, a remote laboratory present at the University of Genoa. Our work aims to allow users to connect remotely to the board we mentioned before, to compile and then to execute specific programs for this architecture. Plug-in and test programs have been developed using C and C++ programming languages in GNU/Linux Ubuntu and Montavista Linux operating systems. This thesis has been developed in the "Electronic Systems and Networking Group" (ESNG) laboratory at the Departement of Biophysical and Electronics Engineering (DIBE) of the University of Genoa.

4 Sommario Questa tesi é incentrata sulla realizzazione di alcuni plugin e programmi che consentano l utilizzo remoto della scheda di sviluppo DM355 EVM per il processore DaVinci TMS320 di Texas Instruments all interno di ISILab, un laboratorio remoto presente nell Universitá di Genova. Tramite il nostro lavoro si vuole dare quindi la possibilitá ad un utente di collegarsi da remoto alla scheda di cui sopra, compilare e successivamente eseguire programmi specifici per l hardware in questione. I plugin e i programmi di test sono stati sviluppati utilizzando i linguaggi di programmazione C e C++ e i sistemi operativi GNU/Linux Ubuntu e Montavista Linux. La tesi è stata svolta nel laboratorio Electronic Systems and Networking Group (ESNG), presso il Dipartimento di Ingegneria Biofisica ed Elettronica (DIBE) dell Universitá di Genova.

5 Ringraziamenti Vogliamo ringraziare prima di tutto gli Ing. Paolo Buschiazzo, Davide Leoncini e Alessio Leoncini e anche tutti i ragazzi del laboratorio ESNG per la grande disponibilitá e i preziosi consigli e aiuti che ci hanno sempre dato durante tutto il lavoro della tesi. Ringraziamo la Prof.ssa Scapolla per la sua gentilezza e disponibilitá e per il prezioso lavoro di revisione che é andato oltre a quello che é consueto per una laurea triennale. Ci teniamo a ringraziare anche le nostre famiglie che ci hanno sempre sostenuto moralmente e anche fisicamente con deliziosi pranzetti nelle lunghe giornate di studio. Grazie per esserci stati vicini nei momenti di difficoltá e di sconforto. Grazie davvero! Un grazie va anche ai nostri amici e colleghi coi quali abbiamo passato tanti bei momenti. iv

6 Indice Indice Introduzione v viii 1 I Laboratori Remoti Cos é un laboratorio remoto? Architettura generale Esempi di laboratori remoti NetLab - University of South Australia WebLab-Deusto - Universitá di Deusto Laboratorio DSP - Universitá di Maribor edsplab - EED, Universitá di Siviglia RESP - Arizona State University Conclusioni Il laboratorio ISILab Un po di storia Il primo ISILab Un nuovo approccio: il service oriented framework Architettura di ISILab La Homepage di ISILab v

7 Indice vi 2.2 FoxController Architettura del software Interfaccia del web service Plugin dei dispositivi Cos é un plugin? Funzionamento e integrazione con l applicazione host Gestione dei plugin di FoxController Plugin e Metadati Punti di forza della soluzione Controllo remoto della scheda DSP DM355 EVM Introduzione La scheda di sviluppo DM355 EVM Visione d insieme della scheda La memoria Formato di acquisizione Setup della Macchina Virtuale I plugin Il Template plugin Il Plugin per il compilatore Il Plugin per la scheda I Makefile Cos é un Makefile? Realizzazione dei nostri Makefile L intero sistema in funzione Il sistema in prova 54

8 Indice vii 4.1 FoxControllerMonitor Test della scheda e dimostrazione delle sue potenzialitá Il filtro passa basso Il filtro di Sobel Sviluppi futuri 68 Appendice 69 I thread I mutex Bibliografia 74

9 Introduzione Nell insegnamento delle materie scientifiche l utilizzo dei laboratori é uno strumento essenziale sia per introdurre gli studenti alla materia, sia per dare loro l occasione di toccare con mano gli argomenti trattati durante le lezioni. Purtroppo in alcune occasioni si deve rinunciare all attivitá di laboratorio per mancanza di setup sperimentale appropriato e per l assenza di spazi adeguati al numero degli studenti. Altre volte le apparecchiature hanno un costo elevato, e quindi non si possono fornire unitá sufficienti per tutti gli studenti, o ugualmente non possono essere utilizzate dagli studenti senza che siano seguiti da tecnici di laboratorio. Questo peró ci porta a considerare il problema della scarsa disponibilitá di personale che abbia le conoscenze e l attenzione necessaria ad utilizzare gli strumenti di laboratorio. Ancora, alcuni esperimenti possono avere dei setup non facilmente riproducibili (ad esempio un esperimento di fisica come il pendolo di Focault). Questi sono i principali motivi per i quali in molte universitá si é deciso di creare dei laboratori remoti che permettano agli studenti di usufruire di strumentazioni da remoto, ovvero attraverso la rete Internet. Per quanto riguarda i piú famosi laboratori remoti accessibili via Internet, possiamo citare il progetto ilabs del MIT, il progetto VISIR, il progetto WebLab-Deusto dell Universitá di Deusto, il progetto Low-Cost Remote Lab for Internet Services Distance Education dell Universitá dell Illinois, il viii

10 INTRODUZIONE ix progetto dell Universitá di Singapore e i laboratori remoti presenti in Italia nelle Universitá di Pisa e Ancona. Anche il corso di studi di Ingegneria Elettronica dell Universitá di Genova ha sviluppato un laboratorio remoto denominato ISILab (Internet Shared Instrumentation Laboratory), che comprende sia una parte dedicata ad effettuare misure su circuiti elettronici analogici e digitali collegati con un oscilloscopio e un generatore di forme d onda, sia una parte per operare su sistemi embedded, in particolare DSP. Il nostro lavoro dunque si inserisce nel progetto ISILab e nello specifico ci siamo occupati della progettazione e dello sviluppo dei plugin necessari all utilizzo della scheda DM355 EVM all interno del laboratorio remoto. Vogliamo presentare la nostra tesi in questo modo: il primo capitolo descrive vantaggi e svantaggi associati all utilizzo dei laboratori remoti, e la loro architettura generale; il secondo capitolo invece descrive quello che é giá presente nella nostra facoltá e quindi il contesto nel quale abbiamo lavorato; il terzo capitolo descrive il lavoro fatto, quindi gli strumenti utilizzati e i programmi sviluppati al fine di rendere operativa da remoto la scheda DM355EVM; nel quarto capitolo presentiamo i tool utilizzati e i programmi scritti per testare il sistema al termine della sua realizzazione, per poi passare ad una visione d insieme di quanto fatto decrivendo l interazione tra le varie parti che costituiscono il nostro progetto; infine parleremo dei progetti futuri resi possibili grazie al lavoro compiuto. É presente alla fine dell elaborato anche un appendice che introduce all utilizzo dei thread, strumento fondamentale per la realizzazione del nostro progetto, descrivendone caratteristiche principali, regole d implementazione e motivazione del loro utilizzo oltre ad un ampia definizione.

11 Capitolo 1 I Laboratori Remoti Nel seguente capitolo verranno descritte le principali caratteristiche dei laboratori remoti e la loro importanza per l apprendimento. In particolare il discorso si incentrerá sugli obiettivi, su cosa mettono a disposizione, sulle potenzialitá, su come funzionano e in generale sugli elementi che li costituiscono per poi fare una breve panoramica sullo stato dell arte in questo settore. 1.1 Cos é un laboratorio remoto? Un laboratorio remoto é un sistema hardware/software che dá la possibilitá di interagire con la strumentazione di un laboratorio scientifico al quale non si ha fisicamente accesso [5]. Esso nasce dalla necessitá di migliorare alcuni aspetti dell esperienza di laboratorio tradizionale che é innegabilmente un fattore fondamentale per l apprendimento soprattutto nel campo scientifico. Rispetto a quest ultimo infatti, quello remoto mantiene la possibilitá di 1

12 CAPITOLO 1. I LABORATORI REMOTI 2 interagire con sistemi reali e non con loro simulazioni, avendone la piena accessibilitá spaziale e temporale. Spaziale perché é sufficiente solo una connessione ad internet e se ne puó quindi usufruire in qualsiasi parte del mondo ci si trovi; temporale perché l accesso é consentito 24 ore su 24. Inoltre, cosa non meno importante, viene data la possibilitá di utilizzare strumenti sofisticati e nella maggior parte dei casi anche costosi, garantendo una maggiore efficienza del laboratorio. Si risolve infatti il problema di laboratori troppo affollati che costringono piú studenti a lavorare sullo stesso dispositivo, e di conseguenza se ne consente l utilizzo individuale per un tempo maggiore anche in orari diversi da quelli previsti dalla facoltá. Tuttavia bisogna anche tenere conto del fatto che l accesso alla risorsa non puó avvenire contemporaneamente da parte di piú utenti, cioé si deve anche contare che si sta operando su uno strumento reale che non puó soddisfare diverse richieste nello stesso istante. Bisogna anche considerare poi la necessitá di sistemi di sicurezza atti alla protezione del dispositivo: essendo a disposizione di un qualunque utente diventa ancora piú importante prevenire il suo danneggiamento. Nel prossimo paragrafo verrá illustrata l architettura generale di un laboratorio remoto. 1.2 Architettura generale Per comprendere meglio il sistema laboratorio remoto nella sua completezza é importante conoscere la struttura generale che li accomuna tutti per poi poter affrontare piú agevolmente il prossimo capitolo nel quale descriveremo ISILab, ovvero il contesto in cui si inserisce la nostra tesi. In un laboratorio remoto possiamo individuare tre componenti:

13 CAPITOLO 1. I LABORATORI REMOTI 3 Figura 1.1: Schema generale di un laboratorio remoto. 1. l interfaccia utente; 2. il server del laboratorio; 3. i dispositivi e le applicazioni controller. L interfaccia utente é quella che permette l utilizzo del laboratorio nelle vere applicazioni. Nasconde dietro a poche funzioni (ad esempio dei pulsanti) la complessitá delle operazioni che devono essere effettuate sulla strumentazione e/o sull esperimento stesso per svolgere una determinata azione. Puó essere un programma da installare sul computer client oppure un applicazione web. Il server del laboratorio si occupa di gestire le richieste che arrivano dagli utenti del laboratorio e di comunicare con le applicazioni controller che controllano i dispositivi. I controller gli comunicano quali risorse sono libere e quali sono occupate. Gli utenti del laboratorio possono fare richieste

14 CAPITOLO 1. I LABORATORI REMOTI 4 diverse contemporaneamente e cercare di utilizzare la stessa risorsa nello stesso istante. In queste situazioni il server del laboratorio deve schedulare le richieste degli utenti controllando quali siano le risorse occupate e quali quelle libere. Le applicazioni controller sono dei programmi che controllano i dispositivi del laboratorio. Esse implementano la comunicazione a basso livello con i dispositivi, utilizzando protocolli e hardware specifici. Raccolgono e mettono a disposizione del server centrale tutte le informazioni disponibili appartenenti ai dispositivi controllati, come ad esempio lo stato. 1.3 Esempi di laboratori remoti Questa sezione illustra alcune implementazioni realizzate da altre istituzioni nell ambito della didattica per permettere l accesso e l utilizzo sia di esperimenti di elettronica di base, sia di schede DSP o piú in generale di sistemi embedded. Ogni sottosezione é relativa ad un determinato laboratorio remoto NetLab - University of South Australia NetLab é un laboratorio remoto sviluppato alla University of South Australia. Attualmente é usato dagli studenti e dallo staff della Scuola di Ingegneria elettrica e dell informazione a scopo dimostrativo ed esercitativo. Puó essere anche utilizzato da visitatori esterni previa registrazione e prenotazione del tempo necessario al proprio esperimento sul sito del laboratorio. NetLab permette l accesso remoto a strumentazione reale e circuiti con componenti a valore variabile, e restituisce misurazioni reali. Ha un interfaccia grafica realistica che consente agli utenti di premere bottoni, girare

15 CAPITOLO 1. I LABORATORI REMOTI 5 manopole come farebbero davanti ad uno strumento reale. Inoltre il modulo circuit builder permette di scegliere da un set limitato i componenti da inserire nel circuito. Dal punto di vista software, NetLab é un applicazione basata su Java. Per utilizzare il laboratorio bisogna scaricare e installare un applet sul proprio pc. La connessione con gli strumenti é resa possibile da un estensione della libreria VISA di National Instruments. Il circuit builder é basato su una matrice che é capace di connettere fisicamente i componenti installati su di essa. Il modulo consiste di 256 nodi disposti in 16 file e 16 colonne. I nodi sono connessi grazie a dei relé DPDT (double pole double throw) [11]. Per la struttura di questi dispositivi elettrici, al massimo si potranno usare 16 componenti a due terminali. Gli strumenti disponibili sono un oscilloscopio, un generatore di forme d onda, un multimetro digitale, quattro resistori variabili, due condensatori a capacitá variabile, un induttore variabile e un trasformatore WebLab-Deusto - Universitá di Deusto L Universitá di Deusto ha sviluppato per il proprio laboratorio remoto il WebLab-Deusto, un framework che ospita numerosi esperimenti. Questi esperimenti possono essere utilizzati dagli studenti attraverso un interfaccia web user-friendly: possono caricare una loro applicazione per lo specifico sistema embedded, usare pulsanti e interruttori per controllare i dispositivi remoti e infine possono visualizzare i risultati ottenuti tramite una webcam. Il WebLab-Deusto rende disponibili tre diversi test-bench: il WebLab-CPLD, il WebLab-FPGA e il WebLab-PIC.

16 CAPITOLO 1. I LABORATORI REMOTI Laboratorio DSP - Universitá di Maribor Il laboratorio remoto DSP del Universitá di Maribor usa un hardware sviluppato appositamente dai suoi ricercatori e un sistema software di controllo basato su MATLAB/Simulink e LabVIEW. Questo laboratorio remoto permette agli utenti di interagire con facilitá con un insieme di esperimenti attraverso una gradevole interfaccia grafica. Inoltre include un sistema di prenotazioni che abilita gli utenti a riservare in anticipo alcuni esperimenti edsplab - EED, Universitá di Siviglia L edsplab si trova all Electronic Engineering Department dell Universitá di Siviglia ed é utilizzato in un corso di base sui microprocessori. Il laboratorio usa come dispositivo di test un digital signal processor TMS320C30 di Texas Instruments connesso ad un generatore di forme d onda e a un comune oscilloscopio. La strumentazione di laboratorio puó essere monitorata tramite una webcam che offre un feedback visuale in tempo reale del banco di lavoro del laboratorio RESP - Arizona State University Un altro esempio di laboratorio remoto rivolto ai DSP é il laboratorio RESP (Real-Time Embedded Signal Processing), sviluppato dall Arizona State University. Il laboratorio offre due differenti test bench: il primo é basato su una scheda Freescale EVM su cui é montato un DSP56858, mentre il secondo é basato sul kit DSK5510 di Texas Instruments che é una piattaforma di sviluppo a basso costo che permette agli utenti di creare applicazioni per la famiglia di DSP TI C55XX. Questo laboratorio é utilizzato al momento

17 CAPITOLO 1. I LABORATORI REMOTI 7 in un corso sull utilizzo Real-Time dei DSP, i cui esercizi sono incentrati su FFT, filtri FIR (Finite Impulse Response) e sintesi di note musicali Conclusioni L analisi di questi laboratori mostra che molti di essi per essere utilizzati necessitano di installare plugin extra oppure run-time framework sul lato client. Questo puó provocare problemi di compatibilitá con il sistema dell utente finale, oppure, in presenza di firewall, puó non essere possibile la corretta comunicazione col server.

18 Capitolo 2 Il laboratorio ISILab Questo capitolo descrive il laboratorio remoto ISILab, l ambiente nel quale si inserisce il nostro lavoro di tesi. Innanzitutto parleremo della storia del laboratorio, ripercorrendo le innovazioni apportate nel corso degli anni, per poi analizzare meglio l architettura attuale del sistema e gli aspetti caratterizzanti. 2.1 Un po di storia ISILab, acronimo di Internet Shared Instrumentation Lab, é un laboratorio remoto per la formazione nel settore dell elettronica. ISILab é il risultato di un progetto nato al DIBE (Dipartimento di Ingegneria Biofisica ed Elettronica) nel 1999, ed é disponibile all indirizzo it/ Il primo ISILab Le idee che hanno spinto professori e ricercatori coinvolti nel progetto sono quelle presentate nel primo capitolo, in sintesi eseguire esperimenti da re- 8

19 CAPITOLO 2. IL LABORATORIO ISILAB 9 Figura 2.1: Architettura del primo ISILab moto con strumentazione e circuiti reali. In effetti il laboratorio nelle sue prime realizzazioni comprendeva solamente dei circuiti analogici e digitali, ed é per questo che quando parliamo di strumentazione ci riferiamo a oscilloscopi e ad generatori di forme d onda. I dispositivi in questione erano controllati da uno o piú server dedicati, detti RLS (Real Laboratory Server), sui quali era attiva un applicazione LabVIEW, e le richieste da parte dell utente sugli specifici esperimenti erano gestite da un web server centralizzato detto VLS (Virtual Laboratory Server), che connetteva gli esperimenti alle interfacce web dei client. La Figura 2.1 illustra l architettura di cui sopra. L interfaccia utente, nel primo prototipo del 2000, si basava su LabVIEW, come del resto il motore lato server; cosí facendo peró, si costringeva l utilizzatore ad installare sul proprio sistema il LabVIEW Run-Time Engine. Per migliorare questo aspetto e rendere piú accessibile il laboratorio si decise di passare ad una versione basata su Java. É molto piú frequente trovare una Java Virtual Machine installata sul computer dell utilizzatore rispetto

20 CAPITOLO 2. IL LABORATORIO ISILAB 10 Figura 2.2: La scheda ISIBoard al LabVIEW Run-Time. In questo modo le interfacce grafiche potevano ora essere caricate piú facilmente. Inizialmente ogni esperimento necessitava di strumentazione propria, perdendo di fatto i vantaggi principali di avere un laboratorio remoto, per cui si pensó ad una soluzione che permettesse di utilizzare la stessa strumentazione per piú circuiti. Fu cosí che venne ideata ISIBoard, che vediamo in Figura 2.2 una scheda dedicata alla gestione di piccole schede-esperimento su cui erano installati i circuiti da utilizzare. Negli anni dal 2001 al 2007 continui aggiornamenti hanno portato ad una offerta di numerosi esperimenti di elettronica analogica e digitale. Il laboratorio gestisce la multiutenza e consente di utilizzare la stessa strumentazione per diversi esperimenti Un nuovo approccio: il service oriented framework Recentemente l architettura del laboratorio é stata aggiornata sotto la spinta delle nuove tecnologie nel mondo delle applicazioni web. Dal 2009, anno di pubblicazione dell articolo [1], si adotta un approccio completamente

21 CAPITOLO 2. IL LABORATORIO ISILAB 11 nuovo basato sull uso di web services. Il W3C (World Wide Web Consortium), la principale organizzazione degli standard per il web, definisce un web service come un sistema software progettato per supportare l interazione tra macchine (computer) diverse tra di loro attraverso una rete. Un web service ha un interfaccia descritta in un formato comprensibile da ogni macchina, ovvero il WSDL (Web Services Description Language). Altri sistemi comunicano con il web service in modi conformi a questa sua descrizione usando messaggi SOAP, solitamente veicolati da pacchetti HTTP. Inoltre si utilizza la serializzazione XML dei dati unitamente ad altri standard [3]. Un web service consente quindi alle applicazioni che vi si collegano di usufruire delle funzioni che esso mette a disposizione. Una caratteristica importante é che ogni operazione ha una sua descrizione comprendente i parametri che si aspetta di ricevere, quelli che restituirá e il tipo di entrambi. Quindi la descrizione delle caratteristiche di un web service e l interfaccia software che fornisce ci permettono di utilizzarlo correttamente con facilitá non appena ci si é collegati. L approccio service-oriented é stato scelto perché permette di modellare con facilitá un qualsiasi sistema elettronico complesso, che puó essere analizzato dal punto di vista delle funzioni che esso offre al suo utilizzatore. Ognuna di esse é tale che i suoi input o output sono modellabili come sorgenti di dati e si possono definire come risorse astratte. Ad esempio, in un sistema di riscaldamento con alcuni sensori di temperatura e una caldaia elettronica, le risorse astratte sarebbero i valori di temperatura registrati dai sensori e lo stato della caldaia (accesa o spenta). I primi possono essere letti, mentre lo stato puó essere sia letto che scritto, cosicché il sistema di controllo dovrebbe leggere i dati in arrivo e decidere se é il caso di accendere o meno la

22 CAPITOLO 2. IL LABORATORIO ISILAB 12 caldaia. Se i dispositivi sono piú complessi, si potrebbe dover lavorare non solo con variabili, ma anche con testi oppure comandi codificati in XML, o anche flussi di dati. In questi casi potrebbe essere conveniente decidere di nascondere la complessitá dei dispositivi all utente finale mediante un unica interfaccia general purpose, come quella di un web service, che quindi puó essere utilizzata per descrivere qualsiasi tipo di dispositivo elettronico. L idea é quella di avere un interfaccia che contenga dei metodi per leggere, scrivere ed elencare tutte le risorse disponibili, che possono essere descritte tramite metadati strutturati, ad esempio via RDF(Resource Description Framework). L RDF é un modello standard per lo scambio di dati nel web. Ha delle features che facilitano l aggregazione dei dati anche se lo schema sottostante ad essi é diverso, e supporta in particolare le evoluzioni degli schema nel tempo senza richiedere che tutti i dati debbano essere cambiati. L RDF estende la struttura a collegamenti del web introducendo gli URI (Uniform Resource Identifier) per dare un nome alle relazioni tra risorse. Ad esempio nel caso di un link di una pagina web l URI permette di dare un nome alla relazione che intercorre tra i due capi del link, ovvero tra la pagina nella quale troviamo il collegamento e quella collegata. Usando questo semplice modello, l RDF rende possibile la combinazione, l utilizzo e la condivisione di dati strutturati e semi-strutturati tra diverse applicazioni. La struttura a collegamenti forma un grafo con una ben precisa direzione (quella dei collegamenti) e facilmente leggibile grazie alle etichette (i nomi delle relazioni). In questo grafo i nodi rappresentano le risorse e le frecce rappresentano la relazione che intercorre fra i nodi. Costruendo il grafo si ha una chiara rappresentazione dei dati che si stanno analizzando [2]. Il modello RDF é utilizzato come metodo generale per descrivere l informa-

23 CAPITOLO 2. IL LABORATORIO ISILAB 13 zione in termini di risorse astratte, e quindi si presta perfettamente all utilizzo nel caso in cui si debbano descrivere le funzionalitá di un dispositivo. Parleremo piú approfonditamente dei documenti RDF quando tratteremo dell architettura software del laboratorio remoto ISILab. Riassumiamo le principali caratteristiche del nuovo modello service-oriented come segue: ogni dispositivo é considerato dal punto di vista delle funzionalitá che offre; una o piú funzionalitá appartententi a uno o piú dispositivi costituiscono insieme una risorsa; ogni risorsa disponibile nel laboratorio corrisponde ad una funzione fornita dal web service; nuove funzionalitá del laboratorio possono essere aggiunte piú agevolmente; Le precedenti affermazioni sono vere indipendententemente dal tipo di dispositivo considerato e conseguentemente dall hardware e dai protocolli che permettono di comunicare con i dispositivi. Questo risultato si ottiene applicando il concetto dell incapsulamento: l implementazione software del servizio é nascosta all utente finale dalla molto piú semplice interfaccia software fornita dal web service Architettura di ISILab Come giá detto, ISILab ha un architettura service-oriented. Vogliamo concentrarci sulla parte che ci riguarda piú da vicino, ovvero ISILab DSP [7], di cui diamo una schematizzazione grafica in Figura 2.3. L architettura

24 CAPITOLO 2. IL LABORATORIO ISILAB 14 Figura 2.3: Schema dell architettura di ISILab DSP di ISILab DSP é organizzata in tre diversi livelli: le risorse, il lab server e l interfaccia utente. Analizziamo nel dettaglio il server, che é il modulo software del sistema che interagisce con le risorse e gestisce le richieste in arrivo dall esterno. In figura le risorse disponibili sono la scheda di sviluppo ADSP BF533 Ez-Kit Lite e il suo software di sviluppo Visual DPS++, comprensivo di compilatore. Il fulcro di questo sistema é rappresentato da due applicazio-

25 CAPITOLO 2. IL LABORATORIO ISILAB 15 ni, dette controller, vale a dire FoxController e FoxService. Il ruolo delle due applicazioni di cui sopra si delinea se si considera il fatto di poter avere risorse eterogenee che utilizzano protocolli di comunicazione e hardware dedicati. FoxController e FoxService devono quindi rispondere all esigenza di mettere in comunicazione i dispositivi e il server del laboratorio. Un controller puó essere installato direttamente su un dispositivo, se esso dispone di un sistema operativo, oppure su un personal computer usato come nodo intermedio, il quale é connesso direttamente al dispositivo. Ogni controller mostra al server la stessa interfaccia del servizio web, che descrive metodi per inviare dati e comandi ai dispositivi disponibili e per leggere da essi. Per fare un esempio sulla situazione attuale, nel laboratorio la scheda DSP é connessa direttamente ad un personal computer su cui é in esecuzione un controller. Il sistema permette di inviare un eseguibile, mandarlo in esecuzione sulla scheda e recuperarne l output come pure lo stato del dispositivo. Grazie al fatto di avere delle applicazioni controller, risorse virtuali come ad esempio il compilatore per il DSP della serie Blackfin possono essere gestite in modo identico. Quindi, per completare il precedente esempio, un progetto software puó essere inviato al nodo compilatore, il quale si occupa di creare l eseguibile corrispondente. Successivamente il file binario creato puó essere recuperato dall utente con l invio di un altro comando. La comunicazione a basso livello tra i controller e i sistemi elettronici é implementata attraverso i plugin, di cui parleremo piú avanti. Di fatto i plugin sono librerie dinamiche (DLL) in sistemi operativi Windows, oppure shared objects nel contesto Linux, scritti in linguaggio C/C++. Essi implementano un set di funzioni in modo da rispondere ai bisogni dell interfaccia del web service, usando primitive di basso livello e specifici protocolli. Ogni

26 CAPITOLO 2. IL LABORATORIO ISILAB 16 dispositivo ne ha uno specifico per il suo hardware. Poiché il controller puó gestire contemporaneamente piú plugin, é possibile costruire complessi insiemi di dispositivi capaci di cooperare perché ad esempio connessi tutti alla stessa rete (nel nostro caso, la rete locale del laboratorio). Inoltre questa architettura riduce al minimo gli sforzi in caso di aggiornamento, sostituzione oppure spostamento dei dispositivi, poiché il modulo software del server resta invariato, mentre é sufficiente modificare i plugin di interesse per ottenere le configurazioni desiderate. Il server del laboratorio rappresenta il cuore di tutta l architettura. Fa da tramite tra l utente finale e le risorse reali. Un esempio di sequenza complessa di operazioni comprende la ricezione di comandi da eseguire sul sistema, quindi l interpretazione di essi, e conseguentemente l interazione con i controller dei dispositivi, poi la ricezione dei dati e successivamente il loro invio ad altre risorse, e cosí via. Ogni interfaccia utente contiene un ben definito insieme di funzioni, ad esempio per configurare gli strumenti oppure per acquisire dati, il tutto mediato dalla semplice interfaccia del web service. Ogni funzione dell interfaccia utente puó contattare piú di una risorsa ed effettuare piú di un azione sullo stesso dispositivo. Un altra importante funzione del server é quella di scheduling delle richieste, implementato da un saldo sistema di lock delle risorse che tiene traccia dei dispositivi giá in uso. Se viene richiesta un azione su una risorsa giá occupata, essa viene accodata e verrá eseguita non appena il dispositivo si sará liberato. Dati gli scopi applicativi dell architettura, ovvero quelli di poter servire un gruppo di studenti, il sistema utilizzato permette lo svolgimento di esercitazioni e altro senza un ritardo percepibile.

27 CAPITOLO 2. IL LABORATORIO ISILAB 17 Figura 2.4: Attuale home page di ISILab La Homepage di ISILab La Figura 2.4 mostra l attuale home page di ISIlab [4], in cui possiamo notare tre link che portano a tre diverse sezioni del laboratorio. La prima é relativa ad esperimenti su circuiti elettronici oggetto dei corsi di elettronica di base della facoltá di Ingegneria. Gli altri collegamenti puntano alla sezione ISILab DSP e all ilab Service Broker. ISILab DSP é la parte nella quale si inserisce il nostro lavoro, poiché tratta dei sistemi embedded e della programmazione su questa particolare classe di dispositivi. L architettura service-oriented descritta nel paragrafo precedente ha reso piú agevole questa estensione. ISILab DSP comprende un IDE (Integrated Development

28 CAPITOLO 2. IL LABORATORIO ISILAB 18 Figura 2.5: L IDE del REmLab per il Blackfin 533 Environment) per la creazione di progetti software compilabili da remoto con il tool di sviluppo VisualDSP++ fornito da Analog Devices, ed é predisposto per l esecuzione (sempre da remoto) di questi progetti sulla board ADSP - BF533 EZ-Kit Lite che monta un DSP della serie Blackfin. In pratica la DM355 EVM su cui abbiamo lavorato dovrebbe essere aggiunta a questa sezione, con il suo specifico IDE, cosí da dare la possibilitá di lavorare con due architetture DSP diverse. Come vedremo nel prossimo capitolo, il processore della serie DaVinci montato sulla nostra scheda di sviluppo é un microprocessore ibrido in parte DSP e in parte ARM9, mentre il Blackfin é un DSP puro. In ogni caso, tutte e due le architetture sono orientate al video processing, per cui hanno come target applicazioni simili. Per finire, in Figura 2.5 possiamo vedere come si presenta all utente la schermata di