Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
If a button is set up as active-low, so that the GPIO is connected to ground went it is pressed, shouldn't the micro therefor provide a pull UP, to restore the input to the non-active state? And vice versa for active-high: GPIO goes high while button is pressed, then a pull DOWN is needed to return it to inactive when the button is released.
I ran into this when trying to set up the button_manager in SDK 5.1 .
and corresponding changes in gpio_button_enable() and wiced_gpio_input_get() make my configuration with button_manager work as expected. On chip PU is switched on, IRQ's are called, and click/hold/double click events are detectable.
I hope I am not missing something obvious; this logic just appears to be inverted, but consistently through the gpio_button library.
I'm not using an EVM, I am working on custom-designed hardware (product prototype). The micro is STM32F4.
A separate but follow-up issue I have is that button manager does perform too well in the presence of certain noise or slow rising edges for an active-low button, and detects 0 or 1ms duration events rather than a qualifying "click" event. I will follow up with scope traces, if I get a chance.