- README's env table and external_keyboard.md's device-support table both
get a ProMicro row -- missed when the PR #31 merge landed since neither
was in scope for that commit.
- external_keyboard.md and build_flags.md now cover CARDKB_I2C alongside
ENV_PIN_SDA/ENV_PIN_SCL: the PR generalised CardKB bus selection to a
single macro after build_flags.md was first written, so the doc only had
the older (still valid, but no longer the only) form.
- release-notes.md: added the ProMicro solo build and the new Build Flags
reference page to v1.26's What's New.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Solo's `_solo_dual` env for each board lived inside variants/<board>/, mixed
in with the shared upstream board configs (repeater, room server, plain
companion) that every MeshCore fork carries. Split them out into their own
top-level solo/<board>/ folder -- each still `extends` the board base defined
in its original variants/<board>/platformio.ini, just no longer interleaved
with it file-wise.
- platformio.ini: extra_configs picks up solo/*/platformio.ini alongside
variants/*/platformio.ini.
- build-solo-firmwares.yml: env-discovery grep now scans solo/ instead of
variants/ (the release matrix is unchanged -- same 8 envs, same names).
- pr-build-check.yml: solo/** added to the trigger paths.
- GAT562 30S Mesh Kit: dropped the separate solo_ble env -- solo_dual is a
strict superset (BLE still works, plus USB), and every other board only
ever had one solo build to begin with.
- GAT562 Mesh Watch13: renamed solo_ble -> solo_dual (added DUAL_SERIAL=1) to
match. No comment anywhere recorded whether this board's USB data lines
are actually broken out to a connector -- DUAL_SERIAL compiles and works
over BLE regardless, so worst case the USB half goes unused.
- Removed a dead AUTO_SHUTDOWN_MILLIVOLTS from the three solo envs that set
it (Heltec V3/V4, T-Echo Lite+KeyShield): that macro is only ever read in
the old ui-tiny UITask, never ui-new, which every solo build (these
included) uses -- it did nothing on any of them. Left alone everywhere
else it's set (non-solo companion envs elsewhere use ui-tiny/ui-orig, or
the flag is legitimately read); out of scope here.
- Added docs/solo_features/build_flags.md: every optional -D flag a solo
build understands (GPIO, CardKB/joystick, Hall-sensor cover lock, buzzer/
vibration, GPS switch, display/battery tuning), verified against the code
rather than the existing per-board comments, with what's already baked
into every solo build kept separate from what's opt-in.
- README: doc index + Building from source section link to the new page;
path references to the moved solo files updated to solo/<board>/.
All 8 solo_dual envs rebuilt clean after the move; native test suite (40
cases) unaffected.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Cut restated points, hedge phrases and over-explained asides throughout
-- same information, fewer words per sentence. Also fixed a stale gap
in README's "Building from source" env table (Cardputer ADV and
T-Echo Lite + KeyShield were missing).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Swaps which physical input plays which role on the Heltec V3/V4 wired
joystick: the stick's own fifth "press" contact now drives Enter (your
thumb's already on the stick when you'd confirm something), and the
onboard PRG button -- previously Enter -- becomes Back instead, so it
no longer needs a separate wired button of its own.
Pure pin reassignment in the solo_dual envs, no UITask.cpp changes:
PIN_USER_BTN (Enter) is undef'd and redefined from the base env's PRG
default to the joystick's press pin, and PIN_BACK_BTN takes PRG's old
GPIO0. Scoped to just these two envs -- Wio Tracker L1/GAT562/MeshTiny
share the same UI_HAS_JOYSTICK code path with PRG already correctly
wired as their one true physical button, so their behaviour is
untouched.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
README's Supported Devices table and Flashing section gain the
Cardputer ADV and T-Echo Lite + KeyShield rows/headings (both marked
experimental, matching release-notes.md and the Heltec V3/V4 entries).
external_keyboard.md gets a new section for their built-in TCA8418
keypads -- a separate mechanism from CardKB, not documented anywhere
before. settings_screen.md's GPS pwr row now lists !gps fix among the
things that hold GPS continuously on, matching the actual code.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
README had drifted from the firmware in several places:
- Supported Devices listed only the three nRF52 boards; Heltec V3/V4 were
missing entirely, as was any mention that ESP32-S3 flashes differently.
Flashing is now split per MCU, with the merged-vs-app-only .bin trap
spelled out — that one costs an afternoon to diagnose from a dark screen.
- It advertised a Lemon/Default font switch that was retired in v1.23; there
is one unified misc-fixed 6x9 font now and no font setting at all.
- tools/README claimed ENABLE_SCREENSHOT had to be added by hand, directly
contradicting README's "no special build flags required". The envs have
carried the flag for a while; rewrote the file to cover all four tools.
- "S key for screenshot" described screenshot.py's menu, not the device —
screenshots are driven entirely from the host via CMD_GET_SCREENSHOT.
Structurally, general notes (factory reset on migration, BLE-over-USB
priority) sat at the tail of the ESP32 subsection and read as ESP32-specific;
they're now placed where they apply. Heltec wiring moved out of Supported
Devices into its own section so the device table stays scannable, and the
Solo Tools heading is no longer a link (it was generating a garbage anchor).
New docs/solo_features/external_keyboard.md covers CardKB and the wired
joystick: shortcut table, Full vs Compact, and the pin assignment. The pins
are marked as verified on real V4 hardware only — V3 inherits them from
Heltec's documented pin-compatibility and hasn't been checked on a board.
FEATURES.md (roadmap + code audit, developer-only) moves to
docs/development/roadmap.md; nothing referenced it by path.
Adds Building from source / Releasing / Repository layout, since the release
flow was only discoverable by reading the workflow.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
JakubandClaude Sonnet 5
MarekZegare4andClaude Sonnet 5