AIUTO CON UN PROGRAMMA

Per me per rilevare il primo pulsante che preme dopo l'accensione del led, bisogna controllare solo il primo fronte una sola volta... se uno ha premuto prima o continua a pigiare a raffica non va considerato. Una volta letto il risultato si riabilitano i pulsanti.

Buona l'obiezione della raffica
Ai miei tempi, coi relè, non ero riuscito a escluderla, ma solo per mancanza di voglia

Banale, basta squalificare i pulsanti trovati alti 'prima' della luce verde...

...e pensare che io a 12 anni feci una pulsantiera per quiz usando solo 2 pulsanti, 2 lampadine, un paio di relé (doppio deviatore, configurati per disattivarsi a vicenda al primo che si attiva)... :wink:

Io mi riferivo a quello, prima
Mi ricordo che ho usato gli interruttori del cruscotto di una 600 rottamata.
E le lampadine degli stop, avevo messo la lampada di un giocatore davanti all'altro. Così la lampada rossa indicava il perdente

Standardoil:
Banale, basta squalificare i pulsanti trovati alti 'prima' della luce verde...

Se si controlla solo la prima pressione, la squalifica avviene automaticamente.

p1dn = 0;  // segnali impulsivi alla prima pressione
p2dn = 0;

if      (mr)               {            p1ena = 1; }
else if (p1 & p1ena)       { p1dn = 1;  p1ena = 0; }
else                       {                       }

if      (mr)               {            p2ena = 1; }
else if (p2 & p2ena)       { p2dn = 1;  p2ena = 0; }
else                       {                       }

if      (mr)               { q1 = 0; }
else if (p1dn & led & !q2) { q1 = 1; }
else                       {         }

if      (mr)               { q2 = 0; }
else if (p2dn & led & !q1) { q2 = 1; }
else                       {         }

if (p1dn & p2dn & led)     { q1 = 1;  q2 = 1; }

'mr' è il master reset che abilita i pulsanti e azzera le uscite
'led' è il segnale di "via"
'p1' e 'p2' sono i pulsanti, 1=premuto
'q1' e 'q2' le uscite
...e permettiamo anche la parità :slight_smile:

Claudio_FF:
...
'mr' è il master reset che abilita i pulsanti e azzera le uscite
'led' è il segnale di "via"
'p1' e 'p2' sono i pulsanti, 1=premuto
'q1' e 'q2' le uscite
...

... a voi v'hanno rovinato i PLC :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

Ma ti paiono nomi di variabili da usare? Quelli sono i nomi dei morsetti a vite ... :grin: :grin: :grin:

Guglielmo

gpb01:
... a voi v'hanno rovinato i PLC :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

Che poi... secondo me se si iniziasse da subito a pensare un programma come per un PLC (logica a ciclo di scansione), non ci si troverebbe sempre inevitabilmente nelle peste con le operazioni bloccanti, delay ecc ;D

gpb01:
... a voi v'hanno rovinato i PLC :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

e mi sa pure le schede perforate :wink:
noto poi anche un tocco di design misto a feng shui nelle cose tipo:

else                       {         }

per avere tutti gruppi da 3 righe allineati e coperti per tenere ben aperti i chakra :stuck_out_tongue:

Per lo OP una domandina ina ina:
prevedi solo due concorrenti? oppure anche di più?

maubarzi:
per avere tutti gruppi da 3 righe allineati e coperti per tenere ben aperti i chakra :stuck_out_tongue:

In realtà quell'else vuoto è esplicitamente previsto nelle regole del barr-group... dopo un po' è come avere il berrettino in inverno :slight_smile:

Io purtroppo faccio molta ma molta fatica ad adeguarmi a certe pratiche.
Per me è innaturale spezzare in questo modo i vari test.
Però è una mia personale deformazione :wink:
E poi ci stava la battuta, in attesa che l'OP torni dalla latitanza :stuck_out_tongue:

Claudio_FF:
In realtà quell'else vuoto è esplicitamente previsto nelle regole del barr-group... dopo un po' è come avere il berrettino in inverno :slight_smile:

per la verità li specificano solo che l'else finale è obbligatorio dopo un else...if, non dopo un if semplice,

l'else vuoto lo capisco, fa intendere che non ci si è dimenticati un pezzo...
E' l'allineamento che in realtà aveva scatenato la mia curiosità e mi aveva fatto pensare al feng shui :wink:
Sinceramente, con quel tipo di formattazione, io faccio un po' di fatica a leggere il codice, non ci sono proprio abituato.
E anche il fatto di resettare a rate le varie variabili cozza con il mio modo di fare.
Io preferisco avere tutto assieme in una unica

if (mr)

e dentro nidificare il resto invece di spezzettarlo per funzionalità.
E' sicuramente più modulare come ha fatto @Claudio_FF ma io non mi ci trovo tanto.

Secondo il mio socio, secondo me, e anche secondo il barr_group citato da claudio, indentare in quella maniera è emendabile "proprio" perchè rende illeggibile il programma
citare per citare sono capace anch'io:
regola 3.3a Un solo statement per riga
regola 7.1e le variabili devono avere nome lunghi almeno 3 caratteri, anche i contatori dei cicli
e , rullo di tamburi, la regola più violata di tutte:
regola 1.3b le parentesi graffe aperte devono essere da sole su una riga all'inizio del blocco che aprono, le corrispondenti parentesi graffe chiuse devono essere da sole su una riga alla fine del blocco
Ora, io sono d'accordo che queste regole sono solo consigliate, ma citarne una, la più "nascosta", oltretutto citarla male, dopo aver disatteso tutte le altre non mi è sembrato bello, per nulla
Comunque, alla fine di tutto il pistolotto:
quel frammento di programma è "mal scritto", NON è un esempio di programmazione 'C'

