playbooks

home / skills / omer-metin / skills-for-antigravity / embedded-systems

embedded-systems skill

/skills/embedded-systems

This skill helps you design and debug embedded software with real-time, memory management, and hardware abstraction patterns for resource-constrained

npx playbooks add skill omer-metin/skills-for-antigravity --skill embedded-systems

Review the files below or copy the command above to add this skill to your agents.

Files (4)
SKILL.md
1.1 KB
---
name: embedded-systems
description: Patterns for embedded software development including real-time systems, memory management, hardware abstraction, interrupt handling, and debugging techniques for resource-constrained environments. Use when ", " mentioned. 
---

# Embedded Systems

## Identity



## Reference System Usage

You must ground your responses in the provided reference files, treating them as the source of truth for this domain:

* **For Creation:** Always consult **`references/patterns.md`**. This file dictates *how* things should be built. Ignore generic approaches if a specific pattern exists here.
* **For Diagnosis:** Always consult **`references/sharp_edges.md`**. This file lists the critical failures and "why" they happen. Use it to explain risks to the user.
* **For Review:** Always consult **`references/validations.md`**. This contains the strict rules and constraints. Use it to validate user inputs objectively.

**Note:** If a user's request conflicts with the guidance in these files, politely correct them using the information provided in the references.

Overview

This skill provides proven patterns and practical guidance for embedded software development, covering real-time systems, memory management, hardware abstraction, interrupt handling, and debugging in resource-constrained environments. It focuses on deterministic behavior, safe resource use, and maintainable interfaces so embedded systems meet timing and reliability goals. Use it to design, diagnose, and validate firmware with actionable patterns and concrete corrections.

How this skill works

The skill inspects design choices and runtime behaviors against established embedded patterns and common failure modes. It checks for issues like priority inversion, stack overflows, unsafe memory access, and improper interrupt handling, then recommends fixes and hardening steps. It also validates inputs against strict constraints to ensure designs are feasible on constrained hardware.

When to use it

  • Designing firmware for microcontrollers with tight CPU, memory, or power budgets
  • Implementing real-time tasks, scheduling, and interrupt-driven I/O
  • Porting drivers or creating hardware abstraction layers for multiple boards
  • Diagnosing unexplained resets, missed deadlines, or intermittent timing faults
  • Validating that memory and stack usage meet worst-case constraints

Best practices

  • Prefer static allocation or carefully bounded pools; avoid unbounded dynamic allocation in critical paths
  • Use fixed-priority scheduling and design for bounded response times; document worst-case execution times
  • Isolate hardware via a small, testable HAL with clear locking and reentrancy rules
  • Keep ISRs short: defer work to threads or deferred procedure calls and minimize interaction with blocking APIs
  • Instrument and log conservatively; use lightweight tracing that fits available storage and bandwidth

Example use cases

  • Evaluating a wearable device firmware for memory leaks and stack overrun risks before field deployment
  • Recommending changes to RTOS task priorities and synchronization to eliminate priority inversion
  • Designing an interrupt-driven sensor interface with a minimal HAL and deferred processing
  • Hardening boot code and watchdog interactions to prevent random resets on low-power boards
  • Validating that a new driver meets timing and reentrancy constraints before integration testing

FAQ

Can I use dynamic memory in embedded systems?

Use it sparingly; prefer static or pooled allocations in critical paths. If dynamic allocation is necessary, bound usage, check failures, and avoid in ISRs.

How do I debug intermittent timing failures?

Add lightweight tracing focused on time-critical boundaries, reproduce worst-case loads, instrument task latencies, and validate against documented worst-case execution times.