rusty_esp_core Is a Pure Rust Alternative to Shared C Headers
rusty_esp_core is a pure Rust alternative to shared C headers: one no_std vocabulary for frames, PCM, errors, and a signed manifest, with unsafe forbidden.

Is rusty_esp_core a pure Rust alternative to shared C headers?
Yes. rusty_esp_core is a pure Rust alternative to shared C headers: the types every Janus package speaks at its boundary. It is no_std by default, forbids unsafe code, and has no C and no FFI. It defines frames, PCM blocks, one error, a signed manifest, and clock, rng, and kv traits. It does not contain drivers.
Related reading
Builder field note
rusty_esp_core: The Shared Vocabulary Every Janus ESP32 SpeaksAPIs, composition, and home deployment for rusty_esp_core: The Shared Vocabulary Every Janus ESP32 Speaks live on the field note.
rusty_esp_core is a pure Rust alternative to shared C headers for the types a firmware family otherwise copies into every component. A shared header is the market standard: one frame_t, one error enum, and a macro everyone is afraid to change. This crate is that header, as Rust, with forbid(unsafe), no allocator required, and no driver hidden inside. This page is the comparison. The builder field note on rusty_esp_core is the type record.
What a shared header becomes
The first camera package defines a frame. The audio package defines a block that is almost the same idea. Someone adds a field to one and not the other. A pure Rust alternative to shared C headers exists so that drift has one home, and so a package cannot grow a private dialect.
Layer 0, and the rule that keeps it small
Nothing in the family sits under rusty_esp_core. Video, audio, images, identity, and the mesh sit on top. A type belongs here only if a package needs it at its boundary, and only if it can be defined without esp-hal, ESP-IDF, serde, or a codec crate. If two packages want to share a type and it is not here, it is added here. It is not wired from one function package into another. That is how a maker can take audio without dragging video.
What is actually in it
Borrowed media frames, PCM blocks, monotonic timestamps, one Copy error, a signed capability manifest, and three traits: clock, entropy, and a key-value store whose keys are at most 15 bytes, matching ESP-IDF's NVS limit. The seam does not encrypt. Identity decides that. There is no C and no FFI. A pure Rust alternative to shared C headers that smuggled a driver into the root crate would have failed the rule.
Borrowed frames, and the manifest
An ESP32 has about 512 KB of internal SRAM. Allocating a buffer per frame spends that SRAM on the allocator. A Frame is a validated view over memory the caller already has. A camera frame can reach the network with no conversion and no copy at this layer. The capture crate still copies once out of the C driver's buffer on Track A. That copy is not this crate's.
The honesty rule on the manifest
The manifest is line-based text: model, firmware, chip, and each capability marked available, preview, or planned. A live claim has to name the crate behind it. The same facts always encode to the same bytes, which the device signs. A pure Rust alternative to shared C headers is also how a home computer can trust what a device says about itself, because the bytes do not depend on who printed them.
Seams, not backends
Rng on a chip must be a hardware generator. The laptop's test generator is called InsecureTestRng on purpose. The entropy seam was checked with 1 MB from an ESP32-S3 hardware generator against an operating-system control. The crate's own suite is 26 unit tests and 3 no-panic tests, on the host and on the cross compiles, with and without alloc.
Where a C header still wins
Keep a shared C header when the firmware on both sides of the boundary is C and a Rust crate would be a guest. A pure Rust alternative to shared C headers is the wrong root if the project is an ESP-IDF component written in C.
Honest limits
- This crate has no drivers, no product types, and no codecs. Kernels live in rusty_esp_dsp. Identity lives in rusty_esp_mid.
forbid(unsafe)is this crate. Other crates in the family useunsafewhere the hardware requires it, and they say so.- It runs inside verified profiles. It is not, by itself, a device you flash. espino is the tool that flashes one.
The failure mode of a shared header is quiet. Two packages compile. Their frames do not quite match. The bug shows up as a colour shift or a click, weeks later. A pure Rust alternative to shared C headers makes that mismatch a type error, or a manifest that will not sign because the bytes moved. That is a stricter review than a comment in a header file. It is also why the crate stays small: every extra type is a type every package must understand. A pure Rust alternative to shared C headers earns its place by refusing product types. A pure Rust alternative to shared C headers is not where a new codec goes. A pure Rust alternative to shared C headers is where the frame the codec already accepts is named once.
Where to start
Read the field note, then the package you actually need from the Learn index. Choose a board when the question is flash and PSRAM. The Connect vision is where this vocabulary sits in the map.
The source is part of Remade With Rust, the signed manifest speaks MATA, and the language is Rust. When a type note needs to become a retrieval corpus, the same house runs RAG Converter.
FAQ
Quick answers for builders evaluating this technology.
Why borrow a frame instead of defining a buffer struct in a header?
An ESP32 has about 512 KB of internal SRAM. A new heap buffer per frame is one or more allocations every frame. A borrowed Frame is a validated view over memory the caller already has, such as a DMA ring.
Does this pure Rust alternative to shared C headers need an allocator?
No. alloc and std are optional features. It is checked on riscv32imac, riscv32imafc, and xtensa-esp32s3-none-elf, with and without alloc.
What is the capability manifest?
A short line-based record of model, firmware, chip, and each capability as available, preview, or planned. A live claim must name the crate behind it. The same facts always encode to the same bytes, which the device signs with its identity key.
Who supplies time, entropy, and storage?
Not this crate. Clock, Rng, and Kv are traits. On a chip, Rng must be a hardware generator. The host test generator is named InsecureTestRng so nobody wires it to a key.
Has it run on hardware, or only on the host?
It runs inside every Janus profile verified on silicon. Its entropy seam was checked with 1 MB from an ESP32-S3 hardware generator against an operating-system control. The crate's own gates are 26 unit tests and 3 no-panic tests, plus the cross compiles.