Imported from zeroes-ones/Skills (skills/20-hardware/embedded-engineer/SKILL.md). Install upstream with npx skills add zeroes-ones/Skills --skill embedded-engineer. Copyright stays with the author (MIT).

Embedded Engineer

Portability target: Spec-level (runs on Claude Code, Copilot, Gemini CLI, Codex, Cursor). No vendor-specific frontmatter fields.

Design, implement, and validate embedded systems from silicon selection through RTOS architecture, peripheral bring-up, power optimization, and hardware-in-the-loop testing. Hardware failures cost $50K per PCB respin and 6 weeks of schedule. There is no git revert for a burned board.

RESEARCH_PREREQUISITE — Execute Before Any Output

This is a HARD GATE. Do not produce ANY output, code, strategy, design, or recommendation without completing this research.

Before you act, you MUST execute every applicable research step. Research-before-acting is the difference between professional work and amateur guessing:

If you skip any of these research steps, you are not producing quality output — you are guessing with confidence. Guessing wastes time, breaks systems, and destroys trust. The references, ground rules, and decision trees in this skill exist specifically to prevent guessing. Use them.

Compliance: Research must be executed before any substantial output. For each step, document findings inline in your response using [RESEARCHED] marker: [RESEARCHED: RP1 — Domain verified against changelog v2.4. No breaking changes since cutoff.]. Partial research = partial quality. Zero research = zero credibility.

🔄 Iterative Research Loop — Research at EVERY Decision Point, Not Just Entry

The RP1-RP8 cycle above is NOT a one-time gate. It fires continuously at every material decision point throughout the workflow:

Integration into Core Workflow:

Every decision point in a skill's Core Workflow must be marked with:

[RESEARCH LOOP: Re-execute RP1-RP8 before proceeding to next phase]

This ensures the agent pauses to re-verify ALL research dimensions before making the next decision. A skill that only researches at entry and then operates on auto-pilot is a skill that makes decisions on stale context.

Markers for output: At each loop, the agent outputs: [RESEARCHED: Loop N — RP1-RP8 re-verified. Key delta from previous loop: ...]

Why this matters: A decision made in Loop 0 may be catastrophically wrong by Loop 2 because the context changed. Markets move. Requirements shift. Dependencies update. The research loop catches context drift before it becomes output error.

Compliance: Research must be executed before any substantial output AND re-executed at every decision point. For each research loop, document findings inline. Partial research = partial quality. Zero research = zero credibility. Stale research = dangerous confidence.

Route the Request

Auto-Route (No User Input Required)

Evaluate these file-system conditions in order. First match wins — jump immediately.

Intent Route (Ask the User)

If no auto-route matched, use this intent tree:

Ground Rules — Read Before Anything Else

• Admit uncertainty — never fabricate. If you're not certain about an API method, package version, configuration syntax, or command flag, say so explicitly: "I'm not certain this API exists in the latest version. Check the official docs at [URL]." Never invent a function signature or configuration key because it "seems right." Hallucinated code costs hours of debugging.
• Flag your knowledge cutoff. If your training data predates the latest SDK release, framework version, or platform change, state your cutoff date and recommend verifying against current documentation. This is especially critical for rapidly evolving domains: cloud IAM policies, JS framework APIs, mobile OS capabilities, and SaaS pricing — all change quarterly or faster.
• Never guess security configurations. If you're unsure about the correct CSP header value, OAuth flow parameter, or encryption algorithm choice, do NOT provide a "reasonable default." Say: "Security configurations must be verified against current best practices at [official source]. I cannot provide a definitive answer without current documentation."
• Distinguish between what you know and what you infer. Explicitly mark statements as: [VERIFIED] — from official docs, [COMMON-PRACTICE] — widely used but not authoritative, [INFERRED] — your best guess based on patterns, [UNKNOWN] — you're unsure. This helps the user calibrate trust in your output.

The Expert's Mindset

Masters of embedded engineer don't just build — they build the right thing, at the right time, with the right trade-offs. They think in systems, not tasks.

What Masters Know That Others Don't

• The failure modes of every component in their stack — not just the happy path
• When not to use their favorite tool (every tool has a misuse zone)
• That data/model quality decays over time — monitoring is not optional, it's foundational

When to Break Your Own Rules

• Move fast on reversible decisions. Data format? Hard to change. Dashboard layout? Easy. Know the difference.
• Skip the abstraction until the third use case. Two is coincidence, three is a pattern.

Operating at Different Levels

Default level for this skill: L2 Usage: Invoke this skill with your target level, e.g., "as an L3 embedded engineer, design..."

For full level definitions, see skills/00-framework/skill-levels/SKILL.md.

When to Use

• Selecting an MCU/MPU for a new product: ARM Cortex-M0 through M7, RISC-V, ESP32, nRF52/53/54, STM32 families with tradeoff matrix
• Choosing between bare-metal superloop, FreeRTOS, Zephyr, or ThreadX for a specific use case with real-time constraints
• Configuring peripheral interfaces: SPI at >20 MHz with signal integrity, I2C multi-master with bus recovery, UART with DMA, CAN bus termination
• Designing a secure bootloader with A/B partitions, Ed25519-signed images, and OTA update with power-loss resilience
• Implementing power management: sleep modes, DVFS, battery life estimation for BLE/Zigbee/Thread coin-cell devices
• Setting up hardware-in-the-loop (HIL) testing with programmable power supply, relay fault injection, and logic analyzer
• Debugging real-time issues: interrupt latency budgeting (<1 µs target), jitter analysis (<5% period), priority inversion detection
• Designing safety-critical firmware: watchdog strategy, brown-out detection, ECC memory, dual-redundant computation paths
• Pre-compliance testing for FCC Part 15, CE RED, ISED intentional radiator requirements with 3 dB margin

Decision Trees

(QUICK)

MCU/MPU Selection Matrix

                          ┌──────────────────────────────┐
                          │ START: Define requirements    │
                          │ BOM target: $___ per MCU      │
                          │ Flash: ___ KB, RAM: ___ KB    │
                          │ Peripherals: ___ instances    │
                          │ Sleep current: ___ µA target  │
                          │ Volume: ___ K units/year      │
                          └────────────┬─────────────────┘
                                       │
                         ┌─────────────▼─────────────────┐
                         │ Need Linux? (MMU, >64MB RAM,   │
                         │ complex UI, camera pipeline)?  │
                         └────┬────────────────────┬─────┘
                              │ YES                │ NO
                    ┌─────────▼──────┐    ┌────────▼────────────┐
                    │ MPU path        │    │ MCU path             │
                    │ BOM >$15 target  │    │ BOM <$15 target      │
                    └────┬───────────┘    └────┬─────────────────┘
                         │                     │
              ┌──────────▼──────────┐  ┌────────▼────────────────┐
              │ Wireless required?  │  │ Wireless required?       │
              └──┬──────────────┬───┘  └──┬──────────────────┬────┘
                 │ YES          │ NO      │ YES              │ NO
         ┌───────▼──────┐ ┌────▼─────┐ ┌─▼──────────┐ ┌─────▼──────────┐
         │ i.MX RT cross │ │ STM32MP  │ │ BLE/Zigbee  │ │ STM32G0/G4      │
         │ over (Cortex  │ │ (Cortex-A│ │ → nRF5340   │ │ (Cortex-M0/M4,  │
         │ -M7 + M4)     │ │ + M4)    │ │ ($4-6)      │ │ $0.80-3)        │
         │ $8-12          │ │ $15-25   │ │ WiFi/BT     │ │ RISC-V option:  │
         └───────┬───────┘ └──────────┘ │ → ESP32-C3  │ │ → CH32V003      │
         ┌───────▼───────┐              │ ($1.50-3)   │ │ ($0.10 BOM!)    │
         │ AI/ML at edge │              │ Cellular    │ └─────────────────┘
         │ → STM32N6     │              │ → nRF9160   │
         │ (NPU on-die)  │              │ ($15-20)    │
         │ $8-15          │              │ Sub-GHz     │
         └───────────────┘              │ → CC1312    │
                                        │ ($3-5)      │
                                        └─────────────┘

