1 Università degli Studi di Messina Facoltà di Ingegneria Visilab – Computer Vision and Image Processing Lab Nanodesktop Software development kit per sistemi.

Presentazione sul tema: "1 Università degli Studi di Messina Facoltà di Ingegneria Visilab – Computer Vision and Image Processing Lab Nanodesktop Software development kit per sistemi."— Transcript della presentazione:

1 1 Università degli Studi di Messina Facoltà di Ingegneria Visilab – Computer Vision and Image Processing Lab Nanodesktop Software development kit per sistemi embedded Uno sguardo agli internals Corso di Sistemi Operativi II Messina, 11/12/2009 Seminario tenuto dalling. Filippo Battaglia

2 2 Nella scorsa lezione abbiamo iniziato a vedere le caratteristiche di Nanodesktop, un SDK per piattaforme embedded sviluppato presso il laboratorio Visilab di questa Università. In questa lezione, analizzeremo alcuni aspetti relativi agli internals di Nanodesktop. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

3 3 Ricordiamo che lultima volta avevamo analizzato la Nanodesktop System Architecture. Avevamo detto che il nucleo del sistema nd è diviso in due parti: lHAL, Hardware Abstraction Layer, che ha la funzione di nascondere agli strati superiori del software le caratteristiche specifiche della piattaforma, ed il livello CODE, che contiene le parti che non sono specifiche per lhardware Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

4 4 Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

5 5

6 6 Problema: Come possiamo realizzare un window manager che sia veloce ed efficiente ? Ci poniamo dei requisiti. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

7 7 Il nostro window manager: - deve rinunciare alla compatibilità con X-Window e con Window GDI. Eventuali estensioni (SDL) verranno aggiunte solo in seguito e gireranno sul codice nativo attraverso un layer di traduzione; - deve gestire un numero di finestre limitato a n (e non infinito); - deve gestire un limitato numero di effetti (trasparenze, wallpapers ok, ma niente supporto per finestre 3d, temi del desktop o tab ad esempio); tab ad esempio); - deve supportare i font TrueType tramite la libreria FreeType; - deve supportare il puntatore del mouse; - deve supportare gli sprite; - deve fornire delle dialog box già a disposizione degli sviluppatori per compiti specifici (per esempio, per la selezione di un file) per compiti specifici (per esempio, per la selezione di un file) Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

8 8 - deve gestire i menu - deve essere accelerato in hardware - deve avere il supporto per il char overscreen; - deve gestire una finestra di default per loutput StdOut/StdErr Molti window manager (specie sotto Unix) sono lenti a causa di scelte architetturali particolari (comunicazione tramite socket Unix tra X-client ed X-server). Una libreria C, piccola, compatta ed efficiente permette di ottenere prestazioni superiori: il prezzo che si paga è un aspetto spartano e la perdita di compatibilità con il software preesistente Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

9 9 Cerchiamo di capire come funziona, a grandi linee, il sistema grafico di Nanodesktop Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

10 10 I dati relativi ad ogni singola finestra sono memorizzati in una struct chiamata WindowData. Questa struct contiene dei puntatori a delle aree di memoria che contengono il contenuto della finestra. Queste aree si chiamano: - charmap; - color char map; - window space (WS) - service space (SS) - winsprite screen (WSPR) - logical page (LP) Queste aree vengono allocate/deallocate dinamicamente dalla libreria sulla base delle richieste dei programmi e delle esigenze effettive. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

11 11 Anche ciò che è presente sullo sfondo delle finestre è memorizzato in apposite aree di memoria gestite dinamicamente. Esse sono: - il base screen (BS) - lo sprite screen (SPR) Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

12 12 Analizziamo il sorgente di un programma Nanodesktop #include #include int ndMain() { int CounterX, CounterY, WndHandle; ndInitSystem(); WndHandle=ndLP_CreateWindow (5, 5, 400, 250, "Prova", COLOR_WHITE, COLOR_LBLUE, COLOR_BLACK, COLOR_WHITE, 0); if (WndHandle>=0) { ndLP_MaximizeWindow (WndHandle); for (CounterY=0; CounterY<4; CounterY++) { for (CounterX=0; CounterX<4; CounterX++) { ndWS_DrawRtRectangle (40+60*CounterX, 30+50*CounterY, 30, 30, ndWndColorVector [4*CounterY+CounterX], COLOR_YELLOW, ndWndColorVector [4*CounterY+CounterX], COLOR_YELLOW, NDKEY_BORDER_SIZE (5) | ND_ROUNDED | NDKEY_ROTATE (45), NDKEY_BORDER_SIZE (5) | ND_ROUNDED | NDKEY_ROTATE (45), WndHandle, NORENDER); WndHandle, NORENDER);}} XWindowRender (WndHandle); }} Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

13 13 che dà il seguente risultato: Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

14 14 Il sistema grafico di Nanodesktop si basa su un sistema di renderer. Questi si distinguono in renderer di primo e di secondo livello. I renderer di secondo livello vengono richiamati dal programma applicativo in C tramite apposite routine: XWindowRender (WndHandle); WinSpritesRender (WndHandle); BaseScreenRender (); SpritesRender (); I renderer di secondo livello richiamano internamente il renderer di primo livello: WindowsRender (); Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

15 15 In Nanodesktop, laspetto globale di una finestra (titolo, contenuto, pulsanti di chiusura e di ridimensionamento ecc. ecc.) è contenuto dentro un array chiamato pagina logica (LP, logical page). Ogni finestra ha assegnata una propria logical page. WindowsRender() analizza i dati presenti nelle varie pagine logiche e ricostruisce il frame video finale in una pagina nascosta del framebuffer della PSP. Al termine, una commutazione della pagina video attiva fa apparire il frame istantaneamente (tecnica del double buffering) Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

16 16 Per capire l'attività del renderer di livello LP, è sufficiente guardare questa figura: Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

17 17 Lalgoritmo usato da WindowsRender è molto sofisticato. Infatti, Nanodesktop deve gestire ad ogni frame: - sovrapposizione di finestre - sprites - trasparenze - wallpapers Per incrementare la velocità di rendering, Nanodesktop usa uno speciale algoritmo chiamato accelerazione NanoTile. Tale algoritmo fa uso del chip grafico della PSP per incrementare la velocità di rendering Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

18 18 Nanodesktop divide ogni frame in diverse tessere (tiles). Quando si esegue WindowsRender(), Nanodesktop esegue una serie di chiamate al chip grafico della PSP, visualizzando ad una ad una le varie tile Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

19 19 Il chip grafico della PSP è estremamente veloce. La copia di dati è molto più rapida quando eseguita con sceGuCopyImage() piuttosto che quando viene eseguita via software. Quindi, grazie a NanoTile, noi possiamo ridurre il problema del rendering del frame ad una successione di chiamate allacceleratore grafico. (Sotto PSPE, lunità hardware blitter non è presente, quindi lHAL la emula via software). Lalgoritmo NanoTile è progettato in modo che, se solo una parte dello schermo viene modificata, Nanodesktop renderizzerà solo quella. Le altre parti dello schermo non vengono renderizzate se non sono cambiate. Questo approccio migliora le prestazioni. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

20 20 E necessario comprendere che WindowsRender() è solo una routine a basso livello. Raramente i software applicativi la richiamano direttamente. Le applicazioni di solito richiamano dei render di secondo livello, come XWindowRender() che agiscono su una singola finestra e che, al termine del lavoro, richiamano internamente WindowsRender() riunendo il contenuto delle varie finestre in un singolo frame. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

21 21 La chiamata XWindowRender (WndHandle) avvia il rendering nella finestra con handle WinHandle. Il compito di XWindowRender() è quello di eseguire il merging dei contenuti, relativi ad una sola finestra, dei seguenti spazi: - char map - color char map - window space - service space - winsprite space Alla fine, viene ottenuto laggiornamento della pagina logica assegnata alla finestra. E a questo punto che XWindowRender() richiama internamente WindowsRender() e tutto il frame viene renderizzato sullo schermo. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

22 22 Questo schema spiega meglio lattività di XWindowRender(). Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology XWindowRender WindowsRender

23 23 Problema: che cosa accade se siamo in una applicazione multithreading ? Come possiamo rendere il sistema grafico di Nanodesktop thread-safe ? La risposta è Phoenix Graphic Subsystem. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

24 24 Supponiamo che due thread eseguano XWindowRender() contemporaneamente o, meglio, che il thread 1 inizi un XWindowRender mentre il thread 2 non ha ancora terminato la sua chiamata alla medesima routine. Poichè XWindowRender e WindowsRender usano un unico set di variabili ed un unico acceleratore grafico, il tentativo di eseguire le 2 operazioni di rendering senza un meccanismo di accodamento porterebbe ad un crash del sistema. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

