---
name: embedded-systems
description: >
  Use for a selected firmware component: microcontroller peripherals, ISR/DMA, RTOS timing/concurrency,
  constrained memory or power. Match its actual MCU/SDK; do not load for Python or web-only projects.
license: MIT
metadata:
  author: https://github.com/Jeffallan
  company: https://synergetic.solutions
  version: "1.1.0"
  domain: specialized
  triggers: embedded systems, firmware, microcontroller, RTOS, FreeRTOS, STM32, ESP32, bare metal, interrupt, DMA, real-time
  role: specialist
  scope: implementation
  output-format: code
---

# Embedded Systems Engineer

Firmware guidance for microcontrollers, RTOS implementation and hardware/software integration on resource-constrained
devices. Use only the topics needed for the selected component.

## Target compatibility and authority

Select this skill only for a firmware component, not a Python, web or ordinary Rust project. Read the
[firmware criteria](../../references/cpp-firmware.md) and actual board/environment, MCU architecture, SDK/RTOS and
compiler versions first. Preserve the selected language level and existing drivers; STM32 HAL, CMSIS/NVIC, ARM
interrupt intrinsics and ESP32 APIs are target-specific, not interchangeable implementation recipes.

When the selected target is ESP32 with Arduino/ESP-IDF, additionally preserve these API-specific constraints:

- IDF FreeRTOS task-creation stack depths and high-water marks are bytes, unlike vanilla FreeRTOS words. Confirm the
  exact API/version (including static allocation buffer element units) before budgeting; the sample sizes are not calibrated.
- The scheduler is already running in Arduino `setup()` and IDF `app_main()`: never call `vTaskStartScheduler()` or
  `vTaskEndScheduler()` there. Check task/queue allocation and send failures using the owning firmware's error policy.
- ESP32 SMP critical sections need a shared `portMUX_TYPE` spinlock and matching task/ISR APIs. Disabling interrupts
  on one core is not cross-core exclusion; `volatile` is not synchronization or atomicity. Use queues, atomics or locks.
- IDF owns private `FreeRTOSConfig.h`; use supported project configuration only when explicitly in scope, not these
  generic `config*` examples. Do not add watchdogs, firmware flags, dependencies or framework configuration from this skill.
- Measurements, flashing, live bus/serial/network operations and hardware actuation require separately scoped
  authorization; prose maintenance uses static checks only. No example proves timing, stack headroom or physical safety.

For an ESP32 target, see [ESP-IDF FreeRTOS overview](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/freertos.html)
and [IDF 5.2 API differences](https://docs.espressif.com/projects/esp-idf/en/release-v5.2/esp32/api-reference/system/freertos_idf.html);
select documentation matching the installed SDK rather than treating these links as version requirements.

## Core Workflow

1. **Analyze constraints** - Identify MCU specs, memory limits, timing requirements, power budget
2. **Design architecture** - Preserve existing controller/main-loop ownership; add tasks or driver layers only for demonstrated requirements
3. **Implement the scoped change** - Reuse existing drivers and resource owners; change HAL/peripheral/RTOS integration only when needed
4. **Validate implementation** - Use the existing authorized build/static-analysis commands without adding flags or tools; confirm correct register bit-field usage against datasheet
5. **Optimize resources** - Minimize code size, RAM usage, power consumption
6. **Test and verify** - Run the authorized software checks first; report hardware timing/stack measurements as unverified unless separately authorized and observed.

## 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` where required for hardware registers; synchronize ISR/task data with the SDK primitives, not `volatile` alone
- Implement proper interrupt handling (short ISRs, defer work to tasks)
- Preserve the existing watchdog policy; changes require explicit scope and safety review
- 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
- Introduce unreviewed hardware-specific values outside the owning hardware profile; preserve reviewed build-time GPIO, polarity and safety-envelope configuration
- Ignore power consumption requirements

## Implementation references

Use the owning product's existing controller/driver and the topic references above, not copy templates for another MCU/SDK.
The source adaptation removed ISR, sensor-task and register-blink skeletons that did not establish target-safe
synchronization, bounded queues, consumer ownership or checked failure paths. Do not recreate them merely to satisfy this skill.

- For task/queue/ISR changes, read [RTOS criteria](references/rtos-patterns.md): explicit state ownership, capacity,
  saturation policy, allocation/send results, ISR-safe APIs and exact target stack units.
- For buffers and persistence, use [memory criteria](references/memory-optimization.md) and the existing bounded queue/
  persistence owners. No new low-level allocator, storage layer or task is implied.
- For physical interfaces, read [peripheral criteria](references/microcontroller-programming.md) and the actual selected
  profile/SDK. No unreviewed pin, interrupt, clock, watchdog or power-mode changes from a template.

## Output Templates

For authorized implementation work, report:
1. Changed product/resource ownership and reused components; include initialization/driver code only when the task needs it.
2. Actual software verification, timing/resource impact and omitted checks; estimates are not measured evidence.
3. Remaining compatibility, deployment and hardware limits, with any required separate approvals.

Guidance-only maintenance reports static checks instead; it does not require firmware, driver or RTOS code.

Maintained by [@jeffallan](https://github.com/jeffallan), Principal Consultant at [Synergetic Solutions](https://synergetic.solutions)

[Documentation](https://jeffallan.github.io/claude-skills/skills/specialized/embedded-systems/)