Kaj SchittecatandClaude Opus 4.8
f5fee0c986
Three independent 100%-reproducible triggers finally pinned this down, and they
all turn out to be the same thing: a write to flash.
- every received message -> chat-history write
- opening a channel that has unread messages -> mark-read write
("if you open them back up and there aren't unread messages, there's no flash")
- deleting a contact -> the chunked bulk delete writes repeatedly, and
it flickers CONTINUOUSLY for the whole operation
Mechanism. This panel is a MIPI-DSI DPI/video one: its single ~1.4 MB framebuffer
can only live in PSRAM and the DSI DMA streams it to the glass continuously. PSRAM
sits behind the same cache as flash, and a flash write has to DISABLE that cache
while it runs. For the duration of the write the DMA cannot fetch the framebuffer,
the panel underruns, and a frame comes out as a whole-screen colour flash. Nothing
to do with what is being drawn, which is why it appeared on every screen, on every
board revision, and from the very start of the port.
Fix: CONFIG_SPIRAM_XIP_FROM_PSRAM=y. Code and constants are relocated into PSRAM
at startup so the cache no longer has to be dropped for a flash write. The SoC
supports it (CONFIG_SOC_SPIRAM_XIP_SUPPORTED=y) and IDF ships the same pairing as
a P4 reference config (esp_mm/test_apps/mm/sdkconfig.ci.xip_psram_esp32p4). It
pulls in SPIRAM_FETCH_INSTRUCTIONS / SPIRAM_RODATA / SPIRAM_FLASH_LOAD_TO_PSRAM.
This also explains why 7aaff80 (moving the flush scratch out of PSRAM) did not
help: that reduced PSRAM BANDWIDTH contention, but the cache is disabled outright
during a flash write, so bandwidth was never the constraint. That commit is still
worth keeping on its own merits, but it was not the cause.
Also restores CONFIG_ESP_HOSTED_RESET_SLAVE_USING_CALLBACK and its SDIO twin to
this fragment. They existed only in the GENERATED sdkconfig, so regenerating it
for the XIP change silently dropped them and esp-hosted fell back to resetting the
slave over GPIO 54 — a line this board does not have (C6_EN is on the XL9535, so
it can only be driven by callback). Inert today because TDP4_C6_READY is 0, but
the config is now reproducible from its fragments instead of depending on an
untracked file nobody could regenerate.
Boots clean with XIP enabled: display up, GPS probe reading, only rst:0x1
(POWERON). Needs field confirmation against the contact-delete trigger, which is
the reliable one.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A real touchscreen UI for your mesh radio. · open source · GPL-3.0
Touch-UI MeshCore companion-radio firmware for the LilyGo T-Deck / T-Deck Plus and Heltec V4 + TFT (ESP32-S3).
An LVGL touch UI — map, chat, contacts, channels, settings — split out of
meshcomod. The app depends on a
MeshCore fork via PlatformIO lib_deps.
Boards
See DEVICES.md for the full support matrix, install paths and per-board status.
- LilyGo T-Deck / T-Deck Plus — env
LilyGo_TDeck_companion_radio_touch(stable) - Heltec V4 + TFT + CHSC6x touch — env
heltec_v4_tft_companion_radio_usb_tcp_touch(stable) - Tanmatsu (ESP32-P4) — built from
tanmatsu/(ESP-IDF), ships via the Tanmatsu app store - Elecrow ThinkNode M9 — env
ThinkNode_M9_companion_radio_touch(beta) - RAK WisMesh Tap V2 (RAK3312) — env
rak_tap_v2_companion_radio_touch(beta)
Architecture
This repo holds only the app: the companion_radio glue, the ui-touch
LVGL UI, the two boards' glue/variants, and platformio.ini. The MeshCore
core is not vendored here — it's pulled as a library via lib_deps from the
ALLFATHER-BV/meshcomod monorepo
(the same repo as the non-touch firmware), pinned by a lean source-only core-*
git tag. The touch-app files this repo owns (TouchPrefsStore, WifiRuntimeStore,
the transports, …) are dropped from the lib via -DMC_VENDORED_TOUCH_APP so they
aren't compiled twice. The build is byte-identical to the original in-tree
meshcomod firmware.
Build
PlatformIO pulls the core fork and all libraries automatically:
pio run -e heltec_v4_tft_companion_radio_usb_tcp_touch # Heltec V4 TFT
pio run -e LilyGo_TDeck_companion_radio_touch # LilyGo T-Deck
# or just `pio run` to build both
Flash with the NVS-preserving 4-component chain (bootloader / partitions /
boot_app0 / firmware at 0x0 / 0x8000 / 0xe000 / 0x10000) so saved Wi-Fi
credentials survive — not a merged image, which 0xFF-pads and wipes NVS.
Contributing
Contributions are welcome — see CONTRIBUTING.md. One topic per PR; inbound contributions are accepted under the project's GPL-3.0 license.
License
GPL-3.0-or-later — see LICENSE. wadamesh is copyleft: anyone who distributes a build or a fork must also make their source available under the GPL. This keeps the UI open and concentrates community effort instead of fragmenting it into closed forks.
wadamesh incorporates and depends on MeshCore (MIT, © Scott Powell / rippleradios.com) and other third-party components — see NOTICE for the full list and their licenses. MeshCore-derived files keep their MIT notices; the combined work is distributed under the GPL (MIT is GPL-compatible). The MeshCore fork that wadamesh builds against stays MIT on purpose, so its Wi-Fi/BLE hooks remain upstreamable to MeshCore.