Pulsanti di debouncing

Di recente ho letto un articolo sul rimbalzo dei pulsanti e mi chiedevo se avrei dovuto tenerlo a mente quando lavoro con, ad esempio, un Arduino (ATMega mC)? Presumo che sia un problema, specialmente quando si lavora con gli interrupt.

Quindi è meglio rilevare il rimbalzo nel codice o questo dovrebbe essere curato con l'hardware? Per favore, elabora.

Consiglio vivamente di collegare un ambito (si spera che tu ne abbia uno o che tu ne possa mettere uno da usare) fino al tuo interruttore. Ho visto un progetto di uno studente che ha avuto un rimbalzo sul suo interruttore che è passato da 5v fino a -5v fino a 4v fino a -3v, quindi fino a 2v, quindi di nuovo a 0v. Quando abbiamo osservato l'attuale disegno su un ambito, si è verificato un picco molto grande.

Nel suo caso particolare, era molto necessario che rimbalzasse il suo interruttore sull'hardware.

Tuttavia, d'altra parte, ho visto interruttori che hanno un effetto molto più piccolo che potrebbe essere facilmente rimosso dal software.

Tuttavia, devi valutare le tue opzioni. Se disponi di una quantità di firmware molto complessa, aggiungere l'overhead sia come programmatore che l'utilizzo della CPU potrebbe non valerne la pena e sarebbe meglio aggiungere solo un po 'di hardware. D'altra parte, se stai cercando di ridurre i costi e le dimensioni, ti consigliamo di rimuovere quanto più hardware possibile e fare tutto nel firmware se puoi.

Se sei un designer di elettronica professionale, è probabile che il tuo capo non ti permetta nemmeno di farlo nell'hardware. Il motivo è semplice: se il batch di produzione è abbastanza grande, il software è praticamente gratuito , mentre l'hardware deve essere pagato per ogni unità prodotta. E mentre resistori e condensatori sono a buon mercato, il loro montaggio su un PCB può costare fino a 20 volte il loro prezzo di acquisto.

Sia che si rimbalzi nel software o nell'hardware, è comunque necessario selezionare pulsanti di qualità. Il famigerato pulsante da 157ms dell'articolo non è adatto a nessuna applicazione.
Di solito campiono il pulsante a intervalli di 32 ms , il che è sufficiente per colmare il tempo di rimbalzo di qualsiasi buon pulsante. Sono un grande fan degli switch SKQG TACT di Alps .

Sui pochi dispositivi che ho testato aveva un tempo di rimbalzo iniziale inferiore a 10 ns. Sebbene abbia una durata operativa di 100000 cicli, lo abbiamo testato 200 000 cicli e anche allora il 32ms debouncing era sufficiente. (Immagino che avrei dovuto misurare il livello effettivo di rimbalzo, ma il nostro interesse principale all'epoca era il comportamento del prodotto finale. Comunque, lo stavamo usando fuori specifica.)

Se vuoi davvero una soluzione hardware, secondo la soluzione flip-flop SR menzionata nell'articolo come la soluzione tecnicamente migliore:

Il flip-flop può essere costruito con una doppia porta NAND , disponibile ad esempio in un piccolo pacchetto VSSOP8. Il principale svantaggio di questa soluzione è la necessità di un pulsante SPDT, in cui SPST è molto più comunemente disponibile.

Esistono molti (e molti) modi diversi di rimbalzare i pulsanti. Se lo fai in software o hardware dipenderà dai requisiti del tuo progetto e dal tipo di switch.

Ecco alcuni link a diversi metodi:

http://www.ganssle.com/debouncing.htm

http://hackaday.com/2010/11/09/debounce-code-one-post-to-rule-them-all/

Quell'articolo è la "bibbia" sul rimbalzo. Il rimbalzo del contatto può essere un problema con qualsiasi applicazione.

In genere è meglio rimbalzare gli interruttori nel software in quanto è più facile regolare i ritardi per determinati interruttori, poiché differiscono nella quantità di rimbalzo dei contatti. Spesso è anche necessario rimandare il rilascio della chiave. I produttori di switch spesso specificano la quantità di rimbalzo per i loro prodotti, in genere si aggira intorno ai 10ms - 20ms.

Il cambio di rimbalzo può andare avanti per decine di millisecondi. Se stai eseguendo il polling di uno switch da una routine di interrupt che viene eseguita su un timer, il rimbalzo non sarà un problema, perché anche se ti capita di eseguire il polling dello switch nel mezzo di una tempesta di rimbalzo, ottieni subito il nuovo stato o, nel peggiore dei casi, ottenere il vecchio stato e non vedere il nuovo stato fino al prossimo sondaggio basato sul timer. Il polling da un ISR temporizzato come questo costituisce una forma di rimbalzo del software.

Tuttavia, se si utilizza tale switch per causare l'interruzione e si prevede che la routine del servizio di interrupt venga eseguita rapidamente, in meno di 10 millisecondi, sarà necessario il debounc dell'hardware, altrimenti un evento switch potrebbe comportare un numero alquanto casuale di interrompe, e sicuramente spesso più di quello previsto. D'altra parte, se la routine di interruzione dura abbastanza a lungo, il rimbalzo dell'interruttore si risolverà prima che l'ISR finisca e andrà bene, ma gli ISR ​​ben costruiti non impiegheranno così tanto tempo.

Il modo migliore per fare qualsiasi cosa è il modo più adatto a te. Ma quando hai già un microcontrollore puoi rimbalzare nel software al solo costo di un po 'di sforzo sul codice.

Il modo più logico di rimbalzare nel software è di controllare i pulsanti in momenti che sono più distanti rispetto al tempo di rimbalzo più lungo. 50 ms sembra essere un limite superiore al tempo di rimbalzo degli switch "normali", quindi quando puoi organizzare il tuo software in questo modo sei in chiaro:

forever loop
   wait (at least) 50 ms
   check buttons
   do procesing
end loop

Un approccio al rimbalzo che non è stato ancora menzionato è quello di utilizzare un interruttore a doppio lancio con un tiro legato a VDD e l'altro a terra. Inseriscilo in un pin che (tramite software o hardware) verrà debolmente portato allo stato attuale. Tale approccio fornirà i vantaggi di un interruttore a doppio lancio, ma richiederà solo un pin I / O anziché due.