Misure Elettriche ed Elettroniche

Prof. Bruno Andò

PROGETTO CRIO

Mazza Dario 616/002007

Merlino Sebastiano 616/002008

Messina Marco 616/002000

1

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.

Prog

etto

cRI

O |

Maz

za, M

erlin

o, M

essi

na

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.

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.

FIGURA 1: NI CRIO-9004

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

2

Prog

etto

cRI

O |

Maz

za, M

erlin

o, M

essi

na

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 I\O 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 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

3

Prog

etto

cRI

O |

Maz

za, M

erlin

o, M

essi

na

abbastanza complessa.

dispositivo FPGA;

Come funzionano le applicazioni sul cRIO ?

Un applicazione Real-Time e da due

Un'applicazione FPGA per l'input, l'output, la comunicazione ed il controllo;

nto e l'analisi dei

a priorità normale per data logging locale (I\O sulla memoria non volatile),

pendenza

d un PC tramite cavo ETHERNET è possibile eseguire i VI residenti sul controllore

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 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 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).

realizzata per essere eseguita sul cRIO è composta essenzialmentparti: 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 Time-Critical Loop per le operazioni in virgola mobile, il processame

segnali;

• Un Loopl'interfacciamento Web con pannelli remoti e la comunicazione ETHERNET o seriale.

I due loop vengono mappati sul sistema operativo come thread separati garantendone l'indidurante l'esecuzione. Solo il Time-Critical Loop è in grado di interagire con l'applicazione FPGA contenuta nei chip. Collegando il cRIO ae 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

4

Prog

etto

cRI

O |

Maz

za, M

erlin

o, M

essi

na

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 se

i tre moduli: NI 9215 BNC per l'input analogico (acquisizione

ma è l'applicazione FPGA e l'altra è il Virtual Instument che con

INPUT per l'acquisizione dei due segnali, il confronto con le soglie e output della somma dei

minazione dei led tramite output digitale.

sce in output al

a Vero per

La Trilaterazione: tecnica utilizzata

Nel software sviluppato durante il pr one dei soggetti

di sensori (ad ultrasuoni) all’interno di uno

mplice 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 ddei 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 priessa si va ad interfacciare. Usiamo un boolean per definire in quale delle due modalità deve lavorare l'applicazione FPGA (Vero: INPUT, Falso: LED):

•due segnali;

• LED per l'illu

La prima modalità prende come input i segnali dai moduli e le soglie dal VI e fornimodulo 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 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.

ogetto utilizzeremo una tecnica per l’individuazinello spazio detta MTA (Multiple Trilateration Algorithm). Si suppone di aver, innanzitutto, distribuito un numero N spazio chiuso e che ogni sensore fornisca come dato la distanza che lo separa dall’utente di cui si vuole rilevare la posizione.

5

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, p er mer ciascuna t na, delle matrice A e del vettore B tra ite 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 rilevata dal sensore. indicare la distanza

la:

· · ·

A questo punto utilizzando la formu

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.

Prog

etto

cRI

O |

Maz

za, M

erlin

o, M

essi

na

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.

Andiamodel softwIl VI è cattenda pverrà saluna mapA questodetermin manieIl “loop nche si determindeterminIn brevenumero occuperànelle vareventualCome giUna voltsuddettofornirà inverrà ritrMolto pisistema dIl Sub-VmanteneLe azioned il numfinale (caÈ stato, imappa d

Passiamocodice iposizioneSono staC per il chiamatovalori” spieghiamEntrambmatrice

o ora a spiegaware che sarà costituito da per 10 secondvata su file inpa precedent

o punto iniziainistico e l

era ciclica. non determinmuovono su

nistico” al finnistico” copiee, il “loop no

di sensori à dell’invio driabili Netwoi segnali di stià detto, il “lota che le vari

o loop, esse n uscita le crasmesso su riù semplice èdi trilaterazio

VI consiste inere la sincronni svolte VI somero totale dalcolata sul cRinoltre, realiei sensori, co

o ora a spiegin C ideatoe dell’utente

ate realizzate calcolo della

o, rispettivaed “a tag

mole in dettabe le soluziodelle posizio

are il funzion eseguito sul una Flat-Seqdi di riceverenvece, nel catemente salvaa l’effettivo soop non d

nistico” non ulla rete alne del calcoerà su rete i ron determinie li copierà delle coordinork. Altri comtop dei proceoop determiniabili real-timsaranno forn

coordinate derete, come spè il Sub-VI done esistente,n una semplnia con il cRIOono due. In

dei sensori al RIO) e l’evenzzato un VI dome vettore,