25 25 Potreste pensare allora ad un mutex (semaforo) che risolva il problema: il thread 1 viene sospeso, finchè il thread 2 non ha terminato la sua richiesta di rendering. Questo approccio è detto di tipo bloccante (blocking). Il problema è che porta a delle perdite di prestazioni: in alcuni casi, potrebbe essere conveniente che sia il thread 1 che il thread 2 possano eseguire laggiornamento dello schermo nellambito della stessa chiamata al renderer di primo livello. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

26 26 Il sistema di rendering Phoenix di Nanodesktop risolve il problema in modo elegante. La routine WindowsRender() viene divisa in 2 parti: - un componente client; - un componente server; Allavvio, Nanodesktop fa partire un thread ad alta priorità (PhoenixGraph thread) che esegue un ciclo continuo, ponendosi in attesa di richieste di rendering da parte dei thread dei programmi applicativi. La componente server di XWindowRender sarà fisicamente eseguita solo da questo thread di sistema. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

27 27 I thread applicativi si limitano ad eseguire la componente client di WindowsRender(). Quando un thread esegue tale routine, viene posto in attesa ed il controllo viene passato ai thread successivi. Anche questi potrebbero eseguire dei WindowsRender() mettendosi in stato di attesa. Ad un certo istante t, ci saranno n thread in attesa che hanno registrato la propria richiesta di rendering in un apposito registro interno di nd, ed il controllo passerà al Phoenix Graph Thread. Questultimo leggerà i registri di richiesta rendering, e soddisferà le richieste in ununica istanza. Alla fine, i thread clienti vengono riattivati uno alla volta Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

28 28 Questo schema mostra quanto detto: Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

29 29 Grazie al Phoenix Graph Thread ed allaccelerazione NanoTile, possiamo eseguire unapplicazione in cui viene visualizzato un filmato in una finestra mentre in unaltra viene scaricato un file. Tutto ciò senza blocchi o conflitti. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

30 30 Passiamo ora ad un altro problema: la gestione degli eventi Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

31 31 Tutti i desktop manager hanno bisogno di un sistema di gestione degli eventi. Questo deve essere programmabile dallo sviluppatore finale. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology Cosa accade se eseguiamo un doppio click su una icona ?

32 32 Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology Cosa accade se selezioniamo una voce del menu ?

33 33 Il sistema di gestione degli eventi di Nanodesktop è basato su delle callback. Una callback è una routine che viene eseguita quando viene attivato un certo elemento grafico sullo schermo (pulsante, textbox, icona sul desktop, voce del menu ecc. ecc. ecc.) Le callback sono programmabili: è lo sviluppatore che stabilisce cosa deve accadere quando un certo elemento grafico viene attivato. Quando si decide che un evento grafico sia gestito tramite callback, si dice che esso è interno o callback based. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

34 34 Il cuore del sistema di gestione degli eventi di Nanodesktop si basa su una routine, chiamata MouseControl(). Quando un thread incontra questa routine, viene posto in stato di sospensione, il puntatore del mouse appare sullo schermo, e Nanodesktop è pronto ad eseguire qualsiasi callback sia associata ad elementi che siano selezionati dallutente nel sistema grafico corrente. Il thread chiamante ripartirà solo in presenza di particolari eventi (detti eventi esterni) che non possono essere gestiti internamente da nd oppure a livello di callback. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

35 35 In caso di evento esterno, è il thread che ha chiamato MouseControl() che deve gestire la situazione. A tale scopo, esso riceve un messaggio (una particolare sequenza di codici che viene memorizzata in una struct ndEvent_Type), e può prendere le decisioni che meglio ritiene opportune. Questo meccanismo di programmazione è un pò particolare, ma si consideri che da almeno un anno nd fornisce routine, come ndProvideMeTheMouse_Until(), che richiamano internamente MouseControl() ma permettendo di usare il sistema degli eventi in modo molto più semplice. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

36 36 A questo meccanismo si affianca il Phoenix Mouse Thread. Questo thread viene lanciato automaticamente da nd quando viene fatto apparire sullo schermo il puntatore del mouse. E questo thread che provvede a leggere lo stato dei registri del pad della PSP ogni t millisecondi, aggiornando la posizione del puntatore del mouse. Il PMT provvede anche a richiedere a WindowsRender() lo spostamento/ridimensionamento delle finestre, ed ad eseguire le callback legate agli eventi del sistema grafico. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

37 37 Questo schema ci mostra come funziona il sistema degli eventi di nd Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

38 38 Ogni volta che deve essere eseguita una callback, Nanodesktop può gestire la situazione in 2 modi. a) Può eseguire il codice della callback nellambito del Phoenix Mouse Thread. E la soluzione che di solito si adotta per piccole routine b) Può lanciare un thread apposito, chiamato CBE (Callback executor thread) che dovrà eseguire la callback autonomamente. Viene usato per routine complesse, che a loro volta dovranno creare altre finestre e porsi in attesa di altri eventi da parte del sistema grafico. Al termine dellesecuzione della callback, il CBE thread viene terminato e cancellato. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

39 39 Si noti che in condizioni ideali, noi avremo nel sistema n callback, ciascuna con un certo compito e con certe finestre, ognuna delle quali gira in un suo thread CBE (potremmo dire... in un proprio contesto) ed ognuna delle quali accede al sistema grafico in modo indipendente. Ciò non è un problema, perchè abbiamo visto che il sistema grafico di nd può gestire senza problemi laccesso concorrente di più thread al sistema grafico. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

40 40 Poniamoci ora una domanda: questa architettura potrebbe essere usata in futuro per creare un piccolo sistema operativo con interfaccia grafica e multiprocesso ? La risposta è no. O, almeno, non del tutto. Infatti, Nanodesktop deve sottostare ad una pesante limitazione del sistema operativo della PSP. Lo scheduler del PSP-OS fornisce un multitasking di tipo preemptive, ma lassenza della MMU nel processore MIPS della PSP implica limpossibilità di ottenere i requisiti di isolamento e protezione tipici degli os multiprocesso. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

41 41 In altre parole, quando un processo cerca di scrivere al di fuori del proprio spazio di indirizzamento, il microprocessore non solleva uneccezione (a differenza di quanto accade con i processori Intel o Motorola). E anche a causa di questa caratteristica che sulla PSP non sono state portate le normali distribuzioni Linux. Lunica che finora è stata portata (ma attualmente non esegue programmi diversi da quelli eseguibili da CLI) è uCLinux (http://www.uclinux.org/) uCLinux è una distribuzione Linux dedicata specificamente ai dispositivi senza MMU. Non supporta X, nè Gnome, nè KDE. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

42 42 La compatibilità POSIX Dal corso di Sistemi operativi sappiamo che lo standard POSIX (Portable Operating System Interface) è un insieme di specifiche emanate dallinstituto IEEE per definire in che modo devono comportarsi alcuni sistemi operativi (in particolare, i sistemi operativi della famiglia Unix). Lo standard stabilisce alcune specifiche riguardo al tipo di interfaccia con gli applicativi, al sistema di gestione dei thread, dei segnali, e dei semafori, nonchè alla struttura del file system e delle pipe. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

43 43 Avere un buon layer di compatibilità POSIX è essenziale perchè molti software del mondo x86 fanno uso di funzionalità che sono definite proprio dallo standard. Per esempio, quando unapplicazione del mondo Unix/Linux vuole create un thread, usa la funzione int pthread_create(pthread_t * thread, const pthread_attr_t * attr, void *(* start_routine )(void*), void * arg ); e per distruggerlo usa: int pthread_cancel(pthread_t thread); Se queste funzioni non sono presenti, lapplicazione non è portabile. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

44 44 Il PSPSDK fornisce una API per la gestione di thread e semafori. Ma è molto diversa da quella prevista dallo standard POSIX. Per esempio, per creare un thread: SceUIDSceUID sceKernelCreateThread (const char *name, SceKernelThreadEntry entry, sceKernelCreateThreadSceKernelThreadEntry SceUIDsceKernelCreateThreadSceKernelThreadEntry int initPriority, int stackSize, SceUIntSceUInt attr, SceUInt SceKernelThreadOptParamSceKernelThreadOptParam *option) SceKernelThreadOptParam *option) option SceKernelThreadOptParamoption Mentre per terminare e distruggere un thread: sceKernelTerminateDeleteThreadsceKernelTerminateDeleteThread (SceUID thid) SceUID sceKernelTerminateDeleteThreadSceUID E chiaro che era necessario intervenire per garantire la compatibilità POSIX Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

