a2nr
/
velxio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

fix(micropython): real WiFi driver only where the backend can serve it 

Deploy verification of the #262 fix caught a backend split the issue
could not see. The reporter runs the OSS Docker image, where MicroPython
executes under the QEMU worker — there the real driver works and their
fix verification (DHCP on 192.168.4.x, DNS, TCP) holds. But velxio.dev
routes a plain ESP32 MicroPython run to the in-browser esp32js engine,
and the engines' P4 WiFi (which serves Arduino fine) does not yet cover
MicroPython's v1.20 / esp-idf-4.2 vintage esp_wifi blob: handing it the
real module stalls esp_wifi_init with NO output — observed live as four
minutes of dead serial after the raw-REPL paste, strictly worse than the
stub's fake-but-responsive answers.

So the prelude now asks the bridge: an overlay bridge that keeps the
MicroPython run in-browser declares micropythonWifiSupported=false and
keeps the stub; the QEMU path (every OSS install, and ?esp32sim=qemu in
the overlay) gets the real driver + SSID-rewrite proxy. When an engine
gains MicroPython WiFi it flips its declaration and this file needs no
further change.

Property is duck-typed and optional; the plain OSS Esp32Bridge does not
define it, and undefined means supported — OSS behavior is exactly the
reporter's verified environment.
This commit is contained in:
David Montero Crespo 2026-08-10 22:34:49 +02:00
parent ea1cdffb56
commit d527b1839c
1 changed files with 17 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
frontend/src/store/useSimulatorStore.ts
View File

@ -1972,10 +1972,23 @@ export const useSimulatorStore = create<SimulatorState>((set, get) => {
return `with open(${path},'w') as _f:\n _f.write(${lit})`;
});
// Does this run get a real NIC? Must match what startBoard()
// will decide, because that is what actually attaches the
// device — see sketchUsesWifi().
const wifiOn = board.hasWifi ?? sketchUsesWifi(files);
// Does this run get a real, WORKING network driver? Two gates:
// - the sketch must want WiFi (must match what startBoard()
// decides, because that is what attaches the NIC device —
// see sketchUsesWifi()), and
// - the backend must be able to serve MicroPython's esp_wifi
// blob. The QEMU worker can (issue #262 was reproduced and
// fixed there). An overlay bridge that routes MicroPython to
// an in-browser engine declares `micropythonWifiSupported =
// false` until the engine models what that blob touches —
// handing it the real driver today stalls esp_wifi_init with
// no output at all, which is strictly worse than the stub.
// Absent property (plain OSS bridge) means supported.
const bridgeMpyWifi = (
esp32Bridge as { micropythonWifiSupported?: boolean }
).micropythonWifiSupported;
const wifiOn =
(board.hasWifi ?? sketchUsesWifi(files)) && bridgeMpyWifi !== false;
// WiFi compat shim: replace `network`, `ntptime`, `urequests`
// with smart stubs BEFORE user main.py imports them.