- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We're using an 20736S and we're trying to differentiate between a single, double, and triple button press. We're getting some extra triggering of the interrupt on the button due to bouncing. We do have a pull down resistor on the pin, and we're configuring the pin using gpio_configurePin (we're using P4 in this case) with:
GPIO_INPUT_ENABLE | GPIO_EN_INT_RISING_EDGE | GPIO_PULL_DOWN, GPIO_PIN_INPUT_LOW
We've also setup the port in the BLE_PROFILE_GPIO_CFG with:
GPIO_INPUT | GPIO_INIT_LOW | GPIO_BUTTON | GPIO_INT
It's my understanding that there's debouncing logic already in the firmware and we'd like to try to use that before writing our own. Do we have to do anything special to use the firmware capability, or should we be using different configuration settings. We've tried a variety of different settings but none seem to make a difference.
Thank you.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the information! It looks like we needed something that spanned more than a few milliseconds so we implemented our own that seems to be working fine.
Best,
Phill
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Phill,
Have you checked the SDK 2.2:
Let me know if this helps
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you are using a raw GPIO, then you will need to implement all of the debouncing yourself.
However, if you use GPIO_BUTTON, firmware does a little debouncing 3-4ms. If you need more, then you will need to run a state machine and start off a timer then wait for x number of ms, then check the condition and adjust debounce yourself.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the information! It looks like we needed something that spanned more than a few milliseconds so we implemented our own that seems to be working fine.
Best,
Phill