The XIAO stopped answering on 10-07 ("No response from meshcore
node" for many starts in a row). MeshCore's serial parser reads '<'
and a two-byte length, then waits for that many bytes with no time
limit, so one lost or damaged byte can make it swallow up to 65,535
bytes, and MeshTerm sends only 16 per start. Reproduced on the
PicoCalc: a half frame blocked two APP_STARTs until 600 filler bytes
arrived. meshcore-frame-timeout.patch drops a frame after 200 ms of
silence on the line (bytes queued while the loop was busy still
count), and build-firmware.sh applies it after meshcore-uart1.patch.
Upstream dev and main still have the old parser.
Flashing the XIAO with the new firmware, following the guide as
written, found these problems, now corrected:
- Step 11: `pip install platformio` failed (no pip outside a venv on
this PC), and it fails on externally managed Pythons or lands in an
active venv. The guide now uses the official installer only, and
build-firmware.sh and flash.py find pio in ~/.platformio/penv, so
nobody edits the PATH. uf2conv runs on PlatformIO's Python, because
a bare `python` is missing on many Linux systems.
- Step 12: the script's last line said to double-tap reset first;
flash.py touches the XIAO itself, and a wired XIAO's reset button is
inside the case.
- Step 13: this XIAO's bootloader has only a serial port, and flash.py
printed a pio command for the user to run "from your MeshCore
checkout", with pio not on the PATH. flash.py now does the serial
DFU upload itself (54 s here). Without pyserial, it runs itself
again with PlatformIO's Python instead of skipping the touch.
- A wired XIAO's USB power goes backward into the Lyra through the
3V3 wire (JP confirmed it on the bench). Step 13 now applies only
before wiring, and a new Day-to-day procedure updates the firmware
of a wired radio: poweroff, switch off, open, batteries out, flash.
After the flash, the radio kept its identity, MeshTerm's info command
connected, and an APP_START after a half frame and 0.5 s of silence
got its reply at once.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A final pass over the docstrings and comments: "the own X of Y" is now
"Y's own X" (84 places), a navigation entry is a screen on the stack, our
node is our node, a paint is a paint, the quoted UX labels are in code
font, and a list of punctuation glyphs is in code font.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The README, CONTRIBUTING, SECURITY, the docs index, the development
documents, the script READMEs, the comments of config.example.toml and
pyproject.toml, and the issue and pull request forms. The legal sections
of the README (attribution and licence) stay exactly as they were, between
ste: off and ste: on markers. The SignPath attribution line, the one-line
description of MeshTerm, every code block, and every URL do not change.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The Python scripts, the packaging code, and the full-line comments of the
shell scripts. Heredocs, marker lines, licence lines, and code do not
change. The help text of type-text.py now starts with a complete STE
sentence, and uart1-mux.py now says three writes, as the code does.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The console font gains the two powerline chevrons, drawn into the next
two donor slots (U+2559 and U+255B, which nothing draws), in both the
6x12 and the 6x8 builds. With them in its inventory, the PicoCalc's
verdict is core, so its routes are ribbons of chips like the
Cardputer's.
A chip there can only be filled from the eight background slots, since
under a 512-glyph font the VT has no bright backgrounds. So a node's
chip is the dim twin of its hue (theme.DIM_TWIN), and its label is the
hue itself: the colour the name has in every list and in arrow mode. A
hash label and an annotation are that colour throughout. A keyless chip
is white on light grey, the same pair one bank down. Our star, a faded
hop and the composer's slot have no dark grey to stand on, so they
stand on the page, the slot as a white + in a break of the ribbon. Two
chips of one colour join on a thin chevron in that colour.
Bold is brightness on the console, and Rich merges a selected row's
bold into every span on it, which turned the dim fills bright. Every
chip style there says "not bold"; the tests read the rendered row back
through the emulator's VT to hold that.
The new font takes effect once the font script runs again on the Lyra
(as root). Until then the PicoCalc's installed font lacks the chevrons.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
They were committed from Windows, which records no execute bit, so on
the device `scripts/cardputer-zero/launcher-entry.sh` -- run by path, as
its own usage line and the Cardputer guide say -- was refused with
"Permission denied" while the file sat right there. Every script under
scripts/ that starts with #! is now 100755, as the uConsole bridge
already was.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
M5Stack makes three Cardputers and only the Zero runs Linux; the PicoCalc
takes several cores and only the Luckfox Lyra runs MeshTerm. So the bare
names were ambiguous, and every reference to the two devices now carries
the variant: the --platform values and MESHTERM_PLATFORM, the Platform
constants (PICOCALC_LYRA, CARDPUTER_ZERO), their lane decks and every
screen's picocalc_lyra_lane / cardputer_zero_lane, the font inventories,
the lane chips' theme styles, the scripts/ folders, the two chrome test
files, and the docs and CLAUDE.md that name them.
There is no alias: --platform picocalc is refused with the three real
choices listed, rather than falling back to the desktop layout. The
PicoCalc is auto-detected from its device tree, so it needs nothing.
What names hardware or a user's data keeps its name: the PicoCalc
keyboard's input-device name, its battery's sysfs supply, and the serial
profile the Lyra setup script writes. .gitignore follows the firmware's
folder, and the changelog keeps the words each release used.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Jean-Pierre MartineauandClaude Opus 5.5