Relazione Progetto cRio

1,143 views
1,064 views

Published on

Relazione sul progetto di realizzazione di un algoritmo di localizzazione (mediante trilaterazione) attraverso l'utilizzo del controllore cRIO e del software LabVIEW.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,143
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Relazione Progetto cRio

  1. 1. Misure Elettriche ed Elettroniche Prof. Bruno Andò PROGETTO CRIO Mazza Dario 616/002007 Merlino Sebastiano 616/002008 Messina Marco 616/002000
  2. 2. Progetto cRIO Obiettivi • Acquisire conoscenze di base sull’apparato hardware. • Comprendere il funzionamento del sistema software di base. • Accumulare esperienze a proposito di interfacciamento dell’oggetto con hardware esterno. • Utilizzare l’oggetto come controllore “stand alone” di sistemi automatici. • Reimplementare l’algoritmo di trilaterazione utilizzato nel sistema CAN-Bus attualmente realizzato mediante motore MatLab. • Ottimizzare l’algoritmo di cui al punto precedente per un funzionamento “stand alone” sul cRIO. Generalità Il cRIO (Compact Reconfigurable I/O) è un microcontrollore real-time programmabile per sistemi embedded che offre ottime potenzialità come sistema stand alone per l’esecuzione di applicazioni real-time in LabVIEW. Si trovano all’interno dello chassis dispositivi FPGA (Field Programmable Gate Array), ovvero dispositivi digitali la cui funzionalità è programmabile via software. Esso è utilizzato ampiamente nelle fasi di sviluppo dei prototipi, in quanto eventuali errori possono essere risolti semplicemente riconfigurando il dispositivo. Importante caratteristica del sistema è la sua modularità e grazie a questa ed alle altre caratteristiche precedentemente elencate esso va a confluire in quella categoria di sistemi automatici di misura detti più precisamente SADD (Sistemi di Acquisizione e Distribuzione Dati). Il sistema cRIO consta di un’unità centrale (in cui risiede il Sistema Operativo LabVIEW Real-Time ETS) e di uno chassis ove è possibile ospitare fino a 8 moduli che estendono le funzionalità dell’oggetto. Progetto cRIO | Mazza, Merlino, Messina FIGURA 1: NI CRIO-9004 Il modello di cRIO a nostra disposizione è il cRIO-9004 la cui unità centrale include 64MB di memoria DRAM, disponibile per l’esecuzione delle applicazioni, e 512MB di memoria (a tecnologia flash) per l’immagazzinamento dei dati inerenti il software ed il suo funzionamento. Il sistema è caratterizzato da buona robustezza e da alta affidabilità; inoltre, risultano bassi i consumi del controller progettato per funzionare con alimentazione duale compresa tra i 9 ed i 35 Volt in continua. L’adattabilità del sistema viene dimostrata anche dalla sua resistenza ai fattori ambientali essendo esso in grado di lavorare a temperature comprese tra i -40° C ed i 70° C. L’utilizzo di un processore che lavora alla frequenza di 195 MHz permette il bilanciamento di bassi consumi in potenza e buone capacità di calcolo. Il NI cRIO si interfaccia con sistemi informatici tramite porta Ethernet BaseT 10/100, ed inoltre vi è una porta seriale RS232 per collegarvi device 1
  3. 3. esterni. Un FTP server facilita l’accesso ai file di log o di configurazione presenti all’interno del cRIO. I moduli di cui siamo dotati sono 4 e precisamente abbiamo: • NI 9215 BNC: consta di 4 canali analogici(fino a 16 bits simultanei di input), con un range di input 10  . Tale modulo ha una banda a -3 dB di almeno 420 kHz. Il convertitore A/D ha una frequenza di campionamento di 800 kS/s in modalità multiplexer e 100 kS/s in campionamento simultaneo. • NI 9263: presenta 4 canali analogici per una risoluzione di 16 bit; anch’esso presenta un range di input pari a 10  . E’ un modulo con una discreta robustezza, in quanto possiede una protezione contro tensioni non esterne al range di 30  . Ha una velocità di aggiornamento simultaneo di 100 kS/s. • NI 9265: è dotato di 4 canali analogici; vanta una risoluzione di 16 bit e un range di output che spazia tra 0 e 20 mA. Può sostenere un carico massimo di 600Ω. Ha una velocità di campionamento di 100 kS/s. • NI 9401: è costituito da 8 canali digitali di input/output di tipo TTL a 5  . Il massimo segnale di input processabile dipende dal numero di canali di input utilizzati ed arriva ad un massimo di 30 MHz (solo 2 canali attivi). Il NI 9401 ha un delay time di I/O inferiore a 100 ns. Componenti Software del cRIO Il NI cRIO è un dispositivo dotato di un processore e di una memoria non volatile. Grazie a queste due caratteristiche è possibile installare sul cRIO dei componenti software. Il cRIO viene fornito con un sistema operativo proprietario chiamato LabVIEW Real-Time (ETS): questo si occupa della gestione dei processi e organizza le operazioni di IO effettuate tramite la porta ETHERNET. Oltre al sistema operativo di base, che offre ben poche possibilità per lo sviluppo di applicazioni reali, è possibile installare altri componenti o moduli software forniti dalla National Instruments. Di massima importanza Progetto cRIO | Mazza, Merlino, Messina sono il modulo Real-Time per l’organizzazione dei cicli ad alta priorità, il modulo NI Rio 2.3.1 e il modulo FPGA che si occupa dell’interfacciamento con i moduli del Chassis. Un altro importante strumento installato sul cRIO è il server FTP: grazie a questo è possibile accedere al file-system tramite un qualunque Client FTP. Il server Web integrato nel dispositivo è un'altra risorsa molto utile che però non è stata sfruttata in questo progetto. Che cos'è l'FPGA? Come programmare FPGA con LabVIEW ? Un dispositivo FPGA (Field-Programmable Gate Array) è un dispositivo che può essere configurato, dall'utente o dal progettista, in modo da compiere uno specifico lavoro. La possibilità data all'utente finale di programmare il dispositivo FPGA (Field-Programmable sta per programmabile sul campo) ha 2
  4. 4. permesso a questa tecnologia di diffondersi molto facilmente. Generalmente i dispositivi FPGA vengono però programmati direttamente dai progettisti utilizzando linguaggi come il VHDL (VHSIC Hardware Description Language dove VHSIC sta per Very High Speed Integrated Circuits). La programmazione tramite VHDL dei dispositivi FPGA risulta generalmente abbastanza complessa. LabVIEW e il suo modulo FPGA permettono di programmare i chip FPGA del sistema NI RIO (il cRIO è il modello compatto della famiglia RIO) tramite una comoda interfaccia grafica. Tramite questo modulo si possono sviluppare applicazioni che coinvolgono l'uso di dispositivi FPGA senza avere nessuna conoscenza del VHDL o di progettazione hardware. Inoltre la programmazione grafica degli FPGA, offerta da LabVIEW, incoraggia l'utente a sviluppare sistemi che possono competere, sia in termini di ottimizzazione che di performance, con i dispositivi progettati dalle case produttrici. Lo sviluppo di una applicazione FPGA si svolge su un computer host collegato al dispositivo FPGA; utilizzando il modulo FPGA e il linguaggio G del LabVIEW si ottiene un Virtual Instrument (VI) che poi verrà compilato e inserito nei chip. La compilazione è un processo lungo e, in relazione alla complessità dell'applicazione, può durare solo 15 minuti ma si possono perdere anche diverse ore. La compilazione inizia con la traduzione del VI (grafico) in codice VHDL, quindi viene evocato il compilatore Xilinx ISE per ottimizzare, ridurre e infine sintetizzare la realizzazione hardware del nostro VI. Durante la compilazione vengono inseriti dei vincoli temporali per ottimizzare l'uso delle risorse FPGA e viene, inoltre, ridotta al minimo la logica digitale usata in modo da ottenere un'implementazione ottimizzata che assicuri robustezza ed esecuzione parallela. Inoltre non essendoci nessun sistema operativo sui chip FPGA, il codice così ottenuto è caratterizzato da performance molto alte. Il risultato della compilazione è un file bit stream che, al momento dell'esecuzione, verrà caricato nei chip FPGA ed eseguito con un clock di default a 40 MHz ( 25 ns per ogni tick). Come funzionano le applicazioni sul cRIO ? Un applicazione Real-Time realizzata per essere eseguita sul cRIO è composta essenzialmente da due parti: la prima è quella che rimane sul computer Host mentre la seconda è quella caricata nel cRIO. Le due parti comunicano tramite una connessione ETHERNET e utilizzando un protocollo TCP o UDP. La parte residente sul cRIO è caratterizzata da tre componenti: • Un'applicazione FPGA per l'input, l'output, la comunicazione ed il controllo; • Un Time-Critical Loop per le operazioni in virgola mobile, il processamento e l'analisi dei segnali; Progetto cRIO | Mazza, Merlino, Messina • Un Loop a priorità normale per data logging locale (IO sulla memoria non volatile), l'interfacciamento Web con pannelli remoti e la comunicazione ETHERNET o seriale. I due loop vengono mappati sul sistema operativo come thread separati garantendone l'indipendenza durante l'esecuzione. Solo il Time-Critical Loop è in grado di interagire con l'applicazione FPGA contenuta nei chip. Collegando il cRIO ad un PC tramite cavo ETHERNET è possibile eseguire i VI residenti sul controllore e visualizzarne il Front Panel senza necessariamente implementare la parte residente sul computer Host. Il cRIO non è però stato ideato per essere sempre collegato ad un PC: uno dei suoi tanti punti di forza è la possibilità di lavorare in modalità Stand Alone. In questa modalità si impostano una serie di VI da eseguire quando viene avviato il controllore in modo da poter lavorare senza essere attaccato a nessun 3
  5. 5. computer. La parte Host viene così relegata a semplice pannello di monitoraggio e il computer sarà necessario solo qualora debbano essere effettuate delle modifiche all'applicazione. L'esperimento “Doppia Soglia” L'esperimento “Doppia Soglia” è una semplice applicazione sviluppata per testare le capacità del cRIO e la possibilità di integrare nei VI codice scritto in C. L'esperimento consiste nella lettura di due segnali per controllare se superano due soglie (diverse per i due segnali), i risultati ottenuti dai controlli delle soglie devono essere dati in ingresso ad un codice C che inverte i valori booleani ed, infine, l'uscita del codice C deve essere utilizzata per accendere quattro led. Inoltre, si manda come output analogico la somma dei due segnali in ingresso. Il risultato visibile è che se un segnale è sopra una determinata soglia il led si spegne altrimenti rimane acceso. Per questo esperimento ci siamo avvalsi di tre moduli: NI 9215 BNC per l'input analogico (acquisizione dei due segnali), NI 9263 per l'output analogico (output delle somma dei segnali acquisiti) e NI 9401 per l'output digitale (illuminazione dei led). L'applicazione è divisa in due parti: la prima è l'applicazione FPGA e l'altra è il Virtual Instument che con essa si va ad interfacciare. Usiamo un boolean per definire in quale delle due modalità deve lavorare l'applicazione FPGA (Vero: INPUT, Falso: LED): • INPUT per l'acquisizione dei due segnali, il confronto con le soglie e output della somma dei due segnali; • LED per l'illuminazione dei led tramite output digitale. La prima modalità prende come input i segnali dai moduli e le soglie dal VI e fornisce in output al modulo la somma dei due segnali e al VI quattro boolean (Veri se la soglia è stata superata, Falsi altrimenti). La seconda modalità prende in input dal VI quattro boolean e fornisce in output l'illuminazione dei led in base ai valori boolean ( Led acceso se vero, spento se falso ). Alla fine delle operazione di ogni modalità si manda una IRQ sul canale 3 necessaria a comunicare con il VI. Il Virtual Instrument in primo luogo apre l'applicazione FPGA,poi setta il valore del boolean a Vero per scegliere la modalità INPUT, inserisce le quattro soglie e quindi avvia effettivamente l'applicazione FPGA. Il VI legge i boolean in uscita per poi passarli al codice C e nel frattempo setta il boolean per scegliere la modalità LED e si mette in attesa sulla IRQ 3. Arrivata l'IRQ prende le uscite del codice C ( i quattro booleani invertiti) e li manda di nuovo all'applicazione FPGA per avviarla un'altra volta permettendo l'accesione dei Led. Progetto cRIO | Mazza, Merlino, Messina La Trilaterazione: tecnica utilizzata Nel software sviluppato durante il progetto utilizzeremo una tecnica per l’individuazione dei soggetti nello spazio detta MTA (Multiple Trilateration Algorithm). Si suppone di aver, innanzitutto, distribuito un numero N di sensori (ad ultrasuoni) all’interno di uno spazio chiuso e che ogni sensore fornisca come dato la distanza che lo separa dall’utente di cui si vuole rilevare la posizione. 4
  6. 6. Nell’algoritmo MTA la trilaterazione è applicata a singole terne di sensori e vengono inoltre, in questa fase, eliminate le terne considerate non valide ovvero quelle formate da nodi allineati. Si può, quindi, calcolare che, dati per ipotesi, 8 sensori (tutti supposti validi), avremo 56 differenti terne da valutare. Si suppone, inoltre, per semplicità, che i sensori siano posti tutti alla stessa altezza. L’algoritmo consiste, innanzitutto, nella creazione delle terne e, successivamente, nella realizzazione, per ciascuna terna, delle matrice A e del vettore B tramite queste formule: 2 2         2 2 Nelle precedenti matrici, le variabili x e y rappresentano le coordinate cartesiane del sensore sulla mappa e la variabile r, invece, va ad indicare la distanza rilevata dal sensore. A questo punto utilizzando la formula: · · · otterremo le coordinate, rappresentate dal vettore U, della posizione dell’utente per la singola terna di sensori. La media delle coordinate calcolate dalle singole terne fornirà la posizione finale dell’utente. Funzionamento generale del sistema In questa parte del progetto si è voluto realizzare un VI che calcolasse la posizione dell’utente una volta fornita la mappa dei sensori ed il vettore delle distanze rilevate da questi. Non essendo attualmente disponibile un modulo per l’invio di segnali bluetooth (per la comunicazione con l’utente) si è dovuto realizzare un sistema di scambio informazioni su rete (basata su tecnologia Ethernet) tra il cRIO ed un PC che provvederà a ricevere i dati sulle distanze inviati dai sensori e a rimandarli al cRIO che diverrà, quindi, l’unità logica di calcolo dell’intero sistema e fornirà i risultati ottenuti nuovamente al PC che implementa l’interfaccia utente. Prima di poter spiegare il funzionamento del VI realizzato, è bene spiegare quale sia il metodo utilizzato dal cRIO per l’invio e la ricezione delle variabili su rete. Il cRIO utilizza un motore chiamato Network Variable Engine come server per l’organizzazione delle variabili, un Network Variable Client per ottenerne il valore ed il modulo DataSocket for LabVIEW Real-time per inviarle su rete. Progetto cRIO | Mazza, Merlino, Messina Le variabili vengono distinte dal cRIO in due classi: variabili real-time; variabili network. La differenza tra le due classi di variabili è, praticamente già spiegata dal loro nome. Le variabili real-time vengono gestite dal livello FPGA (hanno quindi priorità real-time nella coda dei processi gestita dal processore del cRIO) e non vengono effettivamente mai trasmesse su rete né ricevute attraverso di essa; per l’effettiva trasmissione e ricezione attraverso la rete ci si affida alla variabili network. La variabile real-time verrà, quindi, scritta su una di tipo network per l’invio di dati e sarà, invece, svolto il processo inverso nel caso di ricezione di dati da utilizzare in processi real-time. 5
  7. 7. Andiamo ora a spiega il funzion o are namento effe ettivo del sist tema da noi r realizzato occcupandoci, dapprima, d del softw che sarà eseguito sul cRIO. ware Il VI è ccostituito da una Flat-Seq quence divisa in più fram Nella prim parte, si nota come il sistema a me. ma i attenda p 10 second di ricevere attraverso l rete la map dei senso Alla ricez per di e la ppa ori. zione della mappa essa m verrà salvata su file in nvece, nel ca in cui la m aso mappa non ar entro i 1 secondi, v rrivi 10 verrà importa da file ata una mappa precedent temente salva ata. A questo punto inizia l’effettivo s o a scambio dati, che è costitu da due l , uito loop definiti rispettivamente loop deterministico e loop non d deterministi che andr ico ranno ad essere eseguiti contemporan neamente in manie ciclica. era Il “loop n determin non nistico” non fa altro che o occuparsi del trasferimen dei dati d nto dalle variabili network i che si muovono su rete al variabili real-time che, invece, verranno utilizzate dal “loop ulla lle d determin nistico” al fin del calco di trilate ne olo erazione. Per ogni ciclo terminato, inoltre, il “l r loop non determin nistico” copie su rete i r erà risultati otten per reinv nuti viarli al PC. In breve il “loop no determini e, on istico” otterr dalla rete il vettore di distanze inv rà i viate dai sensori ed il numero di sensori e li copierà ripettivamen in variab real-time. Al termine del ciclo, il loop si nte bili e occuperà dell’invio d à delle coordin della po nate osizione dell’utente su rete copiando le variabili Real-time R nelle varriabili Netwo Altri com di cui il “loop non deterministic si occupa è quello di attendere ork. mpiti d co” a a eventuali segnali di st dei proce provenien dalla rete ed inviare su rete possibi codici d’er top essi nti u ili rrore. Come gi detto, il “lo determin ià oop nistico” si occ cupa dell’effeettivo calcolo di trilateraz o zione. Una volt che le vari ta iabili real-tim contenen le distanze ed il nume di sensor verranno passate al me, nti ero ri, p suddetto loop, esse saranno forn come in o nite ngresso al bl locco di calccolo realizzat in C. Tal blocco to le fornirà in uscita le c n coordinate de ell’utente op ppure, in cas di irregola so arità, un cod d’errore Il tutto dice e. verrà ritrrasmesso su r rete, come sp piegato prece edentemente dal “loop non determini e, istico”. Molto pi semplice è il Sub-VI d iù destinato ad e essere esegui sul PC. T Sub-VI v ad integra con il ito Tale va arsi sistema d trilaterazio esistente, fornendo un di one , n’interfaccia per la comun nicazione con il cRIO. n Il Sub-V consiste in una sempl Flat-Sequ VI n lice uence con im mposta una temporizzaz zione di 10 msec per m mantene la sincron con il cRIO ere nia O. Le azion svolte VI so due. In un primo mo ni ono omento esso invia l’array di distanze (ricevute da sensori) o y ai ed il num totale d sensori al VI di calcolo sul cRIO; su mero dei o uccessivamen riceve la posizione de nte, a ell’utente finale (ca alcolata sul cRRIO) e l’even ntuale codice d’errore. e È stato, iinoltre, realizzato un VI d configuraz di zione mappa, che si occup semplicem pa, mente, dell’in della nvio mappa dei sensori, co vettore, sulla rete. ome Il codice C Progetto cRIO | Mazza, Merlino, Messina Passiamo ora a spieg o gare quale si la logica d ia del codice i C ideato per calcolare l’effetti in o iva posizione dell’utente. e Sono sta realizzate due differen soluzioni in ate nti C per il calcolo della trilaterazion che abbiam a ne mo chiamato rispettiva o, amente, “a taglio p per valori” ed “a tag glio per occorrenze e”; spieghiam in detta mole aglio. Entramb le soluzioni accettano in ingresso la be matrice delle posizio dei sensori ed il vetto oni ore FIGURA 2: SOGLIE DI TA AGLIO DELL’ALG GORITMO PER V ALORI 6
  8. 8. delle distanze rilevate da questi. Il codice andrà a scartare i sensori che inviano un dato non valido di distanza (maggiore di 10 metri) e, dati questi, calcolerà le terne di sensori valide (quelle per cui i tre sensori non siano allineati o coincidenti). Per ogni terna verrà calcolata la coordinata stimata sull’asse x e quella sull’asse y. A questo punto si troverà la posizione dell’utente calcolando la media dei risultati ottenuti; è proprio in questo calcolo che emerge la differenza fra i due codici. Il codice “a taglio per valori” si basa sulla supposizione che i valori ottenuti per ciascuna coordinata siano distribuiti, per numero di occorrenze, su una gaussiana e che quindi la media calcolata sui valori corrisponda esattamente al risultato voluto. Per poter scegliere i risultati da scartare, il codice ordinerà i risultati dal più piccolo al più grande e scarterà i più piccoli N/5 ed i più grandi N/5, ove N rappresenta il numero totale di valori. L’algoritmo di ordinamento che si è deciso di utilizzare è il QuickSort che assicura le massime prestazioni possibili, rispetto ad altri algoritmi di ordinamento, bilanciando i consumi di memoria e il lavoro del processore. Avendo scartato i valori sicuramente non interessanti si calcola la media sui rimanenti e si ottiene il valore della coordinata. L’operazione appena descritta viene eseguita sia per l’ascissa che per l’ordinata ottenendo quindi la posizione esatta dell’utente. Progetto cRIO | Mazza, Merlino, Messina FIGURA 3: PARTICOLARE DEL VI DI TRILATERAZIONE SUL CRIO Passiamo ora a valutare il peso 1 dell’algoritmo dal punto di vista dell’occupazione di memoria e della complessità di calcolo. 1 Vedi nota successiva 7
  9. 9. Nel caso “peggiore” dal punto di vista della complessità, avremo 64 sensori (maggior numero possibile di sensori sostenuto dalla rete CAN-Bus) tutti a distanza valida e fra i quali non vi siano mai tre sensori allineati o coincidenti. Considerando che ogni variabile in ciascuno dei due vettori è rappresentata mediante l’utilizzo di 64 bit e che nel caso descritto ritroviamo un numero di elementi per ciascun 666,62 kbyte. vettore pari a 41664 avremo quindi una quantità di byte occupati pari a Dal punto di vista della complessità di calcolo l’operazione più faticosa rimane il QuickSort che risulta comunque un algortimo a complessità sottolineare. Si nota un andamento crescente dei tempi di calcolo in maniera direttamente proporzionale al numero di sensori (come si può verificare dal grafico 1). Il codice “a taglio per occorrenze” si propone di risolvere i problemi dell’algoritmo precedentemente descritto, individuati nella supposizione sulla gaussianità della curva dei valori e nell’utilizzo di un algoritmo di ordinamento. Questo algoritmo, non potendo più avvalersi della supposizione sulla gaussianità, dovrà considerare, per ogni supposto valore, il suo numero di occorrenze. Per questo motivo, prendiamo in ingresso un intero rappresentante il numero di cifre dopo la virgola che considereremo per noi significative; tale parametro prenderà, per l’algoritmo, il nome di “accuratezza” e determinerà, perlappunto, l’accuratezza con cui verrà determinata l’uguaglianza fra due numeri (ad esempio 2.3425 è uguale a 2.3476 se accuratezza minore o uguale a 2; i due numeri risultano diversi altrimenti). Per ciascuna coordinata troveremo il minimo ed il massimo valore fra quelli forniti dal calcolo sulle terne di sensori ed allochiamo un vettore, definito vettore delle occorrenze, con un numero N di elementi pari a: 10 Gli indici di tale vettore rappresentano il range di valori misurati, percui, ad ogni indice dell’array possiamo associare un valore del range; la relazione che lega indice e valore è: ⁄10 L’elemento di indice i nel vettore delle occorrenze rappresenterà il numero di occorrenze del valore i fra i valori supposti per la coordinata. A questo punto viene riempito il vettore delle occorrenze e si determinano quelli che hanno numero massimo di occorenze; fra questi si sceglie quello nel cui intorno ricadono il maggior numero di Progetto cRIO | Mazza, Merlino, Messina occorrenze. Il raggio dell’intorno di valutazione è dato da 10 10 Il valore scelto corrisponderà alla coordinata finale dell’utente. Passiamo a valutare il peso 2 di un tale algoritmo. Il FIGURA 4: ESEMPIO DI ISTOGRAMMA DELLE OCCORRENZE. IN caso peggiore sarà lo stesso del precedente. Dal QUESTO CASO SI SCEGLIEREBBE IL VALORE 3.1. 2 Le simulazioni sono state effettuate mediante l’utilizzo di mappe a numero variabile di sensori tutti a distanza valida e fra i quali non vi siano mai tre sensori allineati. Simili mappe sono state ottenute attraverso la creazione di un algoritmo scritto in C che utilizza tecniche di generazione di punti pseudocasuali. Tali punti vengono condizionati a trovarsi a non più di una certa distanza da un punto le cui coordinate vengono fornite come parametri al programma ed inoltre viene fatto un controllo che assicura l’assenza di tre sensori allineati fra quelli generati. 8
  10. 10. punto di vista della complessità di calcolo, l’algoritmo risulta essere molto più leggero del precedente avendo eliminato il QuickSort; uniche “fatiche” richieste al processore sono quella di dover scorrere il vettore delle occorrenze (che può risultare abbastanza grande) e quella dovuta all’allocazione e alla deallocazione di spazio in memoria. L’occupazione di memoria dell’algoritmo sembra essere il suo punto debole si è per questo preferito utilizzare elementi del vettore delle occorrenze a 2 byte. Nel caso peggiore si avrà uno spreco di memoria pari ai 666,624 Kbyte dell’algoritmo precedente più una quantità variabile di memoria di difficile calcolo (si sono, tuttavia, potute osservare variazioni nell’occupazione di memoria fra i 700 Kbyte e 1-2 Mbyte). Per ovviare ad eventuali problemi dovuti all’eccessiva occupazione di memoria si è inserito un controllo che riduce l’accuratezza se il range dei valori supera una certa soglia. L’andamento dell’algoritmo non è strettamente legato al numero di sensori (sebbene continui ad essere influenzato da esso) ma risulta più influente sui tempi di calcolo la dimensione assunta dal range dei valori (affermazione verificata dal grafico 1). Sebbene l’andamento sia più oscillante si può facilmente notare come i tempi di calcolo si siano nettamente ridotti. Progetto cRIO | Mazza, Merlino, Messina GRAFICO 1 9

×