inserire cose "evitabili" in uno sketc provoca rallentamenti?

es "raggruppare " 3 schetch in uno solo per 3 hardware diversi usando quasi tutta la memoria di arduino
ovviamente ogni sketch viene selezionato dal suo pin messo a massa

esempio pratico:

lo stesso hardware funziona come
1 timer secondi+minuti
2 timer ore+minuti
3 termostato

selezionabile esternamente tramite Jumper

il fatto che due dei 3 programmi vengono caricati ma mai usati possono rallentare le prestazioni?

elrospo:
il fatto che due dei 3 programmi vengono caricati ma mai usati possono rallentare le prestazioni?

Le prestazione sono influenzate solo dal codice in esecuzione e l'impegno delle risorse.
Se hai del codice che viene eseguito solo in presenza di una condizione, situazione abbastanza normale in un programma, questo non influisce in nessun modo sul lavoro del micro salvo impegnare flash ed, eventualmente, della ram se ci sono delle variabili globali inserite solo per quelle porzioni di codice.

Se vogliamo andare a fare i puntigliosi:
Le 3 parti di sketch di cui viene eseguito solo uno é leggermente piú lento rispetto una parte sola perché farai in qualche modo un if nel loop per attivare solo una delle tre parti.

Il tempo che serve per eseguire quel if é quello che determina la differenza di tempo che comunque é minimo e non rilevante nel esecuzione dello Sketch.

setup()
{
leggere le entrate per selezionare sketch e memorizzarlo in variabile stato;
}

loop()
{
if (stato == 0)
  {
   parte 1;
   ...
  }
if (stato == 1)
  {
   parte 2;
   ...
  }
...

}

Il tempo che perdi in questo modo é molto inferiore non adattando certe soluzioni di programmazioni che come principiante non conosci. Giá il digitalRead() rispettto una lettura del pin diretta perde piú tempo che il if.

Ciao Uwe

Io farei in modo leggermente diverso:

setup()
{
leggere le entrate per selezionare sketch e memorizzarlo in variabile stato;
}

loop0() {
  // ...
}

loop1() {
  // ...
}

loop2() {
  // ...
}

loop()
{
switch (stato) {
  case 0:
    loop0();
    break;

  case 1:
    loop1();
    break;

  case 2:
    loop2();
    break;
}

Potrebbe essere ancora più veloce, a seconda di quel che combina il compilatore. Per andare più veloce ancora di così si potrebbe eliminare l'if/switch con un puntatore a funzione o un uso furbo della programmazione ad oggetti, ma credo che sia tutto decisamente superfluo, già con la soluzione di uwe la differenza deve essere negligibile!

SukkoPera:
Io farei in modo leggermente diverso:
.
.
.
superfluo, già con la soluzione di uwe la differenza deve essere negligibile!

Se le tre parti di codice devono essere eseguite in funzione di una condizione all'avvio, p.e. un pin collegato ad un ben preciso stato logico, il modo migliore è gestire la cosa dentro la setup, lasciando la loop() vuota, con avvio della relativa parte di codice che sarà composta da una funzione dedicata con al suo interno una while(1), prende il posto della loop(), al cui interno viene eseguito il compito assegnato.

@elrospo
Hai visto;
Hanno giá trovato 2 modi piú veloci del mio suggerimento, dove quello di astrobeed é veloce come la loop() originale.

Ciao Uwe

Astro ha ragione, si risparmia una ulteriore chiamata di funzione ad ogni loop, il che equivale a qualche microsecondo :).

uwefed:
... dove quello di astrobeed é veloce come la loop() originale.

In realtà mettere un while(true) { .... } nella setup() invece che usare la loop(), alla fine è un bel po' più veloce ...

... primo perché si evitano le push/pull nello/dallo stack ad ogni chiamata della loop() (che, vi ricordo, viene chiamata in continuazione da un ciclo for) ed inoltre si evita anche la parte : if (serialEventRun) serialEventRun(); anch'essa eseguita in continuazione dal for, che introduce un altro ritardo.

Oh, ovviamente, in questo modo, si perde la possibilità di usare la Serial.serialEvent() :wink:

Guglielmo

gpb01:
Oh, ovviamente, in questo modo, si perde la possibilità di usare la Serial.serialEvent() :wink:

Vero, però nulla vieta di inserire " if (serialEventRun) serialEventRun();" all'interno del proprio ciclo dedicato.
Se poi si perde un attimo di tempo per scriversi una propria funzione per la gestione, sotto interrupt, della ricezione dati sulla seriale è meglio perché in questo modo non serve quell'antipatico, sciupone di cicli macchina, polling. :slight_smile: