Native runtime: run a deterministic sensor-to-actuator bench loop

What to build

Boot an owned runtime on one selected development board, read a timestamped synthetic sensor sample and drive a disabled-load test output with a measurable deadline. Choose the board and toolchain from measured timing and supported hardware rather than running a JavaScript motor loop on Linux.

Acceptance criteria

• Record board selection, licence/provenance, toolchain and reproducible boot/flash procedure.
• Demonstrate scheduler deadlines, memory bounds, hardware watchdog, safe reset and neutral outputs on a test harness.
• Version the Pi-to-runtime transport and capability handshake; reject incompatible versions and stale authority.
• Keep TypeScript mission logic separate from the board HAL. Record any required firmware-language exception explicitly before implementation.

Blocked by

None. This work can start independently.

Scope and evidence

Implementation progress and remaining acceptance gates are recorded below. Preserve explicit operator authority and report simulator, bench, HIL and vehicle evidence separately. The owned implementation must remain replaceable behind the shared driver and mission contracts.

Implementation progress

The first software slice is implemented on main. See the runtime guide, protocol specification, ADR 2 and validation evidence.

• Original allocation-free C++17 kernel with timestamped synthetic samples, neutral-only state, bounded leases and latched deadline/clock faults.
• Shared bounded UART framing/queue state machine with host tests for fragmentation, corruption, byte budgets and pending transmission.
• Pico 2 HAL and normal/watchdog-stall UF2 builds using pinned SDK, picotool and Arm GNU inputs.
• Versioned CRC-protected Pi codec and boot/session handshake; actual TypeScript-to-C++ freshness/replay/expiry tests.
• Native Stacks commands runtime:build, runtime:bench, runtime:inspect, plus a compiled standalone drone CLI using those same commands.
• Native CTest, 73 Bun tests, five camera-bridge tests, lint and type checks passed locally.
• Flash/boot a physical Pico 2 and retain exact board revision, normal/reset UART captures and boot-token results.
• Measure 1 kHz schedule, <=250 us start lateness, <=500 us execution, stack high-water and neutral GPIO across reset under the disabled-load procedure.
• Measure the 100 ms watchdog reset and fault recovery using the separate deliberate-stall image.
• Run the physical Pi-to-Pico UART freshness/version/lease/reset campaign and confirm or revise the candidate board selection.

Host virtual-clock and cross-compilation evidence do not satisfy the physical measurements above. This issue remains open. There is no arming, PWM, flight telemetry or non-neutral actuator command in this slice.