A MicroPython library in Velxio is a .py file copied onto the board before
main.py runs. It got there inlined into the program as ONE Python string
literal:
with open("mqtt_as.py",'w') as _f:
_f.write("...36 KB of escaped source on one line...")
so compiling the program asked for one CONTIGUOUS allocation the size of the
file. Issue #219 is that bill coming due on a PSRAM-less ESP32: 36407 bytes of
mqtt_as.py, `MemoryError: memory allocation failed, allocating 36410 bytes`.
Never the firmware version the thread suspected.
The v1.28 bump (bd1613a9) made that single allocation fit, so the reported
message is gone — but the mechanism was not, and what it costs today is worse
than the error was. Measured on the reporter's own project, on velxio.dev and
on staging: 216 s pinned in the raw REPL before the first line ran (the paste
went out at 64 bytes per 150 ms, ~426 B/s), and then `OSError: WiFi Out of
Memory`, because 36 KB of heap was still held by the compiled literal when
esp_wifi came up. The project could not work.
Nothing is inlined now. Each file is written by a sequence of small executions
(open / write(b'...') x N / close) — the shape mpremote's `fs cp` uses against
real hardware — so peak guest RAM is a few dozen bytes per step whatever the
library weighs. The program is written as a file too and started with execfile,
whose lexer streams off flash: a big sketch compiles in the same memory a small
one does, and it still runs in __main__ exactly as the pasted code did.
Flow control is the other half. One burst is in flight at a time, sized to fit
the 128-byte RX FIFO both backends model, and what releases the next is the
board's own end-of-execution marker — proof it consumed the last one, instead
of a delay chosen by hoping. A step can only overflow one burst on a
pathologically long file path, and those few bursts fall back to timed pacing
rather than corrupt the stream. The hundreds of protocol exchanges stay out of
the serial monitor; a progress line goes in their place, and a board-side
failure mid-upload is reported instead of starting a program whose library
never arrived.
One implementation, shared by the QEMU bridge and the in-browser engines. The
hand-ported second copy is why this bug lived in both paths, and the pro
overlay now re-exports this module instead of keeping its own.
Also fixes a latent corruption: sanitizeForRepl's inline-comment rule used to
run over that one-line literal, so a ` #` inside a library file made it strip
non-ASCII from everything after it. Library bytes are never tokenized now.
Verified on staging with the reporter's project (main.py + mqtt_as.py): upload
complete in 36.5 s, then "Got reliable connection / Connecting to broker /
publish 0". The WiFi OOM is gone with the heap it was competing for.
Not exercised live: the OSS QEMU MicroPython path — velxio.dev routes every
supported ESP32 kind to the in-browser engines, so staging cannot reach it. It
runs the same session and is covered by the unit tests, and its 800/200 ms
handshake timings are preserved rather than unified with the engines' 400/150.
David Montero Crespo