Curiosità

Buongiorno a tutti,

Ho scritto il seguente programma, l'intenzione era di scrivere in seriale una scritta ("spento" o "acceso") e di attendere di premere un tasto prima di ripetere il programma.

Mi funziona all'accensione, ma poi continua a ripetere la scritta senza più attendere che si prema un tasto.

int alt = 0;
const int v_ON = A0;

void setup() {
  pinMode(v_ON, INPUT); 
  Serial.begin(9600);
}

void loop() {

  if (digitalRead(v_ON)  == LOW) {
    Serial.println("Spento ");
  } else {
    Serial.println("Acceso ");
  }

  while (alt == 0) {
    delay(1000);
    
    if (Serial.available()) {
      alt = 1;
    }
  }

  alt = 0;
  Serial.println(alt);
  Serial.flush();
}

Probabilmente ci sono dei modi più semplici per ottenere lo stesso effetto, ma vorrei capire dove sbaglio!

Grazie anticipatamente per l'eventuale aiuto.

Enrico

Quando arrivano caratteri sulla seriale vengono messi nel buffer. Serial.available() ti dice quando appunto c'è qualcosa in questo buffer, ma non lo svuota, per cui il primo carattere sarà sempre lì e il tuo if sarà sempre verificato. Devi fare una Serial.read() finché non è vuoto, questa rimuove un carattere dal buffer.

Grazie SukkoPera, ero convinto di aver svuotato il buffer con Serial.flush()!!!

Saluti

enrico24:
Grazie SukkoPera, ero convinto di aver svuotato il buffer con Serial.flush()!!!

Da reference infatti la Serial.flush() "Waits for the transmission of outgoing serial data to complete."
Quindi ti serve per i dati in USCITA non in ingresso.

Grazie ancora del chiarimento.

Enrico

Ciao

io di solito evito gli ELSE...con programmi lunghi ...faccio fatica a gestirli.

Se proprio non ne vuoi fare ameno ti consiglio di usare un operatore ternario.......
e più facile da gestire.

Puso:
io di solito evito gli ELSE...con programmi lunghi ...faccio fatica a gestirli.
Se proprio non ne vuoi fare ameno ti consiglio di usare un operatore ternario.......
e più facile da gestire.

Si ma meno leggibile nel listato. E una volta compilato, produce lo stesso codice. Per cui...

Secondo me
con schetc lunghi diventa più leggibile,,,,,,,,almeno ELSE funziona solo il SUO.....di, IF non è corretto.

Puso:
Ciao

io di solito evito gli ELSE...con programmi lunghi ...faccio fatica a gestirli.

Se proprio non ne vuoi fare ameno ti consiglio di usare un operatore ternario.......
e più facile da gestire.

Operatore ternario più leggibile??? Mha ognuno ha le sue preferenze ma con più di un istruzione diventa veramene poco leggibile, identando correttamente e mettendo le graffe allineate in questo modo:

if(1==0)
{
   bla
   bla
}
else
{
  blu
  blu
}

direi che la leggibilità sia migliore poi ognuno programma come meglio gli torna

Temperatura==TemperaturaMedia && Umidita==UmiditaMedia?LettureDHT=1:LettureDHT=0;

fabpolli:
Operatore ternario più leggibile??? Mha ognuno ha le sue preferenze ma con più di un istruzione diventa veramene poco leggibile, identando correttamente e mettendo le graffe allineate in questo modo:

if(1==0)

{
  bla
  bla
}
else
{
  blu
  blu
}



direi che la leggibilità sia migliore poi ognuno programma come meglio gli torna

lo leggerebbe anche un bambino...molte righe per dire poco.

a lungo termine credo diventi più leggibile cosi

1==0 && 1==0? bla bla=1: blu blu=0;

Io le parentesi così proprio non le sopporto, in genere faccio così:

if(1==0) {
  bla
  bla
} else {
  blu
  blu
}

In questo modo ho la prima parentesi chiusa che spezza il codice.
Ovvio che se nidifichi le if a vari livelli diventa più complicato ancora, ma non penso che l'operatore ternario aiuti, anzi.

Poi, concordo che sia una questione personale come si scrive il codice.
Ci sono poi dei formattatori automatici per passare da uno stile all'altro, non so sull'ide di arduino ma su eclipse per java si ad esempio.

Per bla bla si intendono più righe di codice. Se l'istruzione è unica allora anche io uso l'operatore ternario in genere perchè più compatto.

Puso:
Secondo me
con schetc lunghi diventa più leggibile,,,,,,,,

Più leggibile no, può servire per avere il codice sorgente un poco più corto, ma non è evidente per nulla cosa fa in un caso o l'altro, devi cercare i separatori per capirlo.

almeno ELSE funziona solo il SUO.....di, IF non è corretto.

Che tradotto in italiano significa?...

maubarzi:
Io le parentesi così proprio non le sopporto, in genere faccio così:

Anche io, infatti...

Poi, concordo che sia una questione personale come si scrive il codice.

Questo è sicuro. Ma se lavori da solo puoi fare come ti pare, anche scriverlo in geroglifico (tranne poi riprendere un lungo listato scritto due anni prima, e perdere inutilmente parecchio tempo per capire cosa fa e perché, ma vabbé...), se però il listato lo deve leggere anche qualcun altro perché si lavora in gruppo (o anche solo per chiedere qui consigli su come modificare o correggere un programma) allora vedi che la gente ti manda a quel paese in 3, 2, 1.... :smiley:

