
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-embeddedAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 639 |
|---|---|
| repo stars | ★ 1.3k |
| Security audit | 2 / 3 scanners passed |
| Last updated | May 24, 2026 |
| Repository | zhanghandong/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
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 Rule | Design Constraint | Rust Implication |
|---|---|---|
| No heap | Stack allocation | heapless, no Box/Vec |
| No std | Core only | #![no_std] |
| Real-time | Predictable timing | No dynamic alloc |
| Resource limited | Minimal memory | Static buffers |
| Hardware safety | Safe peripheral access | HAL + ownership |
| Interrupt safe | No blocking in ISR | Atomic, critical sections |
---
Critical Constraints
No Dynamic Allocation
RULE: Cannot use heap (no allocator)
WHY: Deterministic memory, no OOM
RUST: heapless::Vec<T, N>, arraysInterrupt Safety
RULE: Shared state must be interrupt-safe
WHY: ISR can preempt at any time
RUST: Mutex<RefCell<T>> + critical sectionHardware 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
| Layer | Examples | Purpose |
|---|---|---|
| PAC | stm32f4, esp32c3 | Register access |
| HAL | stm32f4xx-hal | Hardware abstraction |
| Framework | RTIC, Embassy | Concurrency |
| Traits | embedded-hal | Portable drivers |
Framework Comparison
| Framework | Style | Best For |
|---|---|---|
| RTIC | Priority-based | Interrupt-driven apps |
| Embassy | Async | Complex state machines |
| Bare metal | Manual | Simple apps |
Key Crates
| Purpose | Crate |
|---|---|
| Runtime (ARM) | cortex-m-rt |
| Panic handler | panic-halt, panic-probe |
| Collections | heapless |
| HAL traits | embedded-hal |
| Logging | defmt |
| Flash/debug | probe-run |
Design Patterns
| Pattern | Purpose | Implementation |
|---|---|---|
| no_std setup | Bare metal | #![no_std] + #![no_main] |
| Entry point | Startup | #[entry] or embassy |
| Static state | ISR access | Mutex<RefCell<Option<T>>> |
| Fixed buffers | No heap | heapless::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
| Mistake | Domain Violation | Fix |
|---|---|---|
| Using Vec | Heap allocation | heapless::Vec |
| No critical section | Race with ISR | Mutex + interrupt::free |
| Blocking in ISR | Missed interrupts | Defer to main loop |
| Unsafe peripheral | Hardware conflict | HAL ownership |
---
Trace to Layer 1
| Constraint | Layer 2 Pattern | Layer 1 Implementation |
|---|---|---|
| No heap | Static collections | heapless::Vec<T, N> |
| ISR safety | Critical sections | Mutex<RefCell<T>> |
| Hardware ownership | Singleton | take().unwrap() |
| no_std | Core-only | #![no_std], #![no_main] |
---
Related Skills
| When | See |
|---|---|
| Static memory | m02-resource |
| Interior mutability | m03-mutability |
| Interrupt patterns | m07-concurrency |
| Unsafe for hardware | unsafe-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.