Files
espresso_frame/firmware/sdkconfig.ee02
T
tfaour 474b92a282
Build and push server image / test (push) Successful in 45s
Firmware build check / build-check (push) Successful in 2m50s
Build and push server image / build-and-push (push) Successful in 4m36s
Build and push server image / deploy (push) Failing after 1m34s
Add server-side support for a second panel (13.3in Spectra 6 / EE02) and scaffold its firmware target
Server: Frame.panel_type (new column + migration) is auto-derived from
the device's reported board (X-Frame-Board), never user-set -- the
panel is a property of the hardware, not a picker in the UI.
image_pipeline's packing/render pipeline is parameterized by panel
geometry instead of hardcoded 800x480 globals, with the real confirmed
13.3in geometry (1600x1200) registered alongside the original 7.3in
panel. Existing 7.3in frames are unaffected (column default + board
mapping both resolve to the original panel).

Board identifiers are also renamed (devkit/xiao -> devkit_esp32c6/
xiao_esp32c6, plus new "ee02") since the EE02 board also carries a XIAO
module -- "xiao" alone stopped disambiguating hardware. The server
keeps accepting the legacy bare names indefinitely for already-flashed
devices.

Firmware: scaffolds a third build target (ee02, ESP32-S3 -- a real
chip-target change, not just a same-chip Kconfig variant like xiao) and
a new epd13in3e driver component skeleton. The actual panel init/LUT/
refresh register sequence isn't ported from vendor demo code yet (none
was available), so that component deliberately fails to compile
(#error) rather than risk sending unverified register values to real
hardware -- devkit/xiao are unaffected and build identically to before.
CI's ee02 build step is continue-on-error for the same reason.
2026-08-04 20:08:22 +00:00

46 lines
2.5 KiB
Plaintext

# Board-specific overrides for Seeed's EE02 (XIAO ESP32-S3 Plus + 13.3"
# Spectra 6 panel), layered on top of sdkconfig.defaults via
# SDKCONFIG_DEFAULTS -- see build_for_board.sh, which is the supported
# way to build with this file. Don't set this via a plain `idf.py
# menuconfig` on the default build; that writes straight into the shared
# sdkconfig, not this file.
#
# Unlike xiao (a same-chip Kconfig-only variant of the ESP32-C6 dev
# board), EE02 is a genuinely different chip target (ESP32-S3) --
# build_for_board.sh runs `set-target esp32s3` for this board before
# building, same as it runs `set-target esp32c6` for devkit/xiao.
CONFIG_FRAME_BOARD_NAME="ee02"
# Selects the epd13in3e driver component (13.3", 1600x1200) instead of
# epd7in3e -- see main/Kconfig.projbuild and main/CMakeLists.txt.
CONFIG_FRAME_PANEL_EE02_13IN3=y
# XIAO ESP32-S3 Plus: 16MB flash, 8MB PSRAM (vs. the plain XIAO ESP32-S3's
# 8MB/8MB) -- see partitions_ee02.csv, sized generously against this,
# not yet trimmed/tuned against a real build's actual footprint.
CONFIG_ESPTOOLPY_FLASHSIZE_16MB=y
CONFIG_PARTITION_TABLE_CUSTOM_FILENAME="partitions_ee02.csv"
CONFIG_PARTITION_TABLE_FILENAME="partitions_ee02.csv"
# EE02's e-paper interface pin defaults live in
# firmware/components/epd13in3e/Kconfig instead of being overridden here
# (mirrors how epd7in3e's Kconfig defaults are devkit-shaped and
# sdkconfig.xiao only overrides the ones that actually differ) -- EE02's
# pins are a different Kconfig menu entirely (EPD_PIN_CS_MASTER/CS_SLAVE/
# POWER_EN don't exist on epd7in3e's board at all), not a same-menu
# override, so there's nothing to set here beyond selecting the component
# above.
#
# Deliberately NOT overriding FRAME_NEXT_BUTTON_GPIO/FRAME_BACK_BUTTON_
# GPIO/FRAME_COMBO_BUTTON_GPIO/FRAME_BATTERY_ADC_GPIO here, even though
# the same community source that gave the epd13in3e pinout also reports
# EE02 has 3 user buttons at GPIO2/3/5: (1) which physical button maps to
# which logical role (next/back/combo) isn't confirmed, and (2) more
# importantly, those Kconfig options' `range -1 7`/`range -1 6`
# constraints (main/Kconfig.projbuild) are hardcoded to the ESP32-C6's
# deep-sleep-wakeup-capable GPIO set -- NOT verified against which pins
# can actually wake the ESP32-S3 from deep sleep, which is a different
# set on a different chip. Confirm both before wiring this up; widen/
# adjust those Kconfig ranges if the real wakeup-capable pins for
# whichever GPIOs EE02's buttons land on fall outside them.