Hace poco leí un artículo sobre el debouncing de botones y me preguntaba si debería tener esto en cuenta al trabajar con, por ejemplo, un Arduino (ATMega mC)? Supongo que es un problema, especialmente cuando se trabaja con interrupciones.
Entonces, ¿es mejor detectar el rebote en el código, o debería ser cuidado con el hardware? Por favor, elabore.
Recomendaría encarecidamente conectar un visor (espero que tenga uno o pueda hacer uso de uno) hasta su interruptor. He visto el proyecto de un estudiante que tuvo un rebote en su interruptor que pasó de 5v a 5v hasta 4v a -3v, luego a 2v y luego a 0v. Cuando miramos el dibujo actual en un alcance, hubo un pico muy grande.
En su caso particular, era muy necesario que él renunciara a su cambio de hardware.
Sin embargo, por otro lado, he visto interruptores que tienen un efecto mucho menor que podrían eliminarse fácilmente en el software.
Sin embargo, necesitas sopesar tus opciones. Si tiene una cantidad de firmware muy compleja, puede que no valga la pena agregar la sobrecarga tanto para usted como programador como para el uso de la CPU y sería mejor que solo agregue un poco de hardware. Ahora, por otro lado, si está intentando reducir costos y reducir el tamaño, querrá eliminar la mayor cantidad de hardware posible y hacerlo todo en firmware, si puede.
Si eres un diseñador de electrónica profesional, es probable que tu jefe ni siquiera te permita hacerlo en hardware. El motivo es simple: si su lote de producción es lo suficientemente grande, el software es virtualmente gratuito , mientras que el hardware debe pagarse por cada unidad que produzca. Y mientras que las resistencias y los condensadores son muy baratos, montarlos en una PCB puede costar hasta 20 veces su precio de compra.
Tanto si realiza rebotes en software como en hardware, todavía tiene que seleccionar botones de calidad. El infame botón de 157 ms del artículo simplemente no se ajusta a la aplicación a ninguna .
Normalmente muestro el botón en intervalos de 32 ms , lo cual es suficiente para salvar el tiempo de rebote de cualquier botón bueno. Soy un gran fan de la Alps SKQG Interruptores TACT.
Enlospocosdispositivosqueprobéteníauntiempodereboteinicialdemenosde10ns.Sibientieneunavidaútilde100000ciclos,loprobamosenciclos200000einclusoenesecaso,elrebotede32msfuesuficiente.(Supongoquedeberíahabermedidoelnivelrealderebote,peronuestrointerésprincipalenesemomentoeraelcomportamientodelproductofinal.Detodosmodos,loestábamosusandofueradeespecificaciones).
Sirealmentedeseaunasolucióndehardware,secundolasolucióndeflip-flopSRmencionadaenelartículocomolamejorsolucióntécnica:
El flip-flop se puede construir con una doble puerta NAND , que está disponible en una pequeña El paquete VSSOP8, por ejemplo. El principal inconveniente de esta solución es que necesita un botón pulsador SPDT, donde SPST es mucho más comúnmente disponible.
Ese artículo es la "biblia" en la publicación de anuncios. Contact bounce puede ser un problema con cualquier aplicación.
En general, es mejor deshacerse de los conmutadores en el software, ya que es más fácil ajustar los retrasos de los conmutadores en particular, ya que difieren en la cantidad de rebote de contactos. A menudo, también es necesario denunciar el lanzamiento clave. Los fabricantes de interruptores a menudo especifican la cantidad de rebote de sus productos, por lo general es de aproximadamente 10 ms - 20 ms.
El rebote del interruptor puede continuar durante decenas de milisegundos. Si está encuestando un interruptor desde una rutina de interrupción que se ejecuta en un temporizador, el rebote no será un problema, porque incluso si se enciende el interruptor en medio de una tormenta de rebotes, puede obtener el nuevo estado de inmediato. , o en el peor de los casos obtener el estado anterior, y no ver el estado nuevo hasta la próxima encuesta basada en temporizador. El sondeo de un ISR cronometrado como este constituye una forma de rebote del software.
Sin embargo, si está utilizando ese interruptor para causar la interrupción, y espera que la rutina de servicio de interrupción se ejecute rápidamente, en menos de 10 milisegundos, necesitará un debouncing de hardware; el evento de conmutación podría dar como resultado un número algo aleatorio de interrupciones, y con frecuencia más de lo esperado. Por otro lado, si la rutina de interrupción se prolonga lo suficiente, el rebote del interruptor se habrá solucionado antes de que finalice el ISR, y estarás bien, pero los ISR más bien construidos no toman tanto tiempo.
La mejor manera de hacer cualquier cosa es la forma que más le convenga. Pero cuando ya tienes un microcontrolador, puedes rebotar en el software solo al costo de un esfuerzo de código.
La forma más sencilla de rebotar en el software es comprobar los botones en momentos que están más alejados que el tiempo de rebote más largo. 50 ms parece ser un límite superior en el tiempo de rebote de los interruptores "normales", por lo que cuando puede organizar su software de esta manera, está claro:
forever loop
wait (at least) 50 ms
check buttons
do procesing
end loop
Un enfoque para el rebote que aún no se ha mencionado es usar un interruptor de doble tiro con un tiro atado a VDD y el otro a tierra. Insértelo en un pin que (a través de software o hardware) será llevado débilmente a su estado actual. Tal enfoque proporcionará las ventajas de un interruptor de doble tiro, pero solo requerirá un pin de E / S en lugar de dos.