tfaour
015993af00
Build and push server image / build-and-push (push) Successful in 32s
Battery (firmware + server, disabled by default): new battery.c reads a 2x200k voltage divider via ADC oneshot with curve-fitting calibration (the ESP32-C6's scheme), maps through a piecewise LiPo discharge curve, and restores the pin to button duty after each read -- the settled XIAO ESP32-C6 design shares the back button's GPIO0/A0, time-shared per wake. Skipped entirely when on mains (a 2x100k VBUS divider into a spare digital pin -- the 5V pin is dead on battery power, so presence = mains, where the charging voltage would read misleadingly full) or when the reading is implausible. The manage overlay gains a battery region (static outline glyph + "NN%", below the manage QR, all menu levels), and the device POSTs to the new /frame/battery endpoint after a successful fetch; the server stores percent + as-of timestamp, exposed via /api/queue and shown in the web UI. FRAME_BATTERY_ADC_GPIO / FRAME_VBUS_SENSE_GPIO default to -1 (fully inert on the dev board); compile-verified both disabled and enabled, hardware bring-up deferred until the ordered XIAO + batteries arrive. Orientation (server-side only): new config setting + web UI dropdown (landscape / portrait / landscape_flipped / portrait_flipped). Photos are composed/cropped at the logical hanging shape (portrait crops at 480x800, so face-aware crops match how the frame actually hangs), then rotated losslessly into the panel's native 800x480 byte layout after dithering -- the device never knows. Face-label anchors are transformed through the same rotation (logical_to_native()) so they stay attached to faces on rotated frames. Known documented limitation: the on-device manage overlay still renders in native orientation, so it appears sideways on a portrait-hung frame (QRs scan at any rotation; text reads sideways).
47 lines
1.7 KiB
C
47 lines
1.7 KiB
C
#pragma once
|
|
|
|
#include <stdbool.h>
|
|
|
|
#include "esp_err.h"
|
|
#include "wifi_provisioning.h"
|
|
|
|
/**
|
|
* Which photo-fetch behavior this wake cycle should use -- normally the
|
|
* idempotent GET /frame/image (the server decides on its own whether to
|
|
* advance, based on its configured refresh interval, so a plain
|
|
* wake/reboot never skips a photo just by asking), or POST
|
|
* /frame/advance / POST /frame/back to force a move in either direction
|
|
* (the next-photo / back-photo buttons).
|
|
*/
|
|
typedef enum {
|
|
FETCH_NORMAL,
|
|
FETCH_ADVANCE,
|
|
FETCH_BACK,
|
|
} fetch_action_t;
|
|
|
|
/**
|
|
* Connects to the home WiFi network described by cfg, retrying up to
|
|
* CONFIG_FRAME_STA_CONNECT_MAX_RETRIES times with a per-attempt timeout of
|
|
* CONFIG_FRAME_STA_CONNECT_TIMEOUT_MS. Returns ESP_OK once an IP address
|
|
* has been obtained, ESP_FAIL if all retries are exhausted.
|
|
*/
|
|
esp_err_t frame_wifi_connect_sta(const frame_config_t *cfg);
|
|
|
|
/**
|
|
* Runs the frame's normal-operation cycle: fetch the current image from
|
|
* cfg->toolsserver per `action` (see fetch_action_t), display it, and
|
|
* deep-sleep until the next refresh.
|
|
*
|
|
* If show_management_qr is true (the manage button was held), the
|
|
* displayed photo gets a small "scan to manage" QR overlay in the
|
|
* top-right corner linking to the server's config page, held for 30
|
|
* seconds (the device stays awake), then reverted back to the plain
|
|
* photo before proceeding to the normal sleep-interval logic.
|
|
*
|
|
* battery_percent (0-100, or -1 for "no reading" -- see
|
|
* battery_read_percent()) is shown on the management menu overlay and
|
|
* reported to the server after a successful fetch; -1 skips both.
|
|
*/
|
|
void frame_client_run(const frame_config_t *cfg, fetch_action_t action, bool show_management_qr,
|
|
int battery_percent);
|