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.
95 lines
3.9 KiB
Bash
Executable File
95 lines
3.9 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Builds/flashes for a specific board variant. This project targets three:
|
|
#
|
|
# devkit ESP32-C6-DevKitC-1 (8MB flash) -- the dev board. This is
|
|
# also the plain `idf.py` default (sdkconfig/build/), so this
|
|
# script's devkit mode is mostly for symmetry -- normal
|
|
# `idf.py build`/`flash` work fine too. Reports itself as
|
|
# "devkit_esp32c6" (see main/Kconfig.projbuild).
|
|
# xiao Seeed XIAO ESP32-C6 (4MB flash) -- the production board.
|
|
# Reports itself as "xiao_esp32c6".
|
|
# ee02 Seeed EE02 (XIAO ESP32-S3 Plus, 16MB flash) + 13.3" Spectra 6
|
|
# panel -- a genuinely different chip target (esp32s3, not
|
|
# esp32c6), unlike xiao's same-chip Kconfig-only variant.
|
|
# Reports itself as "ee02". NOTE: the epd13in3e driver this
|
|
# board links (firmware/components/epd13in3e) doesn't actually
|
|
# work yet -- its panel init/LUT/refresh register sequence is
|
|
# still unported from vendor demo code (see that component's
|
|
# own top-of-file comment); building for ee02 will fail to
|
|
# compile until that lands, by design (a deliberate #error, not
|
|
# a bug in this script).
|
|
#
|
|
# The three need different partition tables (each flash size needs its
|
|
# own OTA app-slot sizing -- see partitions_xiao.csv/partitions_ee02.csv)
|
|
# and different flash-size Kconfig. Rather than hand-editing the shared
|
|
# sdkconfig back and forth (fragile, easy to leave it in the wrong state
|
|
# for whichever board you flash next), each board gets its own build
|
|
# directory and its own generated sdkconfig, seeded from
|
|
# sdkconfig.defaults (shared) with the board's override file layered on
|
|
# top via ESP-IDF's own SDKCONFIG_DEFAULTS mechanism. Switching boards is
|
|
# just switching which one you invoke -- none ever touches another's
|
|
# config or build output.
|
|
#
|
|
# Usage:
|
|
# ./build_for_board.sh xiao build
|
|
# ./build_for_board.sh xiao flash -p /dev/ttyUSB0
|
|
# ./build_for_board.sh xiao flash monitor -p /dev/ttyUSB0
|
|
# ./build_for_board.sh devkit build
|
|
# ./build_for_board.sh ee02 set-target esp32s3 # first build only, see below
|
|
# ./build_for_board.sh ee02 build
|
|
#
|
|
# Defaults to "build" if no idf.py subcommand is given.
|
|
|
|
set -euo pipefail
|
|
|
|
script_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
|
cd "$script_dir"
|
|
|
|
if [ $# -lt 1 ]; then
|
|
echo "Usage: $0 <devkit|xiao|ee02> [idf.py args...]" >&2
|
|
exit 1
|
|
fi
|
|
board="$1"
|
|
shift
|
|
|
|
case "$board" in
|
|
xiao)
|
|
build_dir="$script_dir/build_xiao"
|
|
sdkconfig_path="$script_dir/sdkconfig.xiao_local"
|
|
defaults="$script_dir/sdkconfig.defaults;$script_dir/sdkconfig.xiao"
|
|
;;
|
|
devkit)
|
|
build_dir="$script_dir/build"
|
|
sdkconfig_path="$script_dir/sdkconfig"
|
|
defaults="$script_dir/sdkconfig.defaults"
|
|
;;
|
|
ee02)
|
|
build_dir="$script_dir/build_ee02"
|
|
sdkconfig_path="$script_dir/sdkconfig.ee02_local"
|
|
defaults="$script_dir/sdkconfig.defaults;$script_dir/sdkconfig.ee02"
|
|
;;
|
|
*)
|
|
echo "Unknown board '$board' -- expected 'devkit', 'xiao', or 'ee02'" >&2
|
|
exit 1
|
|
;;
|
|
esac
|
|
|
|
args=("$@")
|
|
if [ ${#args[@]} -eq 0 ]; then
|
|
args=(build)
|
|
fi
|
|
|
|
# idf.py is normally a shell *function* (defined by ESP-IDF's
|
|
# activate/export script), not a real executable on PATH -- that
|
|
# function isn't inherited by this script's own subshell even if you
|
|
# sourced the activation script first. IDF_PATH (an exported env var,
|
|
# which *is* inherited) lets this work the same way regardless: call
|
|
# the underlying Python module directly.
|
|
if [ -z "${IDF_PATH:-}" ]; then
|
|
echo "IDF_PATH is not set -- source your ESP-IDF activation/export.sh first" >&2
|
|
exit 1
|
|
fi
|
|
|
|
echo "==> Board: $board (build dir: $(basename "$build_dir"), sdkconfig: $(basename "$sdkconfig_path"))"
|
|
exec python "$IDF_PATH/tools/idf.py" -B "$build_dir" -D "SDKCONFIG=$sdkconfig_path" -D "SDKCONFIG_DEFAULTS=$defaults" "${args[@]}"
|