Initial button state - Githubissues

bxparks / AceButton

An adjustable, compact, event-driven button library for Arduino that debounces and dispatches events to a user-defined event handler.

MIT License

385 stars 37 forks source link

Initial button state #37

Closed Tost69 closed 4 years ago

Tost69 commented 4 years ago

Hi,

first: thanks for your AceButton lib,it provides a lot of possibilities and makes button handling quite easy. However, I have an issue with the initial state of the buttons: the initial state is always 'pressed'. I tried it with and without external and internal pull-down, even with no wiring to the button-pins at all. Finally, I tried the following: pressed the button on restart and voila, this time it was not recognized as being pressed at startup. Could it be the case, that the initial state is negated? Thanks for investigating and kind regards, Tom

bxparks commented 4 years ago

Thanks for your interest in AceButton. You need to give me 2 things before I can debug anything:

a minimal reproducible example code
a circuit diagram (a hand drawn one would be sufficient) Thanks.

Tost69 commented 4 years ago

Hi,

I'm using hardware debounced buttons with Schmitt-Trigger inverter so it gives a nice clean 3,3 high when a button is pressed. The ESP32 board is from EZSBC, coding is done with PlatformIO, used the Espressif ESP32 Dev module lib.

Thanks, Tom

Issue AceButtons.zip

Tost69 commented 4 years ago

Hi,

forget about it:

the initial state provided by isPressedRaw now is correct because now I use button.init(BUTTON_PIN ,LOW) in setup
I've notized that the internal LEDs are switched on with LOW ... that explains why the button state always is/was correct after the first button use; this part also works

Sorry to have bothered you, kind regards, Tom

bxparks commented 4 years ago

Just out of curiosity, why are you using hardware debouncing with a Schmitt trigger, when AceButton already does that for you using software debouncing? I mean, you'll pay the cost of the 20ms of debouncing time anyway. Secondly, it looks like you are shorting the capacitor directly with the switch, instead of going through another resistor. Is that wise? Seems to me that you would be generating micro sparks across your switch's mechanical contact, which will eventually wear it out. (But what do I know, I'm only a software guy.)

Tost69 commented 4 years ago

Hi, :-) yes, hardware debouncing is actually no longer needed. But it's a fun project with my son and we wanted to see how this could work in hardware. The Fritzing I picked this morning was wrong (sorry), there are two resistors and a capacitor per button:

bxparks commented 4 years ago

Very nice. If you want to reduce the number of parts, take a look at my binary encoding page, which explains how to get 5 buttons, using only 4 diodes, and 3 GPIO pins.

Tost69 commented 4 years ago

The binary encoding is really good work, that was also a reason to choose AceButton. I don't like changing the libs for every project, so I'd rather look for something well done and stick with it.

thijstriemstra commented 6 months ago

However, I have an issue with the initial state of the buttons: the initial state is always 'pressed'. I tried it with and without external and internal pull-down, even with no wiring to the button-pins at all

I have the same issue.

Just out of curiosity, why are you using hardware debouncing with a Schmitt trigger, when AceButton already does that for you using software debouncing?

It's a hex schmitt circuit made years ago that I'd like to use with AceButton and it works ok if I just work with a release but longpress etc won't work when the high/low logic is inverted.

Any chance we could get a simple API method that initially inverts the low/high logic, or any other suggestions @bxparks?

thijstriemstra commented 6 months ago

Oh missed this part:

the initial state provided by isPressedRaw now is correct because now I use button.init(BUTTON_PIN ,LOW) in setup I've notized that the internal LEDs are switched on with LOW ... that explains why the button state always is/was correct after the first button use; this part also works

I'll try button.init(BUTTON_PIN ,LOW) and isPressedRaw.

Update: works great. Maybe could be better documented re inverting high/low or I just missed it..

bxparks commented 6 months ago

Update: works great. Maybe could be better documented re inverting high/low or I just missed it..

I think you just missed it: https://github.com/bxparks/AceButton?tab=readme-ov-file#acebutton-class

"Both the constructor and the init() function take 3 optional parameters as shown above:

pin: the I/O pin number assigned to the button
defaultReleasedState: the logical value of the button when it is in its default "released" state (HIGH using a pull-up resistor, LOW for a pull-down resistor)
id: an optional, user-defined identifier for the button, for example, an index into an array with additional information"

There's also an example program: https://github.com/bxparks/AceButton/tree/develop/examples/SingleButtonPullDown