flipperzero-rs: writing Rust applications for the Flipper Zero without the firmware toolchain

Four crates split by abstraction level

The crate set is organised by how much safety the caller opts into, and that split is the clearest way to understand the library. The flipperzero crate gives high-level safe bindings, and it is the one most application code should use. flipperzero-sys provides low-level bindings to the Flipper Zero API and is explicitly unsafe, existing for the cases where the safe layer does not cover something. flipperzero-rt is runtime support, including the panic handler and the entry point helper, which is the piece you cannot write yourself in a no_std binary. The fourth is flipperzero-alloc, a custom global allocator, and the README marks it as required for the alloc crate. The dependency order follows from this: you take the high-level crate, you take the runtime crate, and you add the allocator only if you want heap allocation.

No dependency on the firmware repository means no external dependencies

The claim that distinguishes this project from a straightforward binding generator is in the README: it does not have any direct dependency on the flipperzero-firmware project or its toolchain, so it can be used to build binaries with no external dependencies. This matters more than it first appears. The usual approach to binding a C firmware to another language is to generate bindings from the firmware headers and link against the firmware libraries, which means your build depends on a specific checkout of a large C repository and on a specific build of it. Here the bindings are hand-maintained Rust and the ABI surface is described by the firmware's API symbol list, so the artefact you ship is a self-contained binary. For a device with limited storage and a firmware update cycle, that is a meaningful operational property rather than a nicety.

no_std only, because the target has no operating system behind it

The constraints are stated plainly. The crates support only the core and alloc crates, and the Rust thumbv7em-none-eabihf target currently only supports no_std development, which means it is not possible to use anything in the std crate. The thumbv7em-none-eabihf triple is a bare-metal ARM target, and the name encodes the absence of an operating system: the hf suffix means hardware floating point, which matters when you are linking. The practical consequence for a developer arriving from server-side Rust is that the whole std-shaped world is missing. There is no threading, no file system, no networking from the standard library, and the collections come from alloc rather than from std.

Setup is rustup, one target, and a template repository

The initial setup is two steps, and the second one is the only thing you have to remember. You install rustup following the instructions on rustup.rs, then use rustup to add the bare-metal target.

rustup target add thumbv7em-none-eabihf

That is the whole toolchain requirement, and the absence of a firmware toolchain in the setup is the point made earlier. For actually writing something, the README points at the flipperzero-template repository as the way to get started, and it also notes that the Flipper Zero supports installing externally built applications on the SD card, which is how a built binary reaches the device. The repository layout backs this up with an applications_user directory for the applications that ship in the user's area, a crates directory holding the four crates, a tools directory, a docs directory, plus a .envrc and a flake.nix for a Nix-based development environment and a rustfmt.toml for formatting.

Crate version tracks the firmware API version, and the jumps are large

The versioning policy is unusual and worth reading before you pin anything. The README says the crate major version number will be updated after a bump in the API version in the Flipper Zero firmware, and gives a table mapping crate versions to API versions. HEAD and 0.16.x sit at API 87.1, which is the version the project currently supports, matching the flipperzero-firmware 1.3.4 release. Below that, 0.15.x is API 86.0, 0.14.x is 79.2, 0.13.x is 78.0, 0.12.x is 73.0, 0.11.x is 35.0, 0.10.x is 28.2, and the numbers keep climbing back through 0.9.x at 23.0, 0.8.x at 20.0 and down to 0.3.x at 2.2. The jumps are not incremental. Moving from 0.10.x to 0.11.x crossed seven API versions at once, so a minor bump in this project can mean a substantial rewrite of anything that touches the bound symbols. The alternative is to stay on an older crate major and accept an older API surface, which is the trade the table exists to help you make.

A small but real ecosystem around one device

The project is part of a broader Flipper Zero Rust effort rather than a standalone library. The release history shows v0.15.0 in April 2025, v0.14.0 in January 2025 and v0.13.0 in November 2024, with the repository not archived and the last push on 2026-09-21, so work is still landing between tagged releases. The documentation link points at docs.rs for the flipperzero crate, and the API badge references the firmware's own symbol list for the exact API revision. The licence is MIT, which matters for a device community where people write tools for each other's hardware and share them. The repository also carries a CHANGELOG.md, a CODE_OF_CONDUCT.md, a .pinact.yaml for pinning GitHub Actions versions, a .vscode directory and an .editorconfig, which is the ordinary apparatus of a project that expects outside contributions.

Editorial conclusion

flipperzero-rs fits a Rust developer who wants to write real applications for a Flipper Zero and is comfortable with no_std, embedded targets and unsafe FFI, and who wants binaries that pull in nothing else. It does not fit a team that needs the standard library, a hosted test harness or a normal Cargo build for a desktop target, since the supported target is thumbv7em-none-eabihf and std is explicitly unavailable. Verify first which API version your firmware ships, because the crate major version tracks the firmware API version and the table shows large jumps between them, and start from the flipperzero-template repository rather than from an empty Cargo project.

Frequently asked questions

Official sources

1. flipperzero-rs/flipperzero-rs on GitHub
2. Issues
3. License: MIT
4. README
5. Releases