proprio per evitare nidi
credo che il ternario sia meglio e con programmi lunghi,più leggibile.

mi piacciono questi scambi di parere-

... Puso ... il "ternario" è una assolutamnete poco leggibile, mettitelo in testa, e, in alcuni grossi progetti, in cui tanti ci devono mettere le mani, è anche tassativamente proibito, quindi ... :smiling_imp:

Guglielmo

docdoc:
se però il listato lo deve leggere anche qualcun altro perché si lavora in gruppo...

Questo è vero... in teoria... nella pratica non ho mai trovato casi dove la leggibliità fosse minata principalmente da questi problemi.
In genere i problemi di comprensione si hanno sull'uso di certe variabili o di architettura di base di come è strutturato il programma...
Reputo la scelta di if then else piuttosto che di operatori ternari piuttosto che di mettere le parentesi in un modo o in un altro (a me ad es. piace metterle sempre le graffe anche se nell'if c'è una sola istruzione) una questione marginale.
Lavorando su progetti grossi (milioni di righe) ho sempre trovato altrove i problemi di comprensione.

Diciamo che nella mia esperienza i problemi di comprensione derivanti da quanto detto fin qui li considero happy problem.

Ultima questione, scrivere per agevolare chi ti deve aiutare.
Verissimo.
Se si chiede aiuto sarebbe buona norma rendere il compito dei volenterosi più facile possibile.
Ma essendo la scrittura un fatto soggettivo, io non saprei a monte come scrivere un codice per incontrare le abitudini di chi leggerà.

Se lavori sul kernel linux ci sono degli standard di scrittura, se lavori su altri progetti ne trovi altri.
Se lavori in C ci sono certe abitudini, se lavori in Java altre. Ho visto un po' di tutto negli anni.

gpb01:
... Puso ... il "ternario" è una assolutamnete poco leggibile, mettitelo in testa, e, in alcuni grossi progetti, in cui tanti ci devono mettere le mani, è anche tassativamente proibito, quindi ... :smiling_imp:

Guglielmo

Ecco, appunto, per dire che certe scelte sono soggettive.
In altri è invece consigliato, dipende tanto dalle persone.

Fine pistolotto sbrodoloso e prolisso.
Pace

ok..ok...

mi scuso con tutti.

maubarzi:
Io le parentesi così proprio non le sopporto, in genere faccio così:

if(1==0) {

bla
 bla
} else {
 blu
 blu
}




In questo modo ho la prima parentesi chiusa che spezza il codice.
Ovvio che se nidifichi le if a vari livelli diventa più complicato ancora, ma non penso che l'operatore ternario aiuti, anzi.

Anch'io non le mettevo come le metto ora ma seguendo le regole del Barr group ho cambiato stile e devo dire che per me è diventato più leggibile il codice con le graffe isolate nella loro riga e se non erro anche le MISRA lo impongono. Ma come detto prima è anche questione di gusti se non imposto dal progetto

maubarzi:
... a me ad es. piace metterle sempre le graffe anche se nell'if c'è una sola istruzione ...

... in certi ambienti è anche richiesto ... es. la regola 15.6 delle MISRA C 2012 mostra chiaramente l'esempio:

if ( flag_1 )
  if ( flag_2 )
    action_1 ( );
   else
   action_2 ( );

... come NON Compliant e che la forma da usare è:

if ( flag_1 ) {
  if ( flag_2 ) {
    action_1 ( );
  }
  else {
    action_2 ( );
  }
}

Guglielmo

Guglielmo

addirittura proibito?????

In un mondo in cui è stupido parlare ad un autista mentre sta guidando......qualkuno me lo proibisce???

A volte fatico a comprendere.

fabpolli:
Anch'io non le mettevo come le metto ora ma seguendo le regole del Barr group ho cambiato stile e devo dire che per me è diventato più leggibile il codice con le graffe isolate nella loro riga e se non erro anche le MISRA lo impongono. Ma come detto prima è anche questione di gusti se non imposto dal progetto

Alla fine è una questione di abitudine.
Non penso ci sia in assoluto il modo giusto o sbagliato.

Io ho visto proliferare questo modo di mettere le parentesi in un periodo dove era diffuso pagare i programmatori a righe di codice scritto.
Parlo di circa 20 anni fa, quando mi affacciavo in questo strano modo della programmazione.
Sicuramente mi sbaglio ma ho associato subito le due cose...
Ho visto provare a mettere a capo anche il punto e virgola di fine istruzione...

Puso:
mi scuso con tutti.

con me non serve, secondo me hai il diritto di avere una tua preferenza del tutto legittima

gpb01:
... in certi ambienti è anche richiesto ... es. la regola 15.6 delle MISRA C 2012 mostra chiaramente l'esempio.....

Io lo faccio per un semplice motivo, quando ti capita di aggiungere la seconda istruzione, in genere non ti ricordi mai di mettere le parentese e KABOOOM.
Quindi non mi stupisce che alcuni abbiano istituzionalizzato la cosa per evitare questo tipo di errori oltre che per migliorare la leggibilità.

In genere certe regole sembrano delle pignolerie in realtà nascondono dei motivi più profondi.