In The Wild with 62 Active Installs

FREE RAG Converter Online -- RAGconverter.com

rusty_esp_core

The shared vocabulary of the Janus ESP32 family: borrowed media frames, PCM blocks, monotonic timestamps, one Copy error, a signed capability manifest with an honesty rule, and the three hardware seams — clock, entropy, key-value store — that every backend fills. No drivers, no allocator, no product types, no C, no FFI. forbid(unsafe). no_std by default; alloc and std are features.

• Frames are views, not owners. Frame<'a> is a validated window onto memory the caller already has — a DMA ring, a static arena, a host Vec. The FFmpeg-shaped Vec<Vec<u8>>-per-frame model costs one-plus-N heap allocations per frame on a part with 512 KB of SRAM. Sources write into caller buffers; encoders read views; a camera frame reaches the network with no conversion and no copy.
• One error, and it crosses every boundary. A single Copy enum with no String in it, so a no_std driver and a std service return the same type.
• Capabilities that can be refused. A Manifest names a model, a firmware, a chip and what the device declares it can do — each with a status and the crate that backs it — in a canonical line encoding that rusty_esp_mid signs. A device that claims a capability it does not have is making a signed, attributable statement.
• Seams, not implementations. Clock, Rng and Kv are traits here. The backends live in rusty_esp_core-esp and in the function packages, so this crate compiles for a microcontroller and for a laptop test with the same source.

What has run on hardware

This crate is Layer 0, so it does not run alone — it runs inside every profile the family has verified on silicon. Five of seven have, on two boards. What was measured here, directly:

The entropy result is a smoke test, not a certification: five statistics, one megabyte, one part, one temperature. The control arm is the point — a wrong implementation would have been wrong in both columns.

Every number, with the run that produced it: docs/LEDGER.md. This README makes no claim that is not backed by a test in the repository.

Using it

use rusty_esp_core::prelude::*;

// A validated view over memory the caller already owns. No copy, no alloc.
let geometry = Geometry::new(320, 240, PixelFormat::Rgb565)?;
let frame = Frame::packed(geometry, clock.now(), seq, &dma_buffer[..])?;

// What this device says it can do -- and what it admits it cannot.
let manifest = Manifest {
    model: "acme/doorbell-2",
    firmware: "1.4.0",
    chip: Chip::Esp32S3,
    declared: &[
        Declared::available(Capability::ImageJpeg, "rusty_esp_image"),
        Declared::planned(Capability::IrohRelay),
    ],
};
let n = manifest.encode(&mut buf)?;   // deterministic bytes: sign them

Two tracks, one vocabulary

Everything in the family is built for both, and this crate is what makes that possible: the same types compile for a supervised chip and a bare one.

cargo test --workspace
cargo check -p rusty_esp_core --no-default-features --target riscv32imac-unknown-none-elf
cargo check -p rusty_esp_core --no-default-features --features alloc --target riscv32imac-unknown-none-elf

The seams

Two crates in this repo exist to hold a decision once, so no firmware in the family makes it twice.

rusty_esp_alloc — the allocator seam. One place names rusty_alloc, holds its exact pin, and hands out the type and the bare-metal region; the deliverable's own main does the declaring, because a library must never declare a global allocator.

rusty_esp_rtos — the RTOS seam, new in 0.1.1. One place names the Kairos kernel's ports and the esp-hal window they have to agree with. Two rungs: port brings the context-switch primitives, kernel adds the scheduler. Nothing by default, so adding it changes no existing build.

It is not theoretical — on a XIAO ESP32-S3 the Kairos port runs under a Janus firmware at +0.025% on sign and −0.028% on verify, and two tasks chosen by Kernel::switch_context pass through the seam with 103 real swaps and zero witness faults.

Part of Janus

Janus rebuilds the Espressif ESP32 and Arduino application portfolio as independent, memory-safe Rust packages — so a hardware maker can ship a device that the MATA home computer discovers, catalogs honestly, adopts under its own identity, and pays for. Ten packages, three layers, and the dependency direction never reverses.

Every package is host-verified against an external oracle and keeps a ledger in which no number appears without the run that produced it. Five of seven device profiles have now run their kill tests on real silicon, three of them over a Wi-Fi network the board hosts itself.

Also check out the rest of Remade With Rust — including rusty_alloc, the pure-Rust rebuild of mimalloc that these firmwares run on, and rusty_jpeg, the JPEG engine behind the camera path — and our sister project remade_ffmpeg_rs, a ground-up Rust rebuild of FFmpeg.

About Mata Network

Mata Network builds sovereign, self-hostable infrastructure. Remade With Rust is our open-source home for the permissively-licensed building blocks that work depends on.

License

MIT OR Apache-2.0, at your option. See LICENSE-MIT and LICENSE-APACHE.