Go Down

Topic: analizzatore di spettro con display 128x64 (Read 2057 times) previous topic - next topic

z3us

Salve a tutti

sto cercando di dotare l'impianto stereo della mia auto di due semplici gadget, un voltmetro-amperometro e un analizzatore di spetto. Il primo gadget è stato veramente stupido da creare, è già pronto infatti....non appena li installo faccio un piccolo post dedicato, magari a qualcuno interessa!

ma l'analizzatore di spettro mi sta dando parecchie noie, anche dovute al fatto che ci sono due cose che non conosco e non ho mai usato, la prima è la FFT e la seconda il Display Grafico 128x64!

Tentando di scoprirne il funzionamento di entrambi, ho preso spunto da vari progetti in rete, ma anche avvicinandomi al risultato, non mi soddisfa!

Ecco il codice:


Code: [Select]
#include <ks0108.h>
#include <fix_fft.h>

#define AUDIOPIN 5


char im[128], data[128];
int i=0,val;



void setup() {
  GLCD.Init(NON_INVERTED); 
  GLCD.ClearScreen();
}


void loop() {

 
 
  for (i=0; i < 128; i++){                                     
    val = analogRead(AUDIOPIN); 
   
   
   
    data[i] = val;                                   
    im[i] = 0;                                                     
  };

  fix_fft(data,im,7,0);

GLCD.ClearScreen();


  for (i=0; i< 64;i++){                                     
    data[i] = sqrt(data[i] * data[i] + im[i] * im[i]);
     
     
      GLCD.FillRect(i*8, 0, 8, data[i], BLACK);
      //GLCD.FillRect(i*8, data[(i)+2], 8, 50, WHITE);
   }
   
}



Allora, la libreria del Display funziona, provata e tra provata, La FFT sembra fare il suo lavoro, l'Array viene caricato correttamente.

il nodo del problema sta nella visualizzazione, nei tempi di risposta e nel refresh!

Le barre appaiono, seguono la musica che "inietto" nel pin analogico, ma le barre sono in notevole ritardo. e per di più, non trovo un modo efficacie per evitare il tremendo sfarfallio delle barre dovuto ai tempi eccessivamente stretti di visualizzazione e cancellazione delle stesse.
Come potete vedere, ho provato con il ClearScreen, ma si vedono a stento tanto è rapida la cosa. Il secondo metodo che mi era venuto in mente è quello di creare i rettangoli fino all'altezza desiderata, poi continuarli con un'altro rettangolo ma WHITE, in modo da cancellare l'eventuale precedente!, la situazione migliora, ma lo sfarfallio è sempre evidentissimo!

Vi ringrazio per le eventuali dritte!


astrobeed

La vedo molto dura realizzare un visualizzatore di spettro, seppure nella fascia audio, scritto con Wiring, non solo la gestione del GLCD richiede molto tempo, ma anche la fft non scherza come impegno di tempo cpu.

z3us

Mah, Astro, ti dirò.....lo credevo anche io! ma una normale ricerca su google svela cose davvero interessanti! Da in tizio che con il codice che ho postato scrive addirittura su un televisore, a un'altro che invece pilota una Lol Shield.

La Fast_fft è veramente fast, non impiega moltissimo tempo, l'ho notato anche dal fatto che spostando il ClearSceen prima e dopo il risultato è quasi il medesimo.

inizio però a pensare che l'LCD sia il problema della lentezza!

Ci sarebbe da provare a costruire una Lol shield, ma al momento 126 led da 3mm non me li trovo proprio!

astrobeed


Da in tizio che con il codice che ho postato scrive addirittura su un televisore, a un'altro che invece pilota una Lol Shield.


Si, però è scritto in C con parti in Assembly, con Wiring te lo scordi di generare i giusti sincronismi riga/quadro e il dot clock per scrivere le righe video.

Quote

La Fast_fft è veramente fast, non impiega moltissimo tempo,


Sicuro di questa tua affermazione ?
La fft, anche se fast, richiede sempre un grosso impegno cpu.

Quote

inizio però a pensare che l'LCD sia il problema della lentezza!


Dipende anche da come lo controlli e da quanti pixel devi aggiornare ogni volta, comunque un GLCD 128x64 si riscrive almeno 10 volte al secondo senza problemi con un ATmega 328 e rimane tempo cpu per altre cose.
Io non ti ho detto che non è possibile farlo, ti ho detto che lo vedo molto difficile, se non impossibile con abbastanza velocità, farlo con Wiring, devi usare solo il C ANSI.


z3us


Si, però è scritto in C con parti in Assembly, con Wiring te lo scordi di generare i giusti sincronismi riga/quadro e il dot clock per scrivere le righe video.


Ah, non addentriamoci troppo con la programmazione, sono pur sempre a livelli "base"  :smiley-mr-green:

Quote
Sicuro di questa tua affermazione ?
La fft, anche se fast, richiede sempre un grosso impegno cpu.


No, ma che sicuro! figuriamoci, ho solo notato che con la Lol shield, nel video che ho visto, non si nota differita tra il brano musicale e l'andamento dei led! Certo, sono sicuro che per scopi puramente "Analizzativi" non si può usare a causa dei ritardi dei calcoli!

Quote
Dipende anche da come lo controlli e da quanti pixel devi aggiornare ogni volta, comunque un GLCD 128x64 si riscrive almeno 10 volte al secondo senza problemi con un ATmega 328 e rimane tempo cpu per altre cose.
Io non ti ho detto che non è possibile farlo, ti ho detto che lo vedo molto difficile, se non impossibile con abbastanza velocità, farlo con Wiring, devi usare solo il C ANSI.


Tiro fuori un'altra considerazione personale. Probabilmente il controllo dei display grafici è impegnavito. il controller a bordo del display deve pur sempre darsi da fare con 8000 punti! pertanto potrebbe essere questo il sostanziale problema del ritardo che vedo.


astrobeed


Tiro fuori un'altra considerazione personale. Probabilmente il controllo dei display grafici è impegnavito. il controller a bordo del display deve pur sempre darsi da fare con 8000 punti! pertanto potrebbe essere questo il sostanziale problema del ritardo che vedo.


Il controller di quei display è velocissimo, puoi aggiornare l'intero display tranquillamente più di 25 volte al secondo, il collo di bottiglia è Arduino (= Wiring) e la libreria utilizzata (da dove viene ?) che è sicuramente lenta.


astrobeed

Giusto come esempio qui trovi la descrizione di un progetto simile al tuo, con ottime caratteristiche tecniche, realizzato con un PIC 18F4550 (praticamente la stessa potenza di calcolo di un ATMEGA 328) e un display 128x64 con controller come il tuo.
Come puoi vedere nel breve video funziona senza problemi, puoi scaricarne il relativo codice e farne un porting sul 328, devi solo adattare la parte che gestisce i GPIO e gli ADC, il resto rimane invariato, poi lo compili tramite AvrStudio e la sua toolchain, ovviamente non ha nulla a che vedere con Wiring e l'IDE di Arduino  :)

z3us

Grazie Astro! gli darò un'occhiata! ;)

ora, come spesso accade, ci siamo voltati su un'altro progetto! :-D

ma probabilmente lo riprenderò! (Mi segno la pagina che mi hai suggerito!)

ƎR

interessava anche a me fare un analizzatore di spettro
cosa ne dite se invece di fare via software usassi qualcosa del genere: https://www.sparkfun.com/products/10306
che usa questo integrato: https://www.sparkfun.com/products/10468?

questo è il primo che ho trovato in giro, non so se c'è ne sono anche di meglio :smiley-sweat:

nel mio caso preferirei una soluzione hardware in particolare perchè sto lavorando con un tiny84 a 8MHz...
Riccardo Ertolupi of the Vicenza Thunders Team: http://www.VicenzaThunders.com

Go Up