Embedded Architecture

Step 1: Hardware Capability Assessment

Document the hardware constraints:

• MCU: Architecture (ARM Cortex-M, RISC-V, ESP32), clock speed, cores
• Memory: Flash size (code storage), SRAM size (runtime), external storage
• Peripherals: UART, SPI, I2C, ADC, PWM, timers, DMA channels
• Power source: Battery capacity, charging method, voltage regulators
• Radio: BLE, Wi-Fi, cellular, LoRa — power draw per mode

Step 2: Select RTOS or Bare-Metal

Decision framework:

• Bare-metal: < 3 concurrent tasks, no networking stack, simple timing requirements
• FreeRTOS: General-purpose, large ecosystem, good for most IoT applications
• Zephyr: Strong networking stack, Matter/Thread support, Linux Foundation backing
• NuttX: POSIX-compliant, good for complex applications with file systems
• Custom RTOS: Almost never justified — use an existing one

Step 3: Design Task Architecture

Decompose the firmware into tasks/threads:

• Sensor task: Read sensors at defined intervals, buffer data
• Communication task: Manage radio connection, send/receive data
• Application task: Process data, make decisions, trigger actuators
• Power management task: Monitor battery, manage sleep states
• OTA task: Check for updates, manage download and apply

Define priorities, stack sizes, and inter-task communication (queues, events, semaphores).

Step 4: Design Memory Layout

Plan memory allocation:

• Flash partitions: Application, OTA staging, file system, configuration
• RAM allocation: Task stacks, heap, DMA buffers, ring buffers
• Static vs dynamic allocation: Prefer static allocation — malloc on embedded systems is risky
• Stack overflow protection: Guard patterns, MPU regions

Step 5: Design Power State Machine

Define power modes and transitions:

• Active: Full speed, all peripherals on
• Low power: Reduced clock, unnecessary peripherals off
• Sleep: MCU sleeping, RTC running, wake on interrupt
• Deep sleep: Minimum power, RAM retention optional, slow wake-up
• Transitions: What triggers each transition, wake-up latency, power consumption per mode

Step 6: Design Watchdog and Recovery

Plan for failure recovery:

• Watchdog timer: Hardware watchdog with appropriate timeout
• Task health monitoring: Each task must pet a software watchdog
• Crash recovery: Save crash dump to flash, reboot, report crash on next connection
• Fail-safe defaults: If firmware is corrupted, boot into recovery/OTA mode

Progress Checklist

• Step 1: Hardware capability assessment complete
• Step 2: RTOS or bare-metal selection justified
• Step 3: Task architecture decomposed with priorities
• Step 4: Memory layout planned with partitions
• Step 5: Power state machine defined with transitions
• Step 6: Watchdog and recovery strategy designed

Compaction resilience: If context was lost during a long session, re-read the Inputs section to reconstruct what system is being analyzed, check the Progress Checklist for completed steps, then resume from the earliest incomplete step.

Output Format

# Embedded Architecture

## Hardware Summary
| Component | Specification | Constraint |
|-----------|--------------|------------|
| MCU | [Model] | [Clock, cores] |
| Flash | [Size] | [Partitioning plan] |
| SRAM | [Size] | [Allocation plan] |
| Battery | [Capacity] | [Target life: X months] |

## RTOS Selection
**Choice:** [RTOS name]
**Rationale:** [Why this RTOS for this hardware and requirements]

## Task Architecture
| Task | Priority | Stack Size | Rate | Description |
|------|----------|-----------|------|-------------|
| Sensor | High | 2KB | 1Hz | Read and buffer sensor data |
| Comms | Medium | 4KB | Event | BLE/MQTT communication |
| App | Medium | 2KB | On data | Process and decide |
| Power | Low | 1KB | 10s | Monitor and manage power states |

## Memory Layout
### Flash (Xkb)
| Partition | Start | Size | Purpose |
|-----------|-------|------|---------|
| Bootloader | 0x0000 | 32KB | Boot and OTA |
| App A | 0x8000 | 448KB | Active firmware |
| App B | 0x78000 | 448KB | OTA staging |
| NVS | 0xE8000 | 32KB | Configuration |

### RAM (Xkb)
| Region | Size | Purpose |
|--------|------|---------|
| Task stacks | 12KB | All task stacks |
| Heap | 8KB | Dynamic allocation (minimized) |
| DMA buffers | 4KB | Peripheral DMA |

## Power State Machine

[Active] --idle 5s--> [Low Power] --idle 30s--> [Sleep] --idle 5min--> [Deep Sleep] ^ ^ ^ | |---sensor event--------|---BLE event-----------|---RTC alarm-----------|

| State | Power Draw | Wake Latency | Wake Sources |
|-------|-----------|-------------|--------------|
| Active | 50mA | — | — |
| Low Power | 5mA | <1ms | Any interrupt |
| Sleep | 500uA | 5ms | BLE, GPIO, timer |
| Deep Sleep | 10uA | 500ms | RTC alarm |

## Recovery Strategy
- [Watchdog configuration]
- [Crash dump approach]
- [Fail-safe boot mode]

Handoff

• Hand off to protocol-design if wireless protocol selection or stack design questions arise during firmware architecture work.
• Hand off to fleet-management if OTA update strategy or device provisioning concerns surface during embedded design.

Quality Checks

• All task stack sizes are justified (not just "big enough")
• Memory layout accounts for OTA dual-partition scheme
• Power state machine has defined transitions and wake sources
• Watchdog timeout is appropriate for the slowest legitimate operation
• Static allocation is preferred over dynamic — heap usage is justified
• Battery life estimate is calculated from power state duty cycle

Evolution Notes