Embedded Systems
Implement firmware, RTOS tasks, and peripheral drivers on MCUs with a repeatable analyze-design-implement-validate workflow.
Overview
embedded-systems is an agent skill for the Build phase that guides firmware development, RTOS structure, and resource-constrained optimization on microcontrollers.
Install
npx skills add https://github.com/jeffallan/claude-skills --skill embedded-systemsWhat is this skill?
- Six-step core workflow from constraints through test and verify
- STM32, ESP32, FreeRTOS, bare-metal, DMA, and interrupt coverage
- Compile with -Wall -Werror and static analysis expectations
- Power, RAM, and timing optimization guidance
- Logic analyzer and stack-usage validation called out explicitly
- 6-step core workflow from analyze constraints through test and verify
Adoption & trust: 3.9k installs on skills.sh; 9.7k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need microcontroller firmware with correct interrupts and timing, but generic coding advice ignores memory limits, datasheets, and RTOS constraints.
Who is it for?
Builders implementing STM32 or ESP32 firmware, FreeRTOS apps, or bare-metal peripherals who already have a board and toolchain.
Skip if: Pure mobile app UI, cloud-only APIs, or teams without hardware to test timing and power on real silicon.
When should I use this skill?
Developing firmware for microcontrollers, RTOS applications, power optimization, STM32, ESP32, FreeRTOS, peripherals, interrupts, DMA, or timing debug.
What do I get? / Deliverables
You get structured driver and RTOS implementation steps with compile-time rigor and hardware verification habits before you ship hardware.
- HAL and peripheral driver implementations
- RTOS task architecture and validated firmware build (-Wall -Werror)
Recommended Skills
Journey fit
Firmware and driver work happens while building the physical or IoT product core, before ship-time hardware validation. Bare-metal and RTOS code is device backend logic—memory maps, ISRs, and HAL—not storefront or marketing surfaces.
How it compares
Firmware implementation playbook for MCUs, not a generic refactor or web backend skill.
Common Questions / FAQ
Who is embedded-systems for?
Solo hardware-leaning developers and indie IoT makers writing on-device C/C++ for ARM MCUs and common RTOS stacks.
When should I use embedded-systems?
During Build when you configure peripherals, write ISRs or DMA, stand up FreeRTOS tasks, or debug real-time and power issues on target hardware.
Is embedded-systems safe to install?
Treat generated register and ISR code as safety-critical; review the Security Audits panel on this page and validate on bench hardware before production flash.
SKILL.md
READMESKILL.md - Embedded Systems
# Embedded Systems Engineer Senior embedded systems engineer with deep expertise in microcontroller programming, RTOS implementation, and hardware-software integration for resource-constrained devices. ## Core Workflow 1. **Analyze constraints** - Identify MCU specs, memory limits, timing requirements, power budget 2. **Design architecture** - Plan task structure, interrupts, peripherals, memory layout 3. **Implement drivers** - Write HAL, peripheral drivers, RTOS integration 4. **Validate implementation** - Compile with `-Wall -Werror`, verify no warnings; run static analysis (e.g. `cppcheck`); confirm correct register bit-field usage against datasheet 5. **Optimize resources** - Minimize code size, RAM usage, power consumption 6. **Test and verify** - Validate timing with logic analyzer or oscilloscope; check stack usage with `uxTaskGetStackHighWaterMark()`; measure ISR latency; confirm no missed deadlines under worst-case load; if issues found, return to step 4 ## Reference Guide Load detailed guidance based on context: | Topic | Reference | Load When | |-------|-----------|-----------| | RTOS Patterns | `references/rtos-patterns.md` | FreeRTOS tasks, queues, synchronization | | Microcontroller | `references/microcontroller-programming.md` | Bare-metal, registers, peripherals, interrupts | | Power Management | `references/power-optimization.md` | Sleep modes, low-power design, battery life | | Communication | `references/communication-protocols.md` | I2C, SPI, UART, CAN implementation | | Memory & Performance | `references/memory-optimization.md` | Code size, RAM usage, flash management | ## Constraints ### MUST DO - Optimize for code size and RAM usage - Use `volatile` for hardware registers and ISR-shared variables - Implement proper interrupt handling (short ISRs, defer work to tasks) - Add watchdog timer for reliability - Use proper synchronization primitives - Document resource usage (flash, RAM, power) - Handle all error conditions - Consider timing constraints and jitter ### MUST NOT DO - Use blocking operations in ISRs - Allocate memory dynamically without bounds checking - Skip critical section protection - Ignore hardware errata and limitations - Use floating-point without hardware support awareness - Access shared resources without synchronization - Hardcode hardware-specific values - Ignore power consumption requirements ## Code Templates ### Minimal ISR Pattern (ARM Cortex-M / STM32 HAL) ```c /* Flag shared between ISR and task — must be volatile */ static volatile uint8_t g_uart_rx_flag = 0; static volatile uint8_t g_uart_rx_byte = 0; /* Keep ISR short: read hardware, set flag, exit */ void USART2_IRQHandler(void) { if (USART2->SR & USART_SR_RXNE) { g_uart_rx_byte = (uint8_t)(USART2->DR & 0xFF); /* clears RXNE */ g_uart_rx_flag = 1; } } /* Main loop or RTOS task processes the flag */ void process_uart(void) { if (g_uart_rx_flag) { __disable_irq(); /* enter critical section */ uint8_t byte = g_uart_rx_byte; g_uart_rx_flag = 0; __enable_irq(); /* exit critical section */ handle_byte(byte); } } ``` ### FreeRTOS Task Creation Skeleton ```c #include "FreeRTOS.h" #include "task.h" #include "queue.h" #define SENSOR_TASK_STACK 256 /* words */ #defin