Embedded Architecture
Purpose
Design the firmware architecture for an embedded/IoT device, including RTOS selection, memory layout, power state machine, and task decomposition.
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)
Process
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
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 | 500μA | 5ms | BLE, GPIO, timer |
| Deep Sleep | 10μA | 500ms | RTC alarm |
## Recovery Strategy
- [Watchdog configuration]
- [Crash dump approach]
- [Fail-safe boot mode]
Quality Checks
Evolution Notes
1---2name: embedded-architecture3description: Firmware design patterns, RTOS selection, memory and power management4---56# Embedded Architecture78## Purpose910Design the firmware architecture for an embedded/IoT device, including RTOS selection, memory layout, power state machine, and task decomposition.1112## Inputs1314- Target hardware (MCU, memory, peripherals, power source)15- Feature requirements (sensing, communication, actuation, UI)16- Power budget and battery life requirements17- Real-time constraints (latency, update frequency)18- Regulatory requirements (FCC, CE, safety)1920## Process2122### Step 1: Hardware Capability Assessment2324Document the hardware constraints:25- **MCU:** Architecture (ARM Cortex-M, RISC-V, ESP32), clock speed, cores26- **Memory:** Flash size (code storage), SRAM size (runtime), external storage27- **Peripherals:** UART, SPI, I2C, ADC, PWM, timers, DMA channels28- **Power source:** Battery capacity, charging method, voltage regulators29- **Radio:** BLE, Wi-Fi, cellular, LoRa — power draw per mode3031### Step 2: Select RTOS or Bare-Metal3233Decision framework:34- **Bare-metal:** < 3 concurrent tasks, no networking stack, simple timing requirements35- **FreeRTOS:** General-purpose, large ecosystem, good for most IoT applications36- **Zephyr:** Strong networking stack, Matter/Thread support, Linux Foundation backing37- **NuttX:** POSIX-compliant, good for complex applications with file systems38- **Custom RTOS:** Almost never justified — use an existing one3940### Step 3: Design Task Architecture4142Decompose the firmware into tasks/threads:43- **Sensor task:** Read sensors at defined intervals, buffer data44- **Communication task:** Manage radio connection, send/receive data45- **Application task:** Process data, make decisions, trigger actuators46- **Power management task:** Monitor battery, manage sleep states47- **OTA task:** Check for updates, manage download and apply4849Define priorities, stack sizes, and inter-task communication (queues, events, semaphores).5051### Step 4: Design Memory Layout5253Plan memory allocation:54- **Flash partitions:** Application, OTA staging, file system, configuration55- **RAM allocation:** Task stacks, heap, DMA buffers, ring buffers56- **Static vs dynamic allocation:** Prefer static allocation — malloc on embedded systems is risky57- **Stack overflow protection:** Guard patterns, MPU regions5859### Step 5: Design Power State Machine6061Define power modes and transitions:62- **Active:** Full speed, all peripherals on63- **Low power:** Reduced clock, unnecessary peripherals off64- **Sleep:** MCU sleeping, RTC running, wake on interrupt65- **Deep sleep:** Minimum power, RAM retention optional, slow wake-up66- **Transitions:** What triggers each transition, wake-up latency, power consumption per mode6768### Step 6: Design Watchdog and Recovery6970Plan for failure recovery:71- **Watchdog timer:** Hardware watchdog with appropriate timeout72- **Task health monitoring:** Each task must pet a software watchdog73- **Crash recovery:** Save crash dump to flash, reboot, report crash on next connection74- **Fail-safe defaults:** If firmware is corrupted, boot into recovery/OTA mode7576## Output Format7778```markdown79# Embedded Architecture8081## Hardware Summary82| Component | Specification | Constraint |83|-----------|--------------|------------|84| MCU | [Model] | [Clock, cores] |85| Flash | [Size] | [Partitioning plan] |86| SRAM | [Size] | [Allocation plan] |87| Battery | [Capacity] | [Target life: X months] |8889## RTOS Selection90**Choice:** [RTOS name]91**Rationale:** [Why this RTOS for this hardware and requirements]9293## Task Architecture94| Task | Priority | Stack Size | Rate | Description |95|------|----------|-----------|------|-------------|96| Sensor | High | 2KB | 1Hz | Read and buffer sensor data |97| Comms | Medium | 4KB | Event | BLE/MQTT communication |98| App | Medium | 2KB | On data | Process and decide |99| Power | Low | 1KB | 10s | Monitor and manage power states |100101## Memory Layout102### Flash (Xkb)103| Partition | Start | Size | Purpose |104|-----------|-------|------|---------|105| Bootloader | 0x0000 | 32KB | Boot and OTA |106| App A | 0x8000 | 448KB | Active firmware |107| App B | 0x78000 | 448KB | OTA staging |108| NVS | 0xE8000 | 32KB | Configuration |109110### RAM (Xkb)111| Region | Size | Purpose |112|--------|------|---------|113| Task stacks | 12KB | All task stacks |114| Heap | 8KB | Dynamic allocation (minimized) |115| DMA buffers | 4KB | Peripheral DMA |116117## Power State Machine118```119[Active] --idle 5s--> [Low Power] --idle 30s--> [Sleep] --idle 5min--> [Deep Sleep]120 ^ ^ ^ |121 |---sensor event--------|---BLE event-----------|---RTC alarm-----------|122```123124| State | Power Draw | Wake Latency | Wake Sources |125|-------|-----------|-------------|--------------|126| Active | 50mA | — | — |127| Low Power | 5mA | <1ms | Any interrupt |128| Sleep | 500μA | 5ms | BLE, GPIO, timer |129| Deep Sleep | 10μA | 500ms | RTC alarm |130131## Recovery Strategy132- [Watchdog configuration]133- [Crash dump approach]134- [Fail-safe boot mode]135```136137## Quality Checks138139- [ ] All task stack sizes are justified (not just "big enough")140- [ ] Memory layout accounts for OTA dual-partition scheme141- [ ] Power state machine has defined transitions and wake sources142- [ ] Watchdog timeout is appropriate for the slowest legitimate operation143- [ ] Static allocation is preferred over dynamic — heap usage is justified144- [ ] Battery life estimate is calculated from power state duty cycle145146## Evolution Notes147<!-- Observations appended after each use -->