Team selected ESP32-S3 for a battery BLE sensor. Datasheet: 5 µA deep sleep. Real: 240 µA — the built-in USB-UART bridge leaked current even when "disabled." Fix: external UART with dedicated EN pin, or switch to nRF52840 (1.4 µA system-off with RAM retention). Cost: 3-week respin, $8K prototypes scrapped.

RTOS vs Bare-Metal Superloop

                          ┌──────────────────────────────┐
                          │ START: Define firmware        │
                          │ complexity                    │
                          └────────────┬─────────────────┘
                                       │
                         ┌─────────────▼─────────────────┐
                         │ >3 concurrent tasks with       │
                         │ different timing budgets?      │
                         └────┬────────────────────┬─────┘
                              │ YES                │ NO
                    ┌─────────▼──────┐    ┌────────▼──────────┐
                    │ RTOS required   │    │ Flash <64KB OR     │
                    │                 │    │ RAM <8KB?         │
                    └────┬───────────┘    └───┬──────────┬─────┘
                         │                    │ YES      │ NO
              ┌──────────▼──────────┐   ┌─────▼───┐ ┌───▼─────────┐
              │ Hard real-time       │   │ Bare-metal│ │ Bare-metal  │
              │ (<10µs jitter)?      │   │ superloop │ │ + simple     │
              └──┬──────────────┬────┘   │ with ISRs │ │ scheduler    │
                 │ YES          │ NO     └───────────┘ │ (state mach) │
         ┌───────▼──────┐ ┌─────▼────────┐              └─────────────┘
         │ Zephyr or     │ │ FreeRTOS      │
         │ ThreadX       │ │ (widest       │
         │ (preemptive,  │ │ ecosystem,    │
         │ tickless,     │ │ 100K+ devices │
         │ safety cert)  │ │ shipped)      │
         └───────────────┘ └───────────────┘

Bare-metal: single-function device, flash <64KB, RAM <8KB, power <1 µA sleep, cert cost matters. FreeRTOS: 3-8 tasks, need TCP/IP, moderate real-time (1-10ms deadlines), team already knows it. Zephyr: hard real-time (<10µs jitter), BLE/Thread/Zigbee certified stacks, vendor-independent HAL, safety cert (ISO 26262, IEC 61508).

Power Management Strategy

                          ┌──────────────────────────────┐
                          │ START: Battery target life    │
                          │ ___ months/years              │
                          │ Battery: ___ mAh              │
                          │ Duty cycle: ___ % active      │
                          └────────────┬─────────────────┘
                                       │
                         ┌─────────────▼─────────────────┐
                         │ Coin cell (CR2032, 225mAh)     │
                         │ target >1 year?                │
                         └────┬────────────────────┬─────┘
                              │ YES                │ NO
                    ┌─────────▼──────┐    ┌────────▼──────────┐
                    │ Avg current     │    │ Li-Po/Li-Ion       │
                    │ MUST be <25µA   │    │ >500mAh?           │
                    │ (225mAh/8760h)  │    └───┬──────────┬─────┘
                    └────┬───────────┘        │ YES      │ NO
                         │             ┌──────▼────┐ ┌──▼──────────┐
              ┌──────────▼──────────┐  │ DVFS +     │ │ Simple       │
              │ Strategy:            │  │ tickless   │ │ sleep/wake   │
              │ • Tickless RTOS      │  │ idle       │ │ (WFI/WFE)    │
              │ • BLE conn interval  │  │ • Low freq │ │ Run @ full   │
              │   max (1s+)         │  │   for bg   │ │ speed always │
              │ • No UART RX pull-up │  │ • Boost for│ └──────────────┘
              │ • GPIO analog disc.  │  │   radio TX │
              │   in sleep           │  │ • Ship mode│
              │ • NCP for radio      │  │   <1µA     │
              └──────────────────────┘  └────────────┘

Door sensor: 3.7 µA on the bench, 30% field failures in 3 months. Root cause: magnetic reed switch leaked 10 nA at >80% humidity, biasing a floating CMOS input into the linear region drawing 200 µA. Fix: external 10M pull-down + firmware recalibrated debounce. Lesson: test power in an environmental chamber at -20°C, 25°C, 60°C — not just room temp.

Core Workflow

(STANDARD)

Phase 1 (~4 hours): Silicon Selection & Architecture

1. Do: Fill the MCU/MPU selection matrix. List every peripheral: SPI × N, I2C × N, UART × N, CAN × N, USB Y/N, ADC channels + sample rate, GPIO count. Pin conflicts NOW prevent layout respins LATER.
2. Do: Build the power budget: V_in × I_active × duty_cycle + V_in × I_sleep × (1-duty_cycle) = avg current. Add 30% margin for peripheral leakage you will discover. Compare to battery mAh ÷ avg current = hours.
3. Do: Map memory: bootloader (16-64KB) + app A + app B + filesystem + config. RAM: stacks (per task) + heap + DMA buffers + BLE/TCP stacks. If total >80% chip capacity, size up or cut features.
4. Verify: Order the dev board. Run critical peripheral test within 48 hours — SPI at target speed, ADC noise floor, BLE range. Do not finalize schematic until dev board validation passes.
5. Recover: Dev board fails → restart selection before PCB spins. Changing silicon after layout costs 4-6 weeks and $15K+.

Complete when: MCU/MPU selection matrix with all peripherals mapped and pin conflicts resolved is complete; power budget with 30% margin is calculated against battery capacity; memory map (flash partitions + RAM allocation) is documented with <80% capacity usage; dev board is ordered and critical peripheral test passes within 48 hours.

Phase 2 (~6 hours): RTOS Configuration & Task Design

1. Do: Choose RTOS per decision tree. Configure tick rate (1000 Hz precision, 100 Hz power-saving). Set configTOTAL_HEAP_SIZE to measured max + 20% headroom.
2. Do: Assign task priorities: hard real-time → high (motor, radio); UI/logging → low. Document worst-case execution time (WCET) per task.
3. Do: Stack sizing: measure with uxTaskGetStackHighWaterMark() after 24-hour stress test. Never guess — stack overflow corrupts memory silently and looks like a logic bug.
4. Verify: Priority inversion stress test. Enable priority inheritance on mutexes. If any task starves >2× its deadline, refactor.
5. Recover: Stack overflow → increase that task's stack by 50%, rerun. Heap exhaustion → audit every malloc() — allocate once at init, never in event loops.

Complete when: RTOS is selected per decision tree with tick rate configured; task priority assignment with WCET documented per task is complete; stack sizing is measured via high water mark after 24-hour stress test; priority inversion stress test passes with inheritance enabled on all mutexes.

Phase 3 (~8 hours): Bootloader & OTA Design

1. Do: Partition flash: bootloader (validated at power-on, never self-updates), app A (active), app B (staging), persistent config. Minimum: 32KB bootloader + app A + app B.
2. Do: Ed25519 or ECDSA P-256 image signature verification. Bootloader verifies before jump. Unsigned image = boot rejected. This is how botnets recruit IoT devices.
3. Do: A/B swap: write new image → inactive partition → verify signature → set boot flag → reboot → bootloader validates → N failed boots → revert. Power-loss tested at every 10% of download.
4. Verify: Corrupted image → bootloader detects, rejects. Power loss during OTA → device recovers to previous working image.
5. Recover: Bootloader corrupted → device bricked. Ensure hardware recovery: hold BOOT0 at power-on for ROM bootloader (STM32), or serial recovery (nRF, ESP32).

Complete when: Flash partition layout (bootloader + app A + app B + config) with minimum sizes is defined; image signature verification (Ed25519 or ECDSA P-256) is implemented in bootloader; A/B swap with power-loss recovery tested at every 10% of download is verified; hardware recovery mechanism (BOOT0/serial) is documented and tested.

Phase 4 (~5 hours): Hardware-in-the-Loop Testing

1. Do: HIL rig: Raspberry Pi/PC running pytest → programmable PSU → relay matrix (fault injection) → logic analyzer. Physically stimulates sensors (I2C DACs, GPIO toggles), measures actuator outputs.
2. Do: Test cases: (a) power glitch to brown-out threshold → clean reset, (b) I2C SDA stuck low → timeout + recovery, (c) sensor disconnect → firmware detects, doesn't report NaN.
3. Do: 24-hour soak with randomized fault injection. Log every reset cause (power-on, watchdog, brown-out, software). Verify correct reason recorded each time.
4. Verify: Zero manual intervention. A human should never need to power-cycle a device under test.
5. Recover: Intermittent test failures = race condition or timing bug, not "test flake." Do not increase timeouts — find the root cause.

Complete when: HIL rig with programmable PSU, relay matrix, and logic analyzer is operational; fault injection test cases (brown-out, I2C stuck, sensor disconnect) all pass; 24-hour soak with randomized fault injection completes with zero manual intervention and correct reset cause logging.

Phase 5 (~3 hours): Real-Time Validation & Interrupt Budgeting

1. Do: Measure interrupt latency: GPIO edge to ISR entry via logic analyzer on debug pin. Target: <1 µs for critical interrupts on Cortex-M4 at 80 MHz. >2 µs → investigate nested interrupts or disabled-IRQ regions.
2. Do: ISR execution time <10 µs. ISR does: capture timestamp, set flag, unblock task. Move heavy work to a high-priority task.
3. Do: Jitter analysis: 1000 consecutive periods of a 1 kHz timer. P95 jitter <5% of period. Higher → check interrupt masking or DMA bus contention.
4. Verify: Worst-case latency with all peripherals active (SPI DMA + BLE radio + ADC sampling). Must still meet deadlines.
5. Recover: Jitter exceeds budget → reduce longest interrupt-disabled section. __disable_irq() / __enable_irq() pairs <5 µs max. Use scope guards.

Complete when: Interrupt latency measurement (<1 µs target on Cortex-M4 at 80 MHz) is verified via logic analyzer; ISR execution time (<10 µs) is confirmed for all ISRs with heavy work deferred to tasks; jitter analysis (1000 periods, P95 <5% of period) passes; worst-case latency with all peripherals active meets all deadlines. Complete when: All deliverables verified against acceptance criteria, stakeholder sign-off obtained, and documentation updated with final decisions and rationale. Complete when: Risk register reviewed with mitigation owners assigned, residual risk levels within acceptable thresholds, and escalation paths documented for all identified risks. Complete when: Quality gates passed: peer review completed, automated checks green, test coverage meets minimum thresholds, and no blocking issues remain open.

Error Recovery

(STANDARD)

If a command or approach fails, follow this escalation path before giving up:

Hard failure boundary: If 3 different approaches all fail, STOP. Do not iterate infinitely. Log what was tried, capture the error output, and report the blocking issue with full context. Move to the next independent task rather than blocking all progress on one failure.

Error Decoder — War Stories from the Trenches

(STANDARD)

When this domain goes wrong, it goes wrong in predictable ways. Here are the most common failure signatures, their root causes, and the fix you'll reach for after you've been burned once.

Best Practices

1. Design for memory-constrained environments from the start. Define a memory budget (ROM, RAM, stack per task) before writing any application logic. Use -fstack-usage and map files to verify actual usage against budget. Embedded systems don't have swap — exceeding RAM silently corrupts adjacent data. Budget ROM/RAM with 20% headroom for future features.

2. Assign RTOS task priorities based on real-time deadlines, not perceived importance. A motor control loop with a 100µs deadline gets priority 0 (highest). A logging task with a 100ms deadline gets priority 5. A UI update task with no deadline gets priority 10 (lowest). Rate-monotonic scheduling: shorter period = higher priority. Verify with tracealyzer or a logic analyzer on GPIO toggles at task entry/exit.

3. Keep ISRs short — under 10µs is ideal, under 100µs is acceptable. ISRs should: read a register, set a flag, push to a ring buffer, and exit. Never: allocate memory, take a mutex, call printf, or busy-wait in an ISR. If processing takes longer, defer to a high-priority task via a semaphore or task notification. Profile ISR duration with an oscilloscope on a GPIO — guessing is not enough.

4. Build a hardware abstraction layer (HAL) to decouple application logic from silicon. Define interfaces for GPIO, I2C, SPI, UART, ADC, PWM, and timers. The application calls hal_i2c_write(addr, data, len), never I2C1->DR = data directly. When the SoC changes (and it will — silicon revisions, supply chain pivots, cost reductions), only the HAL implementation changes, not the application. A 50-file firmware with a HAL ports in 1 week; without one, 6 weeks.

5. Implement power management as a first-class architecture concern, not an afterthought. Define sleep modes (idle, sleep, deep sleep, standby) and wake sources (GPIO, RTC, watchdog, communication peripheral). Measure current in each mode with a power profiler. Enter the deepest possible sleep mode whenever the system is idle. A device that draws 10mA instead of 10µA in sleep kills battery life — 10mA idle on a 2000mAh battery = 8 days; 10µA = 22 years.

6. Design peripheral drivers with error recovery baked in, not bolted on. I2C transactions can be NACKed or bus-stuck. SPI can have mode mismatches. UART can receive framing errors. Every driver transaction must: (a) have a timeout, (b) check error flags after every operation, (c) implement a reset/reinitialize path, (d) report errors to the application layer. A driver that hangs forever on a bus fault turns a recoverable transient error into a system-wide lockup.

7. Architect the bootloader with a fail-safe update path. Implement dual-bank flash (A/B partitioning) with a bootloader that: verifies application image CRC before boot, tracks boot attempts (increment on boot, clear on successful run), rolls back to previous image after N consecutive failures (typically 3), and has a golden/recovery image that can be entered via a hardware pin or button combination. A bootloader that erases the old image before verifying the new one = unrecoverable brick on power loss.

8. Use independent watchdog timer (IWDG) with a multi-level supervision strategy. Configure the hardware watchdog with a timeout appropriate for your main loop period (typically 100ms-2s). Kick it only from the main loop — never from an ISR. For RTOS systems, add a software watchdog task that monitors all other tasks via heartbeat counters. If any task misses its deadline, the watchdog task deliberately stops kicking the hardware watchdog, triggering a full system reset. Test by deliberately hanging each task.

9. Perform stack depth analysis before releasing firmware. Use GCC's -fstack-usage flag to generate per-function stack usage data. Sum the worst-case call chain (ISR → callback → driver → application). Add interrupt nesting overhead (if nested interrupts are enabled, sum the worst-case ISR chain too). Verify against allocated task stack sizes with 50% margin. A stack overflow without MMU protection silently corrupts RTOS structures or adjacent task stacks — symptoms appear as random crashes days or weeks later.

10. Enable brown-out detection (BOD) before any flash write or erase operation. Flash programming requires a minimum voltage (typically 2.7V for 3.3V MCUs). During a brown-out (voltage sag from motor startup, battery depletion, or power supply transient), the MCU may execute corrupted instructions and write garbage to flash. Configure BOD to trigger a system reset at a threshold above the flash programming minimum voltage. Test with a programmable power supply: ramp voltage down during flash writes and verify BOD triggers before corruption occurs.

Error Decoder

Cross-Skill Coordination

Coordinate With

Communication Triggers

Escalation Path

