tfaour
d395cf3bb9
Build and push server image / build-and-push (push) Successful in 35s
Factory-reset (GPIO3, hold 10s): clears stored WiFi/server config and restarts into provisioning -- the deliberate, USB-free replacement for the earlier reverted RST-based auto-reprovisioning idea. Next-photo (GPIO2, tap): wakes the device and forces the server to advance immediately via a new POST /frame/advance, instead of waiting for the refresh interval. Both buttons arm themselves as deep-sleep GPIO wakeup sources so a press is noticed promptly even while asleep. Also makes GET /frame/image side-effect-free: it now only advances once refresh_interval_s has elapsed since the current photo was set (tracked server-side), so a device reboot for any reason just redisplays the current photo instead of silently skipping ahead. The server maintains a small reorderable upcoming-photos queue, viewable and rearrangeable from the web UI.
22 lines
744 B
C
22 lines
744 B
C
#pragma once
|
|
|
|
#include <stdbool.h>
|
|
|
|
/**
|
|
* Configures the next-photo button GPIO (CONFIG_FRAME_NEXT_BUTTON_GPIO,
|
|
* active-low with internal pull-up) and arms it as a deep-sleep wakeup
|
|
* source, same as reset_button_init(). Call once, early in app_main(),
|
|
* before the device might enter deep sleep.
|
|
*
|
|
* A no-op if CONFIG_FRAME_NEXT_BUTTON_GPIO is negative (button disabled).
|
|
*/
|
|
void next_button_init(void);
|
|
|
|
/**
|
|
* Returns whether the next-photo button is currently held, debounced with
|
|
* a couple of short re-checks to reject noise. Unlike the reset button,
|
|
* there's no long hold-to-confirm gate -- advancing a photo is low-stakes
|
|
* and should feel immediate, so this returns right away either way.
|
|
*/
|
|
bool next_button_check(void);
|