Is there a bug in the `gpio_button_init` function?
The code is:
return wiced_gpio_init( button->gpio, ( button->polarity == WICED_ACTIVE_HIGH )? INPUT_PULL_UP: INPUT_PULL_DOWN );
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 .
Solved! Go to Solution.
Hi Andrew:
I will look into this case, by the way do you meet some issues when you configure the GPIO functions?
and which evb or chip you are using now?
The issue that I was seeing was that that the on-chip PU/PD was not being activated correctly.
Patching this line to:
return wiced_gpio_init( button->gpio, ( button->polarity == WICED_ACTIVE_HIGH )? INPUT_PULL_DOWN: INPUT_PULL_UP );
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.