Device bricks >0.1% rate? → Halt OTA → Hardware Architect → VP Engineering
Silicon errata, no workaround? → Hardware Architect → Reselection → +8 weeks
EMC failure >6dB over limit? → Hardware Architect → PCB respin → $15K-50K + 4-6 weeks
Bootloader security vuln, unpatchable? → Security Engineer → Emergency OTA / physical recall

Cross-Skill Chain

# Architecture → Embedded bring-up → Firmware → QA
/hardware-architect && /embedded-engineer && /firmware-developer && /qa-engineer

Decision Gates & Handoff Artifacts:

• Silicon selection gate: MCU/MPU selection must pass: (1) peripheral count check (all required interfaces available simultaneously), (2) power budget fit (<80% of PMIC capacity), (3) flash/RAM headroom >30%, (4) lifecycle guarantee (not NRND/EOL). Artifact: MCU selection matrix with scored criteria.
• Pin mux review gate: Every pin assignment verified against alternate functions before schematic freeze. Pin conflict = PCB respin. Artifact: Pin assignment spreadsheet signed off by hardware-architect and firmware-developer.
• RTOS task audit gate: All tasks must show >20% stack headroom after 24-hour stress test. Zero priority inversions. Artifact: RTOS task analysis report with stack high-water marks and CPU utilization.
• Power profile gate: Sleep current within 30% of calculated budget; active current within 10% of datasheet. Exceeding = leakage or misconfiguration. Artifact: Power profiler trace with annotated power states.
• Bootloader security gate: Bootloader must: (1) validate signatures before boot, (2) reject unsigned/corrupt/wrong-key images, (3) revert to previous image after 3 failed boots. All verified on hardware. Artifact: Bootloader test report with pass/fail for each security scenario.
• OTA safety gate: OTA must survive power loss at any point during download. Device always boots valid image (old or new, never corrupted). Brick rate >0.1% = halt rollout. Artifact: OTA robustness test report with 100 random power-loss test results.
• Handoff to firmware-developer: Memory map (linker script input), peripheral init sequence, ISR priority assignments, DMA channel allocation, HAL API specification. Artifact: BSP handoff package with all register-level documentation.
• Handoff to qa-engineer: Test point access (UART header, SWD pins), factory test mode entry sequence, calibration register map. Artifact: HIL test specification with pass/fail thresholds.
• Handoff to performance-engineer: Power budget, clock tree configuration, peripheral utilization report. Artifact: Power and performance baseline report.

Proactive Triggers

State Log

This skill maintains a decision ledger to prevent context drift and ensure recall across sessions. Every major architectural choice, constraint decision, and trade-off must be recorded so that subsequent agents (or future sessions) can recover context without replaying the entire conversation.

What Good Looks Like

• Dev board boots and passes all peripheral self-tests (SPI loopback, I2C scan, ADC known-voltage, GPIO toggle) within 4 hours of unboxing.
• RTOS task set runs 24h under stress: zero stack overflows, zero priority inversions, uxTaskGetStackHighWaterMark() shows >20% headroom per task.
• Power profiler trace: sleep current within 30% of calculated budget; active current matches datasheet within 10%.
• Bootloader validates + boots signed images; rejects unsigned/corrupt/wrong-key images; reverts after 3 failed boots — all verified on hardware.
• HIL rig runs 1000 randomized fault-injection cycles with zero unexpected resets, zero manual intervention.
• OTA survives power loss at ANY point; device always boots a valid image (old or new, never corrupted).

Deliberate Practice

graph LR
    A[Build] --> B[Measure<br/>failure modes] --> C[Study<br/>post-mortems] --> D[Re-build<br/>with constraints] --> A

The One Highest-Leverage Activity: Every quarter, take a system you built 6+ months ago and redesign it from scratch with what you know now. Write down what changed and why.

Anti-Hallucination

*Truncated - read the full file at https://github.com/zeroes-ones/Skills/blob/a20a35e2eef7136945ce72e79af2b83a3193b59f/skills/20-hardware/embedded-engineer/SKILL.md.