Standardoil:
Secondo il mio socio, secondo me, e anche secondo il barr_group ....

Concordo al 100% su tutto quanto scritto d Standaroil; quel pezzo di codice è ... un ottimo esempio di come NON si devono scrivere i programmi. :grin:

Guglielmo

So benissimo che tutte le altre prescrizioni sono state violate, ma non so se scritto secondo esse sia davvero più leggibile, o meglio, comprensibile.

p1dn = 0;  // segnali impulsivi alla prima pressione
p2dn = 0;

if (mar)
{
    p1ena = 1; 
}
else if (pul1 & p1ena)
{ 
    p1dn = 1;  
    p1ena = 0; 
}
else
{
    // Nothing
}

if (mar)
{
    p2ena = 1; 
}
else if (pul2 & p2ena)
{ 
    p2dn = 1;  
    p2ena = 0; 
}
else
{
    // Nothing
}

if (mar)
{ 
    out1 = 0; 
}
else if (p1dn & led & !out2)
{ 
    out1 = 1; 
}
else
{
    // Nothing
}

if (mar) 
{ 
    out2 = 0; 
}
else if (p2dn & led & !out1) 
{ 
    out2 = 1; 
}
else
{
    // Nothing
}

if (p1dn & p2dn & led)
{ 
    out1 = 1;  
    out2 = 1; 
}

Secondo me a volte la concisione e gli allineamenti, purché riferiti a sezioni molto brevi, aiutano a non perdersi tra troppa "sintassi sparsa". Qui non c'è un grosso algoritmo strutturato, ma programmazione a basso livello (al di sotto restano solo le equazioni del ladder), ci sono quattro blocchetti funzionali molto piccoli e indipendenti che interagiscono tra loro tramite segnali (le variabili). Vedere ogni blocchetto in una piccola area rettangolare, formato da sezioni ben distinte e incolonnate (le condizioni, le azioni ecc) personalmente mi aiuta a non confondermi. Che stilisticamente non piaccia lo posso comprendere.

Scusa, ma seplificarlo e renderlo più leggibile (gli else vuoti si possono evitare del tutto, checché se ne dica) ?

p1dn = 0;  // segnali impulsivi alla prima pressione
p2dn = 0;

if (mar)
{
   p1ena = 1;
   p2ena = 1;
   out1  = 0;
   out2  = 0;
}
else
{
   if (pul1 & p1ena)
   { 
      p1dn = 1;  
      p1ena = 0; 
   }
   //
   if (pul2 & p2ena)
   { 
      p2dn = 1;  
      p2ena = 0; 
   }
   //
   if (p1dn & led & !out2)
   { 
      out1 = 1; 
   }
   //
   if (p2dn & led & !out1) 
   { 
      out2 = 1; 
   }
}

if (p1dn & p2dn & led)
{ 
    out1 = 1;  
    out2 = 1; 
}

Guglielmo

P.S.: ... sono partito dal tuo codice al post di sopra ... non so nenache cosa fa :smiley: :smiley: :smiley:

gpb01:
... gli else vuoti si possono evitare del tutto, checché se ne dica ...

Mi autoquoto per spiegare ...

Sia le MISRA C-2012, terza edizione Feb. 2019, rule 15.7, che il libro citato da Claudio-FF (libro che, se ben ricordate, sono stato il primo qui sul forum a consigliare), parlano di mettere sempre lo statemnt else solo nei casi di if ( ... ) .... else if ... e non nei casi di semplici di if in cui non c'è motivo di avere un else vuoto!

In pratica, citando appunto le MISRA C-2012:

A final else statement shall always be provided whenever an if statement is followed by a sequence of one or more else if constructs. The else statement shall contain at least either one side effect or a comment.

Per cui:

if ( flag_1 )
{
   action_1 ( );
}
else if ( flag_2 )
{ 
   action_2 ( );
}
/* Non-compliant */

... mentre occorre terminare con:

else
{
   ;   /* No action required - ; is optional */
}

Guglielmo

P.S.: il libro "Embedded C Coding Standard", al punto 8.2.d dice esattamente la stessa cosa .... "Any if statement with an else if clause shall end with an else clause.".

Beh, trasformiamo un problema in una opportunità: ne facciamo l'occasione per aprire un megatopic regole di stile?
Dove consigliamo come scrivere programmi in uno stile standard, condiviso da tutti noi?
E accompagnamo i neofiti a scrivere in una maniera che sia compatibile con esso
Da non doverci tutte le volte scontrare con programmi scritti con colla e forbici?

Orbene, vediamo SR ci riesco io, seguendo le regole del barrgroup

// inizializzazioni varie

void setup(){
// le varie pin mode


}


void loop(){
if(digitalRead(pulsante0))
{avvio=HIGH;
digitalWrite(lampada0,avvio);


}
if(digitalRead(pulsante1)){
if(avvio)
{// vince 1
digitalWrite(lampada1);
}
else
{// barava, vince 2
digitalWrite(lampada2);

stop();
}

E poi basta che col telefono non riesco