Botões de rejeição

Recentemente, li um artigo sobre a rejeição de botões e fiquei pensando se deveria ter isso em mente ao trabalhar com, por exemplo, um Arduino (ATMega mC)? Suponho que seja um problema, especialmente ao trabalhar com interrupções.

Portanto, é melhor detectar rejeição no código ou isso deve ser resolvido com o hardware? Por favor elabore.

Eu recomendo conectar um escopo (espero que você tenha um ou consiga usar um) até o seu switch. Eu vi o projeto de um aluno que teve um salto no interruptor que passou de 5v para -5v até 4v para -3v, depois para até 2v, depois para 2v e depois para 0v. Quando analisamos o desenho atual em um escopo, houve um pico muito grande.

No seu caso particular, era muito necessário que ele renunciasse à sua chave no hardware.

No entanto, por outro lado, vi switches que têm um efeito muito menor que poderia ser facilmente removido no software.

Você precisa pesar suas opções. Se você possui uma quantidade muito complexa de firmware, a adição de sobrecarga para você, como programador e o uso da CPU, pode não valer a pena, e seria melhor adicionar apenas um pouco de hardware. Agora, por outro lado, se você estiver tentando reduzir custos e tamanho, convém remover o máximo de hardware possível e fazer tudo isso no firmware, se puder.

Se você é um designer profissional de eletrônica, é provável que seu chefe nem permita que você faça isso em hardware. O motivo é simples: se o lote de produção é grande o suficiente, o software é praticamente gratuito , enquanto o hardware deve ser pago por cada unidade que você produz. E enquanto os resistores e capacitores são muito baratos, montá-los em uma placa de circuito impresso pode custar até 20 vezes o preço de compra.

Independentemente de você renunciar em software ou hardware, você ainda precisa selecionar botões de qualidade. O infame botão 157ms do artigo simplesmente não é adequado para nenhuma aplicação.
Normalmente, mostro o botão em intervalos de 32 ms , o que é suficiente para diminuir o tempo de debounce de qualquer botão bom. Sou bastante fã dos Switches SKQG TACT da Alps .

Nos poucos dispositivos que testei, o tempo de rejeição inicial era inferior a 10ns. Embora tenha uma vida útil de 100.000 ciclos, testamos por 200.000 ciclos e, mesmo assim, o débito de 32ms foi suficiente. (Acho que deveria ter medido o nível real de devolução, mas nosso principal interesse na época era o comportamento do produto final. De qualquer forma, estávamos usando-o fora das especificações.)

Se você realmente deseja uma solução de hardware, recomendo a solução de flip-flop SR mencionada no artigo como a melhor solução tecnicamente:

O flip-flop pode ser construído com uma porta NAND dupla , que está disponível em um pequeno pacote VSSOP8, por exemplo. A principal desvantagem desta solução é que você precisa de um botão SPDT, em que o SPST está muito mais disponível.

Existem muitas (e muitas) maneiras diferentes de devolver botões. O fato de você fazer isso em software ou hardware dependerá dos requisitos do seu projeto e do tipo de switch.

Aqui estão alguns links para diferentes métodos:

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

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

Esse artigo é a "bíblia" sobre a renúncia. O retorno do contato pode ser um problema com qualquer aplicativo.

Geralmente, é melhor rejeitar comutadores no software, pois é mais fácil ajustar os atrasos para determinados comutadores, pois eles diferem na quantidade de rejeição de contato. Também é necessário renunciar à liberação da chave. Os fabricantes de comutadores geralmente especificam a quantidade de rejeição de seus produtos, normalmente em torno de 10 ms a 20 ms.

O retorno do interruptor pode durar dezenas de milissegundos. Se você estiver pesquisando um comutador a partir de uma rotina de interrupção que é executada em um temporizador, o ressalto não será um problema, porque, mesmo que você ocorra um questionário no meio de uma tempestade, você obterá o novo estado imediatamente , ou, na pior das hipóteses, obtenha o estado antigo e não verá o novo estado até a próxima pesquisa com base no cronômetro. A pesquisa de um ISR cronometrado como este constitui uma forma de debounce de software.

No entanto, se você estiver usando esse comutador para causar a interrupção, e espera que a rotina do serviço de interrupção seja executada rapidamente, em menos de 10 milissegundos, precisará de uma reativação de hardware; caso contrário, um evento de comutador poderá resultar em um número aleatório de interrompe e, certamente, muitas vezes mais do que o esperado. Por outro lado, se a rotina de interrupção for longa o suficiente, o retorno do switch será resolvido antes que o ISR termine, e você ficaria bem, mas os ISRs mais bem construídos não demoram tanto tempo.

A melhor maneira de fazer qualquer coisa é a que melhor combina com você. Porém, quando você já possui um microcontrolador, pode debitar no software apenas pelo custo de um esforço de código.

A maneira mais essencial de debounce no software é verificar os botões nos momentos mais distantes do que o tempo de rejeição mais longo. 50 ms parece ser um limite superior no tempo de rejeição dos comutadores 'normais'; portanto, quando você pode organizar seu software dessa maneira, fica claro:

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

Uma abordagem para a rejeição que ainda não foi mencionada é o uso de um comutador de lançamento duplo com um lançamento vinculado ao VDD e o outro no chão. Alimente isso em um pino que (seja por software ou hardware) será puxado levemente para o seu estado atual. Essa abordagem fornecerá as vantagens de um comutador de lançamento duplo, mas exigirá apenas um pino de E / S em vez de dois.