
Porting a PyTorch model to a microcontroller sounds like a model problem, but it's really a pipeline problem. A keyword-spotting model needs audio resampled, windowed, FFT'd, run through a Mel filterbank, log-compressed, and normalized before it ever reaches the network — and the constants controlling each step (window size, FFT convention, epsilon values) are usually scattered across config files nobody rereads. Get one of them wrong in the C rewrite and the device still boots fine; it just quietly predicts the wrong thing, with no black-box "pass/fail" test telling you why. Code2Edge solves this with stage-wise differential parity instead of black-box testing. The same audio corpus runs through both the Python reference pipeline and the generated C pipeline, and every intermediate tensor is compared — max/mean absolute error, cosine similarity, and eventually prediction agreement. If a stage drifts past tolerance, the system flags exactly which stage and offers a deterministic hint (e.g., "shape mismatch at framing — check hop length"), so debugging starts from evidence instead of guesswork. Bob drives this as an orchestrator, not a black-box code generator. An MCP server gives it five hardware-aware tools (profiling the model, inspecting the pipeline, checking the target, running parity tests, benchmarking) plus workflow tools for starting runs and gating steps. Bob follows a fixed sequence: analyze the repo, produce an Edge Readiness Report, pause for a human APPROVE/REJECT, generate code, run a host parity gate (with a 3-attempt repair loop before escalating to a human), build for the MCU, run a device parity gate, benchmark on real silicon, and open a pull request. The target users are embedded/ML engineers who need confidence that a ported pipeline behaves identically to its source model — not just that it compiles. The project is grounded in a real trained workload: a 119,372-parameter DS-CNN for 12-class keyword spotting (96.65% test accuracy), deployed to an STM32U585 (Cortex-M33) on an Arduino UNO Q. What makes this different is the discipline around honesty: every reported number is explicitly labeled real (measured from an artifact) or mock (a placeholder for an unavailable dependency), and the two are never mixed. Host-side parity is fully real and passing across 500 samples and 4 pipeline stages. Physical benchmarking is real and passing on actual silicon (50/50 correct inferences). Device-side parity is real but currently limited to a single fixture rather than the full corpus — an openly disclosed gap, with a hardware-validation guide checked in to finish the job.
27 Sep 2026