45 45 Sotto Nanodesktop, il problema è stato risolto tramite il porting di una libreria, chiamata EmbPThread. (http://sourceforge.net/projects/pthreads-emb/) http://sourceforge.net/projects/pthreads-emb/ Questa libreria si comporta come un layer di traduzione e fornisce alle applicazioni nd quasi tutte le funzioni relative alle funzionalità previste dallo standard POSIX thread. In questo modo diventa possibile eseguire sulla PSP normali applicazioni per x86 che richiedono un certo grado di compatibilità POSIX Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

46 46 Parallelizzazione dei calcoli attraverso la VFPU Infine, volevo soffermarmi un attimo sulla tecnologia di parallelizzazione dei calcoli che viene usata da Nanodesktop. Come detto nel nostro precedente incontro, la parallelizzazione dei calcoli ha consentito di eseguire algoritmi di visione artificiale estremamente sofisticati su un dispositivo portatile come la PSP. Alla base di questo risultato cè la VFPU, il componente hardware integrato nel processore della PSP, e capace di performance superiori a 2 Gflops/sec. Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

47 47 La VFPU fornisce 128 registri in virgola mobile a 32 bit. I registri sono divisi in 8 matrici da 4x4 registri. La VFPU, inoltre, possiede istruzioni che consentono di eseguire la somma, la differenza, la moltiplicazione scalare di due matrici di 4x4 elementi con pochi cicli di clock. Ora, supponete di avere una singola istruzione che sommi due matrici 4x4 elementi Appare evidente che potete agire su 16 elementi alla volta! (SIMD) Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology 1504 0314 5343 2150 2231 03110 1111 350 3735 06214 6454 50100

48 48 Normalmente la VFPU della PSP dovrebbe essere programmata direttamente in linguaggio assembler. Tuttavia, Nanodesktop integra un componente che consente di eseguire le operazioni richieste direttamente dal linguaggio C: si chiama EMI (Enhanced Mathematical Interface). Sotto PSPE la VFPU non è emulata, quindi viene usato un altro componente, chiamato EMIEMU che provvede ad emulare via software le operazioni necessarie. La cosa non è comunque un problema, perchè lo sviluppatore può usare un wrapper chiamato ndHAL_XFPU che richiama la funzione giusta sia sotto PSPE che sotto PSP Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

49 49 Nel programma che ora vi mostrerò, noi eseguiamo la formula x^2 + 1 per x che va da 0 a 15 Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

50 50 Il programma è questo: #include #include #define MATRIX0 0 #define MATRIX1 1 #define MATRIX2 2 int ndMain() { float FloatBufferA [16], FloatBufferB [16], FloatBufferRes [16]; float FloatBufferA [16], FloatBufferB [16], FloatBufferRes [16]; int Counter; int Counter; ndInitSystem (); ndInitSystem (); for (Counter=0; Counter<16; Counter++) FloatBufferA [Counter] = Counter; for (Counter=0; Counter<16; Counter++) FloatBufferA [Counter] = Counter; for (Counter=0; Counter<16; Counter++) FloatBufferB [Counter] = 1; for (Counter=0; Counter<16; Counter++) FloatBufferB [Counter] = 1; ndHAL_XFPU_Load16FloatsToMatrix (MATRIX0, &FloatBufferA); ndHAL_XFPU_Load16FloatsToMatrix (MATRIX0, &FloatBufferA); ndHAL_XFPU_Load16FloatsToMatrix (MATRIX1, &FloatBufferB); ndHAL_XFPU_Load16FloatsToMatrix (MATRIX1, &FloatBufferB); ndHAL_XFPU_MatrixTrvMul (MATRIX0, MATRIX0, MATRIX0); ndHAL_XFPU_MatrixTrvMul (MATRIX0, MATRIX0, MATRIX0); ndHAL_XFPU_MatrixSum (MATRIX0, MATRIX1, MATRIX2); ndHAL_XFPU_MatrixSum (MATRIX0, MATRIX1, MATRIX2); ndHAL_XFPU_Store16FloatsFromMatrix (MATRIX2, &FloatBufferRes); ndHAL_XFPU_Store16FloatsFromMatrix (MATRIX2, &FloatBufferRes); for (Counter=0; Counter<16; Counter++) printf ("sqr(%d) + 1 = %f \n", Counter, FloatBufferRes [Counter]); for (Counter=0; Counter<16; Counter++) printf ("sqr(%d) + 1 = %f \n", Counter, FloatBufferRes [Counter]); ndHAL_WaitKey (0); ndHAL_WaitKey (0);} Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

51 51 Vediamo il risultato: Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology Funziona! E si può anche verificare che sulla vera PSP è molto veloce

52 52 La programmazione tramite ndHAL_XFPU è un argomento molto complesso. Per ora vi rimando al capitolo 28 della Nanodesktop User Guide Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology

53 53 GRAZIE Visilab – Computer Vision and Image Processing Lab University of Messina - Italy Nanodesktop tecnology