Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
zhanghandong avatar

Domain Embedded

  • 639 installs
  • 1.3k repo stars
  • Updated May 24, 2026
  • zhanghandong/rust-skills

This is a copy of domain-embedded by actionbook - installs and ranking accrue to the original listing.

domain-embedded is a Rust agent skill that enforces no_std embedded constraints—heap safety, ISR races, and HAL ownership—for developers shipping bare-metal or MCU firmware on ARM, RISC-V, ESP32, STM32, and nRF targets.

About

domain-embedded is a Layer 3 domain-constraints skill in the rust-skills collection for no_std embedded Rust on microcontrollers and bare-metal boards. It auto-injects project context from Cargo.toml and .cargo/config.toml, then maps domain rules—interrupt safety, DMA timing, peripheral ownership, and RTIC or Embassy patterns—to concrete Rust design choices developers must follow. The skill covers embedded-hal, PAC/HAL layering, cortex-m, and common toolchains for ARM and RISC-V MCUs including ESP32, STM32, and nRF families. Developers reach for domain-embedded when firmware must compile without heap surprises, when ISR handlers risk data races, or when HAL borrow rules block GPIO, SPI, I2C, or UART bring-up. It is invoked on embedded/no_std tasks rather than general application Rust.

  • Maps six domain rules (no heap, no std, real-time, resource limits, hardware safety, interrupt safety) to Rust design ch
  • Enforces heapless buffers and static allocation patterns instead of Box/Vec on MCUs
  • Documents ISR-safe shared state with Mutex<RefCell<T>> and critical sections
  • Auto-injects target config from .cargo/config.toml at skill load
  • Covers GPIO, SPI, I2C, UART, DMA, Embassy, RTIC, cortex-m, ESP32, STM32, nRF vocabulary

Domain Embedded by the numbers

  • 639 all-time installs (skills.sh)
  • +7 installs in the week ending Jul 28, 2026 (Skillselion tracking)
  • Security screen: HIGH risk (skills.sh audit)
  • Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/zhanghandong/rust-skills --skill domain-embedded

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs639
repo stars1.3k
Security audit2 / 3 scanners passed
Last updatedMay 24, 2026
Repositoryzhanghandong/rust-skills

How do you write safe no_std Rust firmware on MCUs?

Ship bare-metal or MCU firmware in Rust without heap surprises, ISR races, or HAL ownership bugs.

Who is it for?

Firmware engineers writing bare-metal or MCU Rust with embedded-hal, RTIC, Embassy, or PAC crates on ARM, RISC-V, ESP32, STM32, or nRF hardware.

Skip if: Developers building standard std Rust web services, CLI tools, or desktop apps without microcontroller or bare-metal targets.

When should I use this skill?

The user is developing embedded/no_std Rust firmware and hits HAL ownership, interrupt, DMA, or heap-allocation problems in Cargo-based MCU projects.

What you get

Embedded design decisions aligned to no_std constraints, ISR-safe patterns, and peripheral driver code that respects HAL ownership rules.

  • ISR-safe peripheral driver patterns
  • no_std firmware design decisions

By the numbers

  • Matches Cargo.toml and .cargo/config.toml via two glob patterns

Files

SKILL.mdMarkdownGitHub ↗

Project Context (Auto-Injected)

Target configuration: !cat .cargo/config.toml 2>/dev/null || echo "No .cargo/config.toml found"

---

Embedded Domain

Layer 3: Domain Constraints

Domain Constraints → Design Implications

Domain RuleDesign ConstraintRust Implication
No heapStack allocationheapless, no Box/Vec
No stdCore only#![no_std]
Real-timePredictable timingNo dynamic alloc
Resource limitedMinimal memoryStatic buffers
Hardware safetySafe peripheral accessHAL + ownership
Interrupt safeNo blocking in ISRAtomic, critical sections

---

Critical Constraints

No Dynamic Allocation

RULE: Cannot use heap (no allocator)
WHY: Deterministic memory, no OOM
RUST: heapless::Vec<T, N>, arrays

Interrupt Safety

