Skip to content

Overlay patch 0015: _timing for the windows port; the wasm bridge's call signature - #24

Merged
bdbarnett merged 2 commits into
mainfrom
timing-redesign
Sep 26, 2026
Merged

bdbarnett merged 2 commits into
mainfrom
timing-redesign

Conversation

@bdbarnett

@bdbarnett bdbarnett commented Sep 26, 2026 •

Copy link
Copy Markdown
Contributor

Two things the timing redesign (PyDevices/pydevices#101) needs from the interpreter overlay.

Patch 0015, the windows port. micropython.exe has no signals, no machine.Timer and no threads in the VM, so nothing could wake the main thread on a deadline: multimer's old win32 provider needed the thread in an alertable wait, which the REPL's console read is not, and a plain time.sleep starved it. The patch adds a _timing module: one high-resolution waitable timer, waited on by a helper thread that only sets a flag and signals an event when the deadline passes; the main thread notices the flag between bytecodes, in mp_event_wait_ms and in the console wait, and hands the callback to mp_sched_schedule from its own context, so the callback runs at a bytecode boundary exactly as a board's soft machine.Timer callback does. The port's waits (MICROPY_INTERNAL_WFE, the console wait in mp_hal_stdin_rx_chr, the piped-stdin path of 0013) block on that event, so a sleep or a REPL waiting for a key wakes the moment a deadline passes; init() also requests Windows' 1 ms timer resolution, as SDL does. Measured on a real Windows console: report() says source=native, a 10 ms timer delivers 507/500 idle and busy with 0.5 ms median jitter and 4 ms p99 lateness, and about 100 callbacks a second at an idle -i prompt (the earlier timer-queue draft pinned to the 15.6 ms system tick: 348/500, 20 a second at the prompt). Justification for an overlay patch: no Python-level route delivers on the main thread of a build without threads, and the REPL goal is the charter's first requirement. In the windows-full and windows-networked profiles.

The wasm bridge. usermods/wasmbridge/mod_wasm_bridge.c called external_call_depth_dec() with no argument where v1.29.0 takes one, so every timer callback in the direct wasm build ended in "null function or function signature mismatch" (fatal under node, a console error in a page). Fixed. The portal's and workbench's vendored runtime were built before the fix and want an mp-wasm rebuild after this merges.

Rebased over #23 with no conflict. Companions: PyDevices/lvgl-bindings#22, PyDevices/pydevices-examples#149. Draft until the Windows phase is in the ledger.

…e's call signature

0015 gives micropython.exe a wake source: a _timing module whose timer-queue
thread sets a flag the main thread notices between bytecodes, in sleeps and
in the console wait, then hands the callback to mp_sched_schedule from its
own context. multimer's native source is its only caller. In the windows
profiles; compile-checked with mingw and smoked under wine (the VM-hook and
sleep paths; the console and pipe waits need a real Windows console).

The wasm bridge called external_call_depth_dec with no argument; v1.29.0
takes the object to keep rooted. The call went through an invoke wrapper
with the wrong signature, so every timer callback in the direct wasm build
ended in "null function or function signature mismatch" (fatal under node,
a console error in a page). It passes mp_const_none now.
…event, 1 ms timer resolution

The cloud's first version used a timer-queue timer and 10 ms wait slices;
on a real Windows console it fell to the 15.6 ms system tick (a 10 ms
multimer timer: 348/500 idle, 339 busy, 20 a second at the prompt). Now one
waitable timer, high resolution where Windows offers it, on a helper thread
signals an event that MICROPY_INTERNAL_WFE, the console wait and the piped
stdin path block on, and init() asks for the 1 ms resolution as SDL does.
Same bench: 507/500 idle and busy, 0.5 ms median jitter, 4 ms p99 lateness,
about 100 a second at the prompt. mp_timing_poll keeps a deadline pending
when the scheduler queue is full, so a full queue cannot stop every timer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant