Pessoal, boa?

Seguinte, estou em um desenvolvimento onde preciso capturar as interrupções de dois botões (up e down) que deverá contar um evento somente quando ocorre a transição para LOW.

Os eventos ocorrem quando pressionados os respectivos botoes, o problema é que mesmo com tratamento (debounce), set INPUT_PULLUP, FALLING, ocorre dupla contagem do evento (quando pressionado e quando o botao é solto).

Configuração: IDE ARDUINO 1.8.19 - Esp8266 NODEMCU ESP-12

Anexo o código principal, se puderem me ajudar  agradeço.

Exibições: 442

Anexos

Responder esta

Respostas a este tópico

Boa tarde Joacir,

pelo seu histórico de postagem percebi que você é um frequentador aqui do LgG.

Posto isto, pergunto se já recomendaram para você ler o tópico:

  https://labdegaragem.com/forum/topics/sugest-o-de-como-postar?

Se ainda não leu, acho que é um bom momento para ler.

Lendo, entenderá que postar código n área de texto do tópico, além de perder caracteres, perde também a formatação.

Por favor, remova seu código da área de texto do seu tópico e anexe-o como um arquivo.

RV mineirin

Boa tarde,

obrigado por compreender as razões da minha solicitação, removendo o codigo da área de texto do tópico

e postando  como arquivo anexado.

Ainda não testei seu código para ver o que ocorre com ele, mas já vi uma coisa que 

não se deve fazer.

Dentro de rotinas de interrupção não é recomendado o uso de millis|(), já que milllis() depende de outra

interrupção, e algumas interrupções fica desabilitadas durante uma rotina de manuseio de interrupção.

Mais tarde tento entender o que mais pode estar errado com seu código.

RV mineirin

Tranquilo meu velho, eu é que nao segui as regras. Abraço.

Boa noite,

um grande problema ao usar as soluções de interrupt com botões, é que não é possível

fazer debouncig, pois a interrupt ocorre toda vez que satisfizer a condição programada para o interrupt.

Se o interrupt for usado por outro tipo de sinal, este bouncing não este e portanto a interrupção

ocorre normalmente

Botões geram muitos "repiques" ou em inglês "bouncing".

Quanto mais "vagabundo" o botão mais bouncing ele gera.

isto significa que ao apertar um botão (ou até mesmo ao solta-lo) gere milhares de liga/desliga.

Isto faz com que a rotina de interrupt seja rodada milhares de vezes em alguns milissegundos.

Veja a figura abaixo:

Efeito bouncing - Debounce, o que é e como resolver via software

O melhor enfoque é que ao usar rotinas de interrupt com botões, não faça incremento ou operações

com variáveis nesta rotinas.

O ideal é ligar um "flag" e em seguida um delay, testar o estado do botão e depois usar um travamento.

Assim você tenta garantir que passe o tempo do bouncig, e que ele não afete variáveis.

no código que estou anexando, eu empreguei estas técnicas.

Um detalhe:

Em baixo no seu código está escrito  assim:

// D7 -> CHAVE DOWN -> RESISTOR 220 OHMS -> GND
// D4 -> CHAVE UP -> RESISTOR 220 OHMS -> GND.

Como você está ligando os resistores de pull-up do ESP, basta ligar o botão entre o GPIO e o GND, sem

usar nenhum resistor.

Veja se o código atende sua necessidade.

RV mineirin

interrupt_V02.ino

Boa noite,

Para limitar bouncing em um botão, coloque um capacitor em paralelo com a chave. 

Teste alguns valores como 10 nF. 

Boa noite Murta, testei com valores entre 100nf e 10nf. Há redução dos "repiques" mas a leitura incorreta ainda ocorre.

Valeu pelo retorno, assim que conseguir uma solução aviso.

Boa noite RV, vou testar isso no código. Como tentativa de redução dos "Repiques" estou testando com um 4066 (https://www.ti.com/lit/ds/symlink/cd4066b-mil.pdf), o qual reduziu muito o problema, porém em alguns momentos há falso positivo ao pressionar (duas contagens). 

Te aviso assim que testar, valeu pela ajuda e vamos falando.

Bom dia, 

Você já trocou o botão?

Sugiro troca-lo por outro tipo. 

É estranho tanto repiques. 

Boa noite Murta, 

Já, inclusive inseri o CI 4066, que é uma chave bilateral para tentar aumentar a velocidade de chaveamento, melhorou mas ainda apresenta, em alguns momentos contagem dupla.

Atualmente estou testando o protótipo direto na USB, vou testar com uma fonte estabilizada, tenho uma hikari 3205S, talvez apresente alguma mudança no comportamento.

Também aqui no fórum, apareceram boas sugestões que vou testar hoje.

Grande abraço e obrigado por seu tempo.

Joacir.

Olá, Joacir!

   Para se usar interrupções, a técnica que o RV descreveu em seu post é a mais adequada, além do importante alerta sobre o comportamento de mais de um tipo de interrupção rodando concorrentemente, o que pode ser, sim, um problema.

   Mas fica uma dúvida: É realmente necessário utilizar interrupção? Pergunto porque, em primeiro lugar, o pressionar de um botão é um evento de operador e, portanto, muito mais lento do que o executar de instruções do processador, o que indica poder ser tratado por polling, ou varredura, se preferir,

   Além disso, ainda há a necessidade de se tratar o bouncing, como muito bem explicado no referido post, e que trás outra complicação no caso de tratar por interrupção.

   As interrupções são recursos nobres nos processadores e, como tal, devem ser usadas para casos em que sejam realmente necessárias.

   Já fiz centenas de projetos de sistemas embarcados e nunca usei interrupções para tratamento de botões ou teclados matriciais. Sempre usei polling e nunca tive qualquer problema.

   Um bom uso de interrupções surgiu em um outro post recente aqui no LdG, em que um profissional da Eletrônica, fazendo uma graduação em licenciatura em Física queria medir a velocidade de um móvel. Bem, neste caso, dependendo da precisão de medição requerida, pode ser necessário o uso de interrupção.

   A não ser que eu não tenha prestado a devida atenção ao teu post e, por conseguinte, não esteja vendo a razão pela qual interrupções devem ser usadas neste teu caso, a minha opinião é que ler os botões por polling é melhor e mais fácil.

Sucesso!

D. T. Ribeiro.

Boa noite D.T. tudo Certo?

Em relação ao projeto, trata-se de um dispositivo onde o usuário, através de dois botões, deverá navegar em um menu criado em um OLED e à partir das opções escolhidas, as devidas funções são disparadas.

A definição em se utilizar interrupções foi, entre outras, por desafio pessoal, o qual está se mostrando talvez, um pouco menos confiável que o esperado, isto considerando o projeto proposto.

Obrigado pela ajuda!

Joacir.

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço