sto cercando di ottimizziare la lettura di un canale analogico con arduino, in questo momento ho a disposizione arduino uno leggendo solo il canale arrivo a 20 microsecondi, i tempi si allungo facendo un po' di analisi fino a 40 -100 microsecondi (secondo il tipo di analisi), se acquistassi arduino mega 2560 i
tempi potrebbero migliorare ?
Piu che altro spiegaci tu cosa vuoi realizzare e come mai hai bisogno di cosi tanti campionamenti al secondo. 10000 campionamenti al secondo non sono pochi.
Devo monitorare dei transienti di un dispositivo al microsecondo, potrei usare un oscilloscopio, ma questo non mi permette di fare delle operazioni matematiche solo vedere il segnale, mi sono avventurato su arduino perche' conosco la programmazione in C.
Si ma dubito se ne trovino con buffer molto capienti, quei dati poi li devi portare su Arduino e a quel punto perdi tutto il tempo risparmiato con un adc piu performante.
@RobertoBochet metti che colleghi l'adc direttamente ad arduino in modo da utilizzare al massimo due porte, per leggere entrambe le porte impieghi meno di 1us, poi lo salvi in un buffer e diciamo che ad esagerare impieghi 1.2/1.5 us per ogni lettura.
Trovare adc cosi potenti a basso costo non è per niente facile! il buffer non è obbligatorio, ovvio che se rimani circoscritto alla digitalRead() pare impossibile!
Volendo poi esagerare si potrebbe creare uno schema con un adc potentissimo e tante fifo controllate da clock esterno ed arduino che le rincorre a leggere i dati e visualizzare, in questo modo puoi raggiungere benissimo velocità elevate ma a discapito di un gap tra lettura reale e visualizzata anche nell'ordine dei secondi.......ma a questo punto si fa prima a prendere una cpu piu performante ma con sempre un adc esterno.
Gli ADC dei MC o dei periferiche seriali raramente superano i 200KSPS, per arrivare a 1MSPS puoi usare un ADC parallelo(flash) ad esempio il TLC5510 arriva a 20MSPS , ovviamente stiamo al massimo sui 8bit altrimenti i costi vanno sù, comunque anche i seriali possono arrivare molto alti
vbextreme: @RobertoBochet metti che colleghi l'adc direttamente ad arduino in modo da utilizzare al massimo due porte, per leggere entrambe le porte impieghi meno di 1us, poi lo salvi in un buffer e diciamo che ad esagerare impieghi 1.2/1.5 us per ogni lettura.
Si, allora un leggero miglioramento si riesce a raggiungere, ma forse allora è meglio più concentrarsi sulla analisi, no? Con un rapporto di 1:4 quella meriterebbe un cambio di microcontrollore, magari passando a un arm a 32bit? Bisogna vedere anche se si necessità di calcoli in virgola mobile.
@RobertoBochet non ha specificato che calcoli e come vuole campionare e visualizzare i dati, quindi si e' solo parlato in generale, non è detto poi che serva un arm, ci sono chip a 8 bit potentissimi con un mucchio di ram, vedi il pic18fxxkxx
La serie 18 dei PIC è paragonabile agli AVR come potenza di calcolo e velocità operativa, il loro vantaggio è che esistono modelli altamente verticalizzati per specifiche applicazioni, p.e. il controllo motori, e semplificano non poco la vita in fase di progetto.
Il motivo per cui nelle piccole mcu 8 bit, tutte, gli ADC sono tipicamente da 10 bit con sample rate massimo compreso tra 25 ksps e 100 ksps è perché i dati campionati vanno pure gestiti in un qualche modo ed è inutile avere un ADC da 1 Msps se poi non sei in grado di elaborare i dati in tempo reale, rammento che un AVR mediamente richiede 125 ns, due cicli macchina, per oltre la metà delle istruzioni assembly, alcune richiedono fino a quattro cicli macchina, alla fine in un 1 us si riescono ad eseguire da 5 a 10 istruzioni assembly a seconda della loro tipologia, tra leggere i port, acquisire i dati su un sfr, trasferirli in un buffer ram, ipotizzo una elaborazione post acquisizione, siamo veramente al limite di una mcu 8 bit di ultima generazione.
Se c'è la reale esigenza di acquisire dati analogici a 1 Msps e oltre meglio andare su mcu più performanti, p.e. i dsPIC che possiedono ADC a 12 bit in grado di campionare ad oltre 1 Msps, fino a 4 Msps su alcuni modelli di dsPIC, e sono perfettamente in grado di gestire i dati in tempo reale grazie al DMA e il ciclo macchina di solo 25 ns.
Quasi tutte le istruzioni assembly dei dsPIC richiedono un singolo ciclo macchina e la word è 16 bit il che consente di acquisire dati a 10-12 bit con una singola operazione.
Se poi mettiamo sulla bilancia il core DSP e l'unità matematica che esegue moltiplicazioni e divisioni, tra numeri interi, in hardware, la gestione hardware dei numeri a virgola fissa ecco che con i dsPIC diventa possibile "macinare" grosse mole di dati in tempo reale, il tutto con un micro che costa da 5 a 8 Euro (prezzi per pezzi singoli) a seconda del modello.
vbextreme: @RobertoBochet non ha specificato che calcoli e come vuole campionare e visualizzare i dati, quindi si e' solo parlato in generale
Se arriva ad impiegare 100mus non fa solamente una somma o una sottrazione, è probabile che implementi operazioni più complesse, un classico dei campionamenti è la divisione che quasi sempre è in virgola mobile, quindi un processore che sia in grado di fare calcoli HW in virgola mobile può portare molti più giovamenti di un adc più rapido. Bisogna localizzare ed eliminare il collo di bottiglia, puoi anche avere un Ferrari ma se la guidi sulle strade di campagna non arriverai lontano.
Ti faccio notare che io parlo sempre per ipotesi, se l'utente non mette dei paletti io parto dalle situazioni più probabili.
Vedo che astro ha già proposto un alternativa più performante non solo in termini di raccolta dati.