Mojo is usually pointed at GPUs and AI kernels. I wanted to see how far the other direction goes, so I wrote a bare-metal firmware and peripheral SDK for the Raspberry Pi Pico (RP2040, a dual Cortex-M0+) in pure Mojo — no OS, no C application layer. The whole application plus SDK is Mojo; startup is ~60 lines of assembly and one linker script.
[IMAGE 1 — docs/assets/hw-tests.png] (hero: the on-hardware test suite, all green)
A complete blink is 780 bytes, and it turns out that’s byte-for-byte the size of the same blink compiled with clang -O2 on the identical rig. Blinking an LED looks like this:
import pico
from pico import Pin, pins, sleep_ms
@export("mojo_main")
def start() abi("C"):
pico.init()
var led = Pin[pins.LED]() # pin number is a compile-time parameter;
led.make_output() # Pin[99]() is a compile-time error
while True:
led.toggle()
sleep_ms(250)
The trick that makes it possible
[IMAGE 2 — docs/assets/pipeline.png] (the retarget pipeline)
The bundled Mojo LLVM has no 32-bit ARM backend, so mojo build can’t target
Cortex-M0+ directly. The workaround is a source-to-source-ish pipeline at the
IR level:
mojo build --emit=llvmtargeting riscv32 — it shares the exact ILP32
little-endian data model of ARMv6-M, so the emitted IR is layout-compatible.- Rewrite the target triple + datalayout to
thumbv6m-none-eabi, and downgrade
the handful of IR constructs the system LLVM (18) doesn’t understand yet
(captures(none),#dbg_*records,f0xfloat literals, single-arg
lifetime intrinsics). - System
opt -O2/llc -O2→ Cortex-M0+ object. arm-none-eabi-gcclinks it with crt0 + linker script + boot2 + libgcc.
The retarget pass is guarded by unit tests, opt -verify, and a check that the number of volatile ops is preserved end to end. When a nightly emits new IR syntax, supporting it is usually one more rewrite rule. (The whole pipeline driver is itself a Mojo program, not a shell script.)
What’s measured
[IMAGE 3 — docs/assets/benchmarks.png] (9 workloads × 4 languages, normalized to clang C)
I didn’t want to hand-wave the performance claim, so the benchmark builds the same 9 workloads four ways — Mojo, gcc -O2, clang -O2 (same LLVM backend as Mojo, which is the fair yardstick for language overhead), and Rust opt-level=2 — on the same board, crt0, clocks and 1 MHz timer, three runs each, with checksums verified identical across all four languages.
- Register-loop microbenchmarks: Mojo == clang C to the microsecond (the 200k-round xorshift is 102,501 µs in all three of Mojo / clang / Rust).
- Larger workloads (CRC-32, quicksort, 16×16 matmul, recursive fib): Mojo lands within ±13% of clang C, ahead on some, behind on others — ordinary optimizer variance, no systematic “language tax”, no cliff as programs grow.
Full methodology and the honest caveats (Rust’s own compiler-builtins skew the division/float rows; XIP flash alignment adds noise on tight loops) are in the repo’s BENCHMARKS.md.
What the SDK does today
GPIO (pins as compile-time-checked types), PIO (assembler written as method calls, with side-set, forward labels, and compile-time assembly — a PIO program can be a comptime value so the instruction words become flash constants, with comptime assert turning an invalid program into a build error), PWM, ADC + on-die temperature sensor, UART, NVIC interrupts, RTT
logging, dual-core launch, SIO hardware spinlocks and inter-core FIFO.
Everything is backed by 26 on-target tests that run on real silicon (results written to a RAM mailbox, read back over SWD) — including a genuinely contended dual-core spinlock test (2×20k increments == exactly 40,000) and full F5 breakpoint debugging validated over the DAP protocol. There’s a scheduled CI job that re-tests against the newest nightly daily.
The stack, end to end
- Language & toolchain: Mojo nightly, managed by pixi (pinned lock for reproducibility, plus a daily CI job that re-tests against the newest nightly so breakage surfaces within a day).
- Build:
mojo build --emit=llvm→tools/retarget.mojo→ system LLVM 18opt/llc→arm-none-eabi-gccwith a 60-line crt0.S, one linker script, and boot2 assembled from vendored pico-sdk source (checksummed at build time, regression-tested byte-identical to the reference). - The tooling is Mojo, too: the pipeline driver, IR retarget pass, ELF verifier, benchmark driver and chart generator are all Mojo programs — Python survives only as the test orchestrator and DAP protocol client.
- Debugging: probe-rs + VS Code — press F5 and you get breakpoints, stepping, variables, CPU registers and live SVD peripheral views in the
.mojosources, on a $4 MCU. RTT logging over the same probe, no UART wires. - Tests & CI: Mojo host unit tests (retarget rules, PIO encodings, boot2 provenance) + the 26-test on-target suite over SWD; GitHub Actions runs the host suite on every push and the newest-nightly job on a schedule.
- Packaging: the SDK installs into any pixi project via the
pixi-build-mojobackend —pixi add --githttps://github.com/Hundo1018/inmojomni.git` inmojomni, thenimport pico`. (Verified end-to-end from a fresh environment.)
Where I could use the team’s input (embedded feedback)
A few things came up that I think are relevant to Mojo reaching freestanding / embedded targets, and I’d love to know what’s on the radar:
- A 32-bit ARM (thumbv6m/v7m) backend would remove the entire retarget hack. The riscv32 detour works precisely because the data models match, but it’s a workaround.
- Discarded volatile loads.
_ = read32(mmio_addr)(a volatile load whose result is unused) is dropped by the elaborator before it reaches LLVM, so the volatile access never happens. On an MCU this is a real footgun — I hit it as a hang draining a hardware FIFO and had to route the value into a branch with a side effect to keep the load alive. Is eliminating an unused-but-volatile load intended? (Happy to file a minimal repro.) - A no-std / freestanding profile. The bounds-check/assert path pulls in a small printf/formatting machinery; on bare metal I stub those symbols to a
bkpttrap. A supported freestanding profile (and a way to opt the assert I/O into a user-provided trap) would make this cleaner.
On the flip side, comptime is a joy here — folding an entire register map to immediates, and assembling PIO programs at compile time with real assertions, are exactly the ergonomics that make this fun rather than painful.
It’s experimental and pinned to nightly (the language isn’t 1.0), but every claim in the README has a test behind it. Feedback, questions, and “you’re holding LLVM wrong” corrections all very welcome.
Disclosure of AI-generated content:
In line with community guidelines, I wish to disclose that this article was entirely written by Claude to convey my intended message.