debounce di 5 pulsanti

Salve, vorrei farvi una domanda se io ho 5 pulsanti e che quei 5 pulsanti fanno cose diverse come posso fare il debounce per tutti 5 e far cose diverse?.

Ecco il il codice .ino:

int ledPin =6;
int pulsantePin = 8;
int ledStato = LOW;
int pulsanteStato = LOW;
int attesaDebounce = 50;
unsigned long ultimoTempoDebounce = 0;
int ultimaLettura = LOW;

void setup(){
  pinMode(ledPin, OUTPUT);
  pinMode(pulsantePin, INPUT);
  digitalWrite(ledPin, ledStato);
  Serial.begin(9600);
}

void loop(){
  int lettura = digitalRead(pulsantePin);
  if(lettura != ultimaLettura){
    ultimoTempoDebounce = millis();
  }

  if((millis() - ultimoTempoDebounce) > attesaDebounce){
    if(lettura != pulsanteStato and lettura == HIGH){
      ledStato = !ledStato;
      digitalWrite(ledPin, ledStato);
     Serial.println(ledStato);
    }
    pulsanteStato = lettura;
    
  }

  ultimaLettura = lettura;

  delay(10);
}

ed in più come posso intercettarli dalla seriale essendo che sto comunicando con python e con uno solo ci riesco ma per far 5 pulsanti come devo fare?.

Non so come spiegarvi il problema in semplicemente vorrei chiamarli cosi: B1, B2, B3, B4, B5 e riconoscerli dalla seriale.

Avete idea come fare?
grazie mille.

I casi sono i seguenti

  1. Fai su ognuno dei 5 pulsanti un sistema di anti rimbalzo hardware
  2. Ti scrivi una funzione che fa la antirimbalzo software
    A) sul PIN che riceve come parametro puoi utilizzare questa funzione tua creata come una DigitalRead
    B) sui 5 pulsanti restituendo come valore di ritorno il numero del pulsante premuto ( puoi usare questa funzione come variabile in una switch case)

Per far capire al tuo programma scritto nell'altro linguaggio quale pulsante è stato premuto devi

  1. sapere scrivere in quell'altro linguaggio (o cercare un forum apposito)
  2. stabilire un protocollo cioè un insieme di regole di comunicazioni (esempio: ogni messaggio è composto da mittente, destinatario, numero di messaggio, Testo del messaggio fine e controllo)
  3. decidere Come avviene lo scambio di informazioni tra le macchine ( è Arduino che ogni volta che cambiano stato di un pulsante avverte ho è l'altra macchina che quando hai bisogno chiede? Esiste un meccanismo di feedback?)
  4. decidere se è come gestire l'errore (esempio: se è Arduino a prendere l'iniziativa Invia un messaggio ma non riceve feedback pur Se dovrebbe Riprova 3 volte a inviare lo stesso messaggio poi accende un led per dire che c'è stato un errore e attende intervento umano)
  5. adesso è solo adesso si può cominciare a pensare al messaggio vero e proprio, il cui contenuto Dipende dalle scelte fatte in precedenza

Chi te lo fa fare di sbatterti in righe di codice quando con cinque (5) condensatori da 0.1 e con una spesa attorno al mezzo euro (per tutti i 5 condensatori) hai già risolto il problema ?

si si , quasi con le librerie che accorciano il codice… tipo se cerchi su github, simple button library e simple led library vengono fuori librerie che hanno tutta la gestione che mi serve a me…

caso mai studio con calma e poi faccio il mio progetto che al meno lo posso fare benissimo con i kit di arduino che ho comprati.

ti ringrazio molto e buona settimana.

Per la lettura di un pulsante non serve una libreria! Per mettere 5 condensatori anti rimbalzo ci vuole un attimo, mentre farlo software è un'inutile complicazione e occupazione di memoria.

Datman:
... mettere 5 condensatori anti rimbalzo ci vuole un attimo, mentre farlo software è un'inutile complicazione ...

... NON solo, in caso i pulsanti un giorno debbano comandare degl interrupt, il "debouncing" software è proprio da evitare del tutto !!!

Guglielmo

Sì: il rimbalzo del pulsante è un difetto dello stesso, non dovrebbe esserci. E' giusto, quindi, fornire un segnale già corretto al microcontrollore, non affidargli un compito che non gli spetta! :slight_smile:

Eh, lo so, ma qui ho visto parlare di debouncing anche troppo!
E quindi, giù di software !
Poi ci meravigliamo che Windovs sia arrivato ad occupare Gigabytes...

Si ma l'OP non deve fare solo lettura e debounce, a lui serve anche l'edge detect, per cui alla fine tra debounce hardware e software cambierebbe una riga in più:

//-----------------------------------------------------------
// RILEVA PRESSIONI SENZA DEBOUNCE
//-----------------------------------------------------------
in = digitalRead(PIN_INGRESSO)
if (in != in_prec)
{
    in_prec = in;
    if (in == LIVELLO_PREMUTO) { ...rilevata pressione...  }
}
//-----------------------------------------------------------
// RILEVA PRESSIONI CON DEBOUNCE 20ms
//-----------------------------------------------------------
in = digitalRead(PIN_INGRESSO)
if (in == in_prec)             { tdeb = millis();          }
else if (millis()-tdeb > 20)
{
    in_prec = in;
    if (in == LIVELLO_PREMUTO) { ...rilevata pressione...  }
}

Comunque la soluzione delle librerie é soluzione (BRUTTA perché quella bella sarebbe hardware, ma quello non sembra si voglia cambiare) ad una sola delle due parti del problema, ovvero la più semplice, il debounce.
A questo punto é necessario pensare al problema più complesso: la comunicazione con un linguaggio di programmazione (perché con le macchine son capaci tutti :slight_smile: ). Per fare questo temo si torni al mio “piano in 5 punti” post 2. Come siamo messi a questo riguarda ciò?

Io non sono d'accordo col fatto di fare il debounce hardware, ci sono vari aspetti da considerare:

  1. il debounce hardware fatto coi condensatori potrebbe non sempre funzionare, e i condensatori col tempo si esauriscono. Magari ci vorranno 30 o anche 50 anni, ma potrebbero danneggiarsi in qualsiasi momento e provocare dei malfunzionamenti. Io nei miei progetti evito assolutamente i condensatori di debounce sui pulsanti

  2. il debounce software si può fare in mille modi diversi, tutto dipende dalle funzioni dei pulsanti

  3. il discorso dell'interrupt non ha tanto senso, perché non ha proprio senso abbinare un interrupt ad un pulsante che dev'essere premuto da un umano; un interrupt lo si usa più per intercettare segnali generati da altri circuiti, per esempio da un Hall-IC che legge un motore, o da una linea dati seriale, ecc.

Quindi io preferisco fare il debounce software, così posso decidere anche il tempo di debounce, e soprattuto avere un debounce sui pulsanti che lo richiedono e magari evitarlo per quelli che non lo richiedono. Ci sono dei pulsanti basati su bubble-contact che non fanno nemmeno il minimo bounce.

Se i tuoi 5 pulsanti non devono mai essere premuti contemporaneamente, puoi anche fare un debounce unico semplicemente ritardando leggermente l'esecuzione della funzione chiamata alla pressione del pulsante, poi ricontrolli se il pulsante è ancora premuto, in caso contrario esci dalla funzione.

  1. il debounce hardware fatto coi condensatori potrebbe non sempre funzionare

Perché mai, di grazia? ... Forse volevi dire che può accadere facendolo software.

e i condensatori col tempo si esauriscono.

I ceramici e quelli al poliestere non invecchiano mai, ai livelli a cui lavorano!

  1. il debounce software si può fare in mille modi diversi

Sì, l'antirimbalzo software si può fare in molti modi diversi, così come quello hardware: condensatore, condensatore e resistenza, con un transistor, con un buffer, con un inverter, con un flip flop... ma non vedo quale rilevanza possa avere ciò...

Resta il fatto che non c'è una ragione valida per scegliere di farlo software, tranne il non saper usare il saldatore! Poi, se devi produrre 100.000 apparati e i 2 centesimi di un condensatore diventano 2000€ a pulsante, mentre aggiungere qualche riga di programma, fosse pure a scapito delle prestazioni (tanto poi sono affari di chi l'ha comprato... >:( ), costa molto meno, allora è un altro discorso (e non è più argomento per questo forum amatoriale).

Datman:
Resta il fatto che non c'è una ragione valida per scegliere di farlo software, tranne il non saper usare il saldatore!

Il discorso si può anche vedere al contrario: se devo fare qualcosa di piccolo perché aggiungere cinque condensatori e dieci saldature quando grazie al software posso tranquillamente evitarli? Questo ovviamente nei casi in cui le prestazioni non risentano dei debounce, cosa che secondo me avviene nel 99% dei casi.

Di cose piccole ne faccio continuamente, e i condensatori, ormai, sono come granelli di sabbia!

Assolutamente d'accordo con Datman, ma capisco zioGuido: ognuno tira l'acqua al suo mulino (lui è un softwarista). Ma come dicevo all'inizio, se voglio una soluzione stabile e sicura vado a lavorare sull'hardware (quella dei condensatori che si scaricano in 30-50 anni sa molto di stridio di unghie sugli specchi, anche perché gli stessi pulsanti, che sono componenti "meccanici", durerebbero sicuramente di meno...).
Sarò all'antica, ma al wifi, dove posso, preferisco un buon cavo CAT5.

Certo, viviamo in un mondo dove fai prima a "dire" ad una macchina cosa deve fare piuttosto che progettarla per fare solo quel lavoro, poi però abbiamo gli "effetti collaterali".

Poi, fondamentalmente, odio passare ore davanti ad un editor a scrivere comandi fondamentalmente "inutili" e so già che se un giorno ci devo rimettere le mani avrò più problemi su un codice lungo piuttosto che su uno corto.
Poi nessuno parla mai di "appesantire" il processore: ho avuto modo di conoscere l'assembler, il linguaggio macchina, lavoro regolarmente su PLC in ladder e evito come la morte ST (Structured Text, che è un po' come il C su Arduino): se qualcuno vuole fare una gara a chi finisce prima un programma, sono a disposizione.
Ognuno ha i suoi "pro", ma ci si dimentica troppo spesso dei "contro".

Un consiglio ai softwaristi "puri"? Prendete in mano il saldatore una volta l'anno: avrete una marcia in più e sarete più completi.

Una volta l'anno?... Almeno un paio d'ore a settimana! :slight_smile:

Sarò all'antica, ma al wifi, dove posso, preferisco un buon cavo CAT5

Su questo non ci sono dubbi: i canali Wi-Fi sono tutt'altro che infiniti, perciò i segnali interferiscono, gli errori aumentano e la velocità diminuisce!

Datman:

  1. il debounce hardware fatto coi condensatori potrebbe non sempre funzionare

Perché mai, di grazia? ... Forse volevi dire che può accadere facendolo software.

Perché non tutti i pulsanti hanno lo stesso rimbalzo, potresti anche trovarti in una situazione in cui hai 20 tactile-switch tutti uguali ma alcuni rimbalzano più degli altri, e se sbagli i valori dei condensatori rischi che su alcuni pulsanti il tuo anti-rimbalzo non funziona.

Però avete ragione voi tutti su una cosa: qui si parla di una piattaforma amatoriale dove si salda una schedina ogni tanto per giocare, io invece ho in testa la progettazione per le produzioni in massa.
Pardon, errore mio.

steve-cr:
(quella dei condensatori che si scaricano in 30-50 anni sa molto di stridio di unghie sugli specchi, anche perché gli stessi pulsanti, che sono componenti "meccanici", durerebbero sicuramente di meno...).

Giusto, a questo non avevo pensato.

steve-cr:
Sarò all'antica, ma al wifi, dove posso, preferisco un buon cavo CAT5.

Ok, anche io preferisco il cavo CAT5, ma non vedo qui cosa c'entri...

steve-cr:
Un consiglio ai softwaristi "puri"? Prendete in mano il saldatore una volta l'anno: avrete una marcia in più e sarete più completi.

Ancora una volta... cosa c'entra? Sembra che si stia creando la faida: softwarista contro hardwarista. Scusa ma lo vedo assurdo.
Io il saldatore lo uso molto più di una volta l'anno, sto continuamente a progettare schede e saldare prototipi, e ti assicuro che se c'è qualcosa che il software può fare al posto dell'hardware, preferisco sempre la via software, perché in ogni momento posso cambiare qualcosa senza dover più modificare l'hardware. E non si tratta di "tirare acqua al proprio mulino" (questa espressione non si trova nel contesto giusto), si tratta di forma mentis, ognuno ha la sua.

se c'è qualcosa che il software può fare al posto dell'hardware, preferisco sempre la via software, perché in ogni momento posso cambiare qualcosa senza dover più modificare l'hardware.

Sulla comodità per fare modifiche, sono senz'altro d'accordo. Prima di Arduino, se dovevo aggiustare un valore dovevo pasticciare col saldatore, e dico pasticciare perché purtroppo ho fatto pochissima progettazione hardware per lavoro, mentre ho progettato e realizzato molto per hobby, abbandonando ben presto i circuiti stampati per le millefori.

ZioGuido, io parlavo di softwaristi "puri", quindi mi stai dando ragione, dato che non lo sei.
Molto semplicemente volevo far capire che non puoi fare tutto col software ma ti devi appoggiare all'hardware, PERO' non puoi fare tutto con l'hardware ma ti devi appoggiare al software (altrimenti torniamo indietro di anni...).

Se hai in testa la produzione di massa significa che hai un prodotto ormai STABILIZZATO, che è uscito dalla fase di prototipazione, quindi non hai più bisogno di correzioni hardware e tantomeno software.

Però io e te sappiamo bene che esistono le modifiche dell'ultima ora (quanti circuiti stampati con i filettini saldati e tenuti con gocce di silicone avete visto?) e "continue" modifiche software dell'ultimo.... anno !

Come vedi non sono né per l'uno né per l'altro, ma se per una normalissima correzione hardware preferisco mettere mano al software, beh....

P.S.
Anche io faccio un PLC industriale su base Arduino Nano, con quattro pulsanti tattili a lato del display 20x4: mai usato il debounce software e nemmeno hardware perché il programma è lungo e il tempo di reazione è, per forza di cose, aumentato. Anzi, certe volte devo premere il pulsante una seconda volta perché "non lo ha preso"....

Come vedi il debounce sarebbe stato tempo sprecato.