gare quale sio per calco. due differen

a trilaterazionamente, “a glio per

aglio. ni accettano

oni dei senso

namento effe cRIO.

quence divisae attraverso laso in cui la mata. scambio dati,

deterministi

fa altro che olle variabili olo di trilaterisultati ottenistico” otterr ripettivamennate della pompiti di cui iessi proveniennistico” si occme, contenennite come inell’utente oppiegato precedestinato ad e, fornendo unlice Flat-SequO. un primo mo VI di calcolontuale codicedi configuraz sulla rete.

ia la logica dlare l’effetti

nti soluzioni ne che abbiam taglio poccorrenze

in ingresso ri ed il vetto

ettivo del sist

a in più framla rete la mapmappa non ar

, che è costituico che andr

occuparsi de real-time erazione. Pernuti per reinvrà dalla rete nte in variab

osizione dell’l “loop non dnti dalla retecupa dell’effenti le distanzngresso al blppure, in casedentementeessere eseguin’interfaccia uence con im

omento essoo sul cRIO; sue d’errore. zione mappa,

Il codice Cdel iva

in mo

per e”;

la ore

FIGURA

tema da noi r

me. Nella primppa dei sensorrivi entro i 1

uito da due lranno ad ess

l trasferimenche, invecer ogni ciclo viarli al PC. il vettore di

bili real-timeutente su redeterministic ed inviare su

ettivo calcoloe ed il numelocco di calcso di irregolae, dal “loop nito sul PC. T per la comunmposta una

o invia l’arrayuccessivamen

che si occup

C

2: SOGLIE DI TA

realizzato occ

ma parte, si ori. Alla ricez10 secondi, v

loop definiti ere eseguiti

nto dei dati d, verranno terminato,

i distanze inv. Al terminete copiando

co” si occupau rete possibio di trilaterazero di sensorcolo realizzatarità, un codon determini

Tale Sub-VI vnicazione contemporizzaz

y di distanze nte, riceve la

pa, semplicem

AGLIO DELL’ALG

cupandoci, d

nota come izione della mverrà importa

rispettivamecontemporan

dalle variabiliutilizzate d

inoltre, il “l

viate dai sene del ciclo, le variabili Ra è quello di aili codici d’er

zione. ri, verranno pto in C. Tal

dice d’erroreistico”. va ad integran il cRIO. zione di 10 m

(ricevute daa posizione de

mente, dell’in

GORITMO PER V

dapprima,

il sistema mappa essa

ata da file

nte loop neamente

i network dal “loop loop non

sori ed il il loop si Real-time attendere rrore.

passate al le blocco

e. Il tutto

arsi con il

msec per

ai sensori) ell’utente

nvio della

ALORI

6

Prog

etto

cRI

O |

Maz

za, M

erlin

o, M

essi

na

7

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.

Prog

etto

cRI

O |

Maz

za, M

erlin

o, M

essi

na

FIGURA 3: PARTICOLARE DEL VI DI TRILATERAZIONE SUL CRIO

Passiamo ora a valutare il peso1 dell’algoritmo dal punto di vista dell’occupazione di memoria e della complessità di calcolo.

1 Vedi nota successiva

8

Prog

etto

cRI

O |

Maz

za, M

erlin

o, M

essi

na

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

vettore pari a 41664 avremo quindi una quantità di byte occupati pari a 666,62 kbyte.

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 edel rang ; 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.

FIGURA 4: ESEMPIO DI ISTOGRAMMA DELLE OCCORRENZE. IN

QUESTO CASO SI SCEGLIEREBBE IL VALORE 3.1.

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 occorrenze. Il raggio dell’intorno di valutazione è dato da

10 10 Il valore scelto corrisponderà alla coordinata finale dell’utente. Passiamo a valutare il peso2 di un tale algoritmo. Il caso peggiore sarà lo stesso del precedente. Dal 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.

9

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.

o, M

essi

na

GRAFICO 1

Prog

etto

cRI

O |

Maz

za, M

erlin