RULE: Shared state must be interrupt-safe
WHY: ISR can preempt at any time
RUST: Mutex<RefCell<T>> + critical section

Hardware Ownership

RULE: Peripherals must have clear ownership
WHY: Prevent conflicting access
RUST: HAL takes ownership, singletons

---

Trace Down ↓

From constraints to design (Layer 2):

"Need no_std compatible data structures"
    ↓ m02-resource: heapless collections
    ↓ Static sizing: heapless::Vec<T, N>

"Need interrupt-safe state"
    ↓ m03-mutability: Mutex<RefCell<Option<T>>>
    ↓ m07-concurrency: Critical sections

"Need peripheral ownership"
    ↓ m01-ownership: Singleton pattern
    ↓ m12-lifecycle: RAII for hardware

---

Layer Stack

LayerExamplesPurpose
PACstm32f4, esp32c3Register access
HALstm32f4xx-halHardware abstraction
FrameworkRTIC, EmbassyConcurrency
Traitsembedded-halPortable drivers

Framework Comparison

FrameworkStyleBest For
RTICPriority-basedInterrupt-driven apps
EmbassyAsyncComplex state machines
Bare metalManualSimple apps

Key Crates

PurposeCrate
Runtime (ARM)cortex-m-rt
Panic handlerpanic-halt, panic-probe
Collectionsheapless
HAL traitsembedded-hal
Loggingdefmt
Flash/debugprobe-run

Design Patterns

PatternPurposeImplementation
no_std setupBare metal#![no_std] + #![no_main]
Entry pointStartup#[entry] or embassy
Static stateISR accessMutex<RefCell<Option<T>>>
Fixed buffersNo heapheapless::Vec<T, N>

Code Pattern: Static Peripheral

#![no_std]
#![no_main]

use cortex_m::interrupt::{self, Mutex};
use core::cell::RefCell;

static LED: Mutex<RefCell<Option<Led>>> = Mutex::new(RefCell::new(None));

#[entry]
fn main() -> ! {
    let dp = pac::Peripherals::take().unwrap();
    let led = Led::new(dp.GPIOA);

    interrupt::free(|cs| {
        LED.borrow(cs).replace(Some(led));
    });

    loop {
        interrupt::free(|cs| {
            if let Some(led) = LED.borrow(cs).borrow_mut().as_mut() {
                led.toggle();
            }
        });
    }
}

---

Common Mistakes

MistakeDomain ViolationFix
Using VecHeap allocationheapless::Vec
No critical sectionRace with ISRMutex + interrupt::free
Blocking in ISRMissed interruptsDefer to main loop
Unsafe peripheralHardware conflictHAL ownership

---

Trace to Layer 1

ConstraintLayer 2 PatternLayer 1 Implementation
No heapStatic collectionsheapless::Vec<T, N>
ISR safetyCritical sectionsMutex<RefCell<T>>
Hardware ownershipSingletontake().unwrap()
no_stdCore-only#![no_std], #![no_main]

---

Related Skills

WhenSee
Static memorym02-resource
Interior mutabilitym03-mutability
Interrupt patternsm07-concurrency
Unsafe for hardwareunsafe-checker

Related skills

How it compares

Pick domain-embedded over general Rust skills when the codebase is no_std MCU firmware with HAL, ISR, or DMA constraints rather than std application Rust.

FAQ

When should developers use domain-embedded?

domain-embedded activates for no_std embedded Rust on microcontrollers and bare-metal targets. Use it when configuring Cargo.toml, .cargo/config.toml, or debugging HAL ownership, ISR, DMA, and peripheral driver issues on ARM, RISC-V, ESP32, STM32, or nRF boards.

Does domain-embedded support RTIC and Embassy?

domain-embedded documents constraints for RTIC and Embassy alongside embedded-hal and PAC/HAL patterns. The skill maps interrupt models, peripheral timing, and ownership rules to Rust-safe designs for GPIO, SPI, I2C, UART, and DMA on MCU firmware.

Is Domain Embedded safe to install?

skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

Rustbackendintegrations

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.