dtsong/embedded-architecture

Embedded Architecture

Purpose

Design the firmware architecture for an embedded/IoT device, including RTOS selection, memory layout, power state machine, and task decomposition.

Scope Constraints

Analyzes hardware specifications, firmware requirements, and power budgets to produce architecture recommendations. Does not generate or compile firmware code. Does not interact with hardware debuggers or flash tools.

Inputs

• Target hardware (MCU, memory, peripherals, power source)
• Feature requirements (sensing, communication, actuation, UI)
• Power budget and battery life requirements
• Real-time constraints (latency, update frequency)
• Regulatory requirements (FCC, CE, safety)

Input Sanitization

No user-provided values are used in commands or file paths. All inputs are treated as read-only analysis targets.

Procedure

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

<!-- Observations appended after each use -->