// the find
rust-embedded/cortex-m
Low level access to Cortex-M processors
The official Rust crates for writing bare-metal programs on ARM Cortex-M processors. Maintained by the Rust Embedded Working Group, it covers everything from startup code and interrupt handling to peripheral register access and semihosting debug output. If you're writing Rust for STM32, nRF, or any other Cortex-M chip, this is the foundation your HAL crate almost certainly depends on.
The compile-fail test suite is unusually thorough — there are dedicated tests ensuring the macros reject bad interrupt signatures, duplicate handlers, and soundness violations at compile time, which is exactly where embedded bugs need to be caught. The crate split is sensible: cortex-m handles CPU peripherals and intrinsics, cortex-m-rt owns the vector table and startup sequence, and panic handlers are separate opt-in crates. The on-target CI workflow runs tests on real hardware in a QEMU loop, not just host-side simulation. Cortex-M Security Extensions (TrustZone-M) support is present via cmse.rs, which many competing ecosystems skip entirely.
Documentation lives almost entirely in rustdoc and the README is essentially a crate index — someone new to embedded Rust has no guided path through the layers (what goes in memory.x, when to use cortex-m-rt vs just cortex-m, how the linker script interacts with your chip's HAL). The peripheral coverage skips some less-common Cortex-M peripherals (FPB is skeletal, AC is barely stubbed), so you may hit a wall if you need low-level debug peripheral access. semihosting is slow by definition and the crate doesn't warn you loudly enough that leaving it enabled in release will halt your chip if no debugger is attached — a footgun that bites beginners regularly. Version churn between cortex-m and cortex-m-rt has historically caused dependency resolution pain when a HAL pins one version and your app needs another.