RAK3401: reliable AIN1 button — interrupt latch, debounce, digital read, instant screen-on 🤖🤖

[disq]

Problem

The RAK3401 companion build has a single user button on AIN1, driven by analogRead() polled once per main-loop iteration — there is no interrupt serving it. Symptoms:

• Presses dropped when the loop briefly stalls (LoRa RX/TX, BLE, flash writes).
• Single clicks feel laggy: the screen only wakes after the multi-click window expires.

Changes

MomentaryButton (generic)

• Configurable multi-click window on the analog constructor (default unchanged).
• reset() — abandon the in-flight gesture.
• enableInterrupt() — permanent FALLING-edge GPIOTE interrupt that latches presses so they survive loop stalls (and can wake the MCU where the platform sleeps on interrupts). Debounced: one count per press, re-armed only after check() sees a clean release (rejects press/release contact bounce). Skipped for analog/SAADC-threshold buttons (GPIOTE vs analogRead conflict on the same pin).

companion_radio UITask

• Wake the display instantly on the press edge when it's off, instead of after the multi-click window.
• Arm the button interrupt at startup for PIN_USER_BTN_ANA boards.

variants/rak3401

• Read AIN1 digitally (active-low, internal pull-up) instead of via SAADC — digitalRead coexists with the GPIOTE edge interrupt where analogRead does not (analogRead otherwise reads stuck "always pressed" once the interrupt is attached). Multi-click retained: single=NEXT / double=PREV / triple=SELECT / long=ENTER.

Notes for reviewers

• Scoped to the button path; no changes to the sleep/power code. (A companion light-sleep-wake tweak that routes this pin through enterLightSleep lives on our integration branch and depends on power-management work not yet upstream — intentionally left out here.)
• Related: RAK3401: powerOff() override + AIN1 SENSE LOW wake from SYSTEMOFF 🤖🤖 #2642 wakes AIN1 from full SYSTEMOFF via GPIO SENSE (different files); independent of this.

Testing

• Builds clean: RAK_3401_companion_radio_ble, RAK_3401_companion_radio_usb.
• The same MomentaryButton/UITask/target logic was bench-tested on RAK3401 companion_radio_ble hardware on our integration branch (digital read fixes the SAADC+GPIOTE "always pressed" conflict; presses reliable through loop stalls; single/double/triple/long all work, no dropped or double-counted clicks). This dev port is build-verified and should be re-flashed/re-tested on hardware before merge.

Known edge case

If the loop stalls through the middle of a fast double-click so check() never re-arms between the two presses, the second press is dropped (fails toward "one click", never a phantom extra). Normal clicking is unaffected.

🤖 Generated with Claude Code