fix(devkit2): Add button deboucing and long press haptic feedback

[kevtae]

Fixed a bug where a long press on the button could accidentally power off the device instead of only sending a BLE notification.

Problem: Physical buttons can “bounce,” meaning the signal rapidly flickers on/off before settling. The firmware was interpreting that noise as a quick tap, which triggered the power-off behavior.

Solution: added a 20ms debounce filter to wait for the signal to stabilize before counting a press and also added haptic feedback (a vibration) when a long press is recognized so you get clear confirmation it worked

[gemini-code-assist]

Code Review

This pull request introduces a debouncing mechanism for the button to prevent spurious presses and adds haptic feedback for long presses. The changes look good and directly address the issue described. I've provided a couple of suggestions to further improve the robustness of the new debouncing logic: ensuring correct access to the was_pressed variable shared between an ISR and a thread, and preventing a potential integer overflow in the time calculation. Addressing these points will make the implementation more robust.

[gemini-code-assist]

The global variable was_pressed is written in an interrupt service routine (button_pressed_callback) and read here in a workqueue thread context. To prevent incorrect compiler optimizations and ensure the latest value is always read, it should be declared as volatile.

For example, in its declaration:

static volatile bool was_pressed = false;

For even greater safety in a concurrent environment like Zephyr, consider using atomic variables (atomic_t) for was_pressed to guarantee atomic access and proper memory ordering between the ISR and the thread.

[gemini-code-assist]

The calculation of stable_time involves a multiplication that can overflow if the button state remains unchanged for a long period (e.g., over ~49 days), as current_time - last_state_change_time could become very large. This overflow would cause stable_time to wrap around to a small value, potentially leading to incorrect debounce behavior.

To make this more robust, it's safer to perform the comparison in 'ticks' rather than milliseconds. This avoids the large multiplication and removes the intermediate stable_time variable.

    if ((current_time - last_state_change_time) >= ((DEBOUNCE_TIME_MS + BUTTON_CHECK_INTERVAL - 1) / BUTTON_CHECK_INTERVAL)) {

[beastoin]

thank @kevtae it's nice, btw @TuEmb can you help ?

[TuEmb]

@kevtae thanks for your PR,

Could you take a look at BUTTON_CHECK_INTERVAL, we already have ~40ms debounce. do the button flickers happen on your side ? it's good if you can capture the issue.

[TuEmb]

I think this condition never occurs. Basically, the button is checked with a 40 ms period, and your debounce time is shorter than one cycle.

[TuEmb]

This behavior is not our intention. We only play the haptic on power-up and power-down. If you prefer this behavior, you can keep it locally or implement a solution that allows customization from the phone app based on user preferences.