Carico di lavoro

Ciao ragazzi buondi a tutti.
Il mio post è rivolto ovviamente a tutta la community ma principalmente a chi ha alle spalle qualche anno di esperienza in più.
Faccio questa premessa semplicemente perchè, dato di fatto, l'esperienza ti porta ad aver incontrato - e valutato - sicuramente piu' ostacoli progettuali.

Andando al topic:
Nella logica di studio e sviluppo di un progetto quali variabili sono da tenere in considerazione per calcolare se il carico di lavoro per una singola shield è eccessivo o se conviene utilizzare piu' shield?

Mi spiego meglio.
Un progetto che prevede l'interrogazione ed elaborazione di diversi input di ingresso con loop continui e di diversa natura (segnali gps, dati gprs, analogici, digitali, etc etc), quindi con tempi di risposta piu' o meno differenti, è consigliabile dividerli su piu' shield "dedicate" oppure su unica?

Sintetizzando:
Quando conviene (se conviene) utilizzare piu' shield da dedicare a singoli cicli?

Grazie mille.
Salvo G.

Tutto dipende dai "TEMPI" di acquisizione/risposta di cui necessiti e ... dal budget ...

... se devi controllare la temperatura di 10 stanze e fare un report ... un unico Arduino è più che sufficente, tanto la velocità con cui cambia la temperatura in una stanza NON è certo un fenomeno che richieda una elaborazione "real time"; se invece dei controllare processi molto più veloci, devi farti i conti e vedere se la singola MCU è in grado di garantirti i tempi di acquisizione richiesti ed i relativi tempi di reazione ed, eventualmente, o scegliere una MCU di una certa fascia che ti garantisca certe velocità e capacità o suddividendo il carico di lavoro su più MCU più piccole.

Quindi ... si deve valutare caso per caso, analizzando le esigenze e valutanto i tempi richiesti senza dimenticare ... la valutazione dei "costi" :wink:

Guglielmo

Ciao,
la logica di Arduino è asincrona, quindi in ogni caso le acquisizioni sono sequenziali una dopo l'altra.
Il limite e dato dalle varie memorie interne di arduino, ma già se riesci a compilare e caricare lo schetch sulla scheda non dovresti avere problemi.

la velocità reale del convertitore analogico-digitale di arduino UNO, senza toccare il prescaler. è 9,6kHz ovvero 9600 acquisizioni analogiche al secondo.

se non devi fare cose particolari, tipo leggere segnali sinusoidali a varie frequenze, non mi porrei il problema della velocità di acquisizione e calcolo,,,ma potrei non aver capito il nocciolo del tuo problema, dimmi tu

Edit:
una cosa che mi viene in mente. Se puoi lascia stare le shield (io non sono amante) l'ideale nel tuo caso sarebbe una implementazione via I2C, se possibile

Ciao ragazzi grazie per le preziose informazioni.

Muplex:
se non devi fare cose particolari, tipo leggere segnali sinusoidali a varie frequenze, non mi porrei il problema della velocità di acquisizione e calcolo,,,ma potrei non aver capito il nocciolo del tuo problema, dimmi tu

In realtà sono nella fase "studio", non ho progetti attivi sulla quale sto lavorando ma sto mettendo insieme tutte le informazioni in mio possesso cercando risposte ai quesiti che mi vengono in mente.
Nello specifico il mio dubbio era rivolto al fatto se esistesse un punto di carico massimo per cui logiche di sviluppo consiglierebbero di utilizzare più arduino e poi avviare comunicazioni I2C master/slave.

Mi domandavo se valesse la pena - ad esempio - dedicare un arduino nano per gestire la parte GPS/GPRS ed uno per gestire gli altri cicli.

Dalle vostre risposte comunque - correggetemi se sbaglio - credo di aver capito che comunque sono ragionamenti sulle prestazioni che vanno fatti post sviluppo e comunque tenendo conto dei costi.

Grazie mille!

tatino:
... sono ragionamenti sulle prestazioni che vanno fatti post sviluppo e comunque tenendo conto dei costi.

No, dopo lo sviluppo no, ma dopo avere le idee chiare su cosa si vuole fare SI !

Quindi, prima capire bene COSA si vuole fare e che tempistiche sono coinvolte, dopo fare lo sviluppo del progetto.

Guglielmo

Puoi farti una idea cercando con google
embedded soft-realtime, hard-realtime, mission critical, time critical, ecc.
In genere la maggior parte delle applicazione rientrano nella categoria soft-realtime dove il fallimento dei vincoli temporali richiesti non hanno conseguenze disastrose (tipo l'aereo che cade).

Quando si decide per più di una MCU preferisco SPI a I2C, in questo caso può tornare utile documentarsi su come assegnare compiti a MCU ed essere notificati da questa durante l'esecuzione.
Certo che coordinare 3 MCU già può essere molto impegnativo dipende dal tipo di applicazione.

Ciao.

Semplicemente, devi verificare di avere le risorse necessarie: pin, ram, interrupt, tempo, ecc. e che le varie attività non interferiscano tra di loro, ad es. una comunicazione bloccante che richiede 10s è incompatibile con un display che deve visualizzare lo scorrere dei secondi.
Hai sufficienti interrupt per gestire tutte le cose che vanno gestite immediatamente senza perdite di tempo? Ad es. la lettura di un encoder dove non devi assolutamente perdere letture.
Le operazioni bloccanti più lunghe, sono compatibili con i tempi di ritardo nell'esecuzione di tutte le altre attività?
La corrente circolante per gestire tutti i carichi collegati, è entro i limiti dell'hardware?
Hai sufficiente memoria per tutto? Sia flash per lo sketch che sram per le variabili?
Insomma, hai capito cosa intendo, devi verificare i punti critici e vedere se ti sballano qualcos'altro.
Ovviamente buona parte degli aspetti emersi con le precedenti domande, si possono risolvere senza ricorrere a più MCU, ma il concetto e l'approccio di analisi resta valido, magari non emerge il fatto di dover usare più MCU ma dispositivi diversi per gestire altri problemi, ad es. uno shift register per gestire più uscire o un multiplexer per lo stesso motivo.

Tieni poi presente, che mettere in comunicazione tra di loro più MCU, non è cosa banale, per cui va gestita sempre con un minimo di attenzione.

Il mio consiglio è di sperimentare in modo mirato dove pensi ci possano essere criticità.

Maurizio