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-architecture3department: "sentinel"4description: "Firmware design patterns, RTOS selection, memory and power management"5version: 16triggers:7 - "firmware"8 - "RTOS"9 - "microcontroller"10 - "bare-metal"11 - "power"12 - "battery"13 - "sleep mode"14 - "memory"15 - "flash"16 - "embedded"17---1819# Embedded Architecture2021## Purpose2223Design the firmware architecture for an embedded/IoT device, including RTOS selection, memory layout, power state machine, and task decomposition.2425## Inputs2627- Target hardware (MCU, memory, peripherals, power source)28- Feature requirements (sensing, communication, actuation, UI)29- Power budget and battery life requirements30- Real-time constraints (latency, update frequency)31- Regulatory requirements (FCC, CE, safety)3233## Process3435### Step 1: Hardware Capability Assessment3637Document the hardware constraints:38- **MCU:** Architecture (ARM Cortex-M, RISC-V, ESP32), clock speed, cores39- **Memory:** Flash size (code storage), SRAM size (runtime), external storage40- **Peripherals:** UART, SPI, I2C, ADC, PWM, timers, DMA channels41- **Power source:** Battery capacity, charging method, voltage regulators42- **Radio:** BLE, Wi-Fi, cellular, LoRa — power draw per mode4344### Step 2: Select RTOS or Bare-Metal4546Decision framework:47- **Bare-metal:** < 3 concurrent tasks, no networking stack, simple timing requirements48- **FreeRTOS:** General-purpose, large ecosystem, good for most IoT applications49- **Zephyr:** Strong networking stack, Matter/Thread support, Linux Foundation backing50- **NuttX:** POSIX-compliant, good for complex applications with file systems51- **Custom RTOS:** Almost never justified — use an existing one5253### Step 3: Design Task Architecture5455Decompose the firmware into tasks/threads:56- **Sensor task:** Read sensors at defined intervals, buffer data57- **Communication task:** Manage radio connection, send/receive data58- **Application task:** Process data, make decisions, trigger actuators59- **Power management task:** Monitor battery, manage sleep states60- **OTA task:** Check for updates, manage download and apply6162Define priorities, stack sizes, and inter-task communication (queues, events, semaphores).6364### Step 4: Design Memory Layout6566Plan memory allocation:67- **Flash partitions:** Application, OTA staging, file system, configuration68- **RAM allocation:** Task stacks, heap, DMA buffers, ring buffers69- **Static vs dynamic allocation:** Prefer static allocation — malloc on embedded systems is risky70- **Stack overflow protection:** Guard patterns, MPU regions7172### Step 5: Design Power State Machine7374Define power modes and transitions:75- **Active:** Full speed, all peripherals on76- **Low power:** Reduced clock, unnecessary peripherals off77- **Sleep:** MCU sleeping, RTC running, wake on interrupt78- **Deep sleep:** Minimum power, RAM retention optional, slow wake-up79- **Transitions:** What triggers each transition, wake-up latency, power consumption per mode8081### Step 6: Design Watchdog and Recovery8283Plan for failure recovery:84- **Watchdog timer:** Hardware watchdog with appropriate timeout85- **Task health monitoring:** Each task must pet a software watchdog86- **Crash recovery:** Save crash dump to flash, reboot, report crash on next connection87- **Fail-safe defaults:** If firmware is corrupted, boot into recovery/OTA mode8889## Output Format9091```markdown92# Embedded Architecture9394## Hardware Summary95| Component | Specification | Constraint |96|-----------|--------------|------------|97| MCU | [Model] | [Clock, cores] |98| Flash | [Size] | [Partitioning plan] |99| SRAM | [Size] | [Allocation plan] |100| Battery | [Capacity] | [Target life: X months] |101102## RTOS Selection103**Choice:** [RTOS name]104**Rationale:** [Why this RTOS for this hardware and requirements]105106## Task Architecture107| Task | Priority | Stack Size | Rate | Description |108|------|----------|-----------|------|-------------|109| Sensor | High | 2KB | 1Hz | Read and buffer sensor data |110| Comms | Medium | 4KB | Event | BLE/MQTT communication |111| App | Medium | 2KB | On data | Process and decide |112| Power | Low | 1KB | 10s | Monitor and manage power states |113114## Memory Layout115### Flash (Xkb)116| Partition | Start | Size | Purpose |117|-----------|-------|------|---------|118| Bootloader | 0x0000 | 32KB | Boot and OTA |119| App A | 0x8000 | 448KB | Active firmware |120| App B | 0x78000 | 448KB | OTA staging |121| NVS | 0xE8000 | 32KB | Configuration |122123### RAM (Xkb)124| Region | Size | Purpose |125|--------|------|---------|126| Task stacks | 12KB | All task stacks |127| Heap | 8KB | Dynamic allocation (minimized) |128| DMA buffers | 4KB | Peripheral DMA |129130## Power State Machine131```132[Active] --idle 5s--> [Low Power] --idle 30s--> [Sleep] --idle 5min--> [Deep Sleep]133 ^ ^ ^ |134 |---sensor event--------|---BLE event-----------|---RTC alarm-----------|135```136137| State | Power Draw | Wake Latency | Wake Sources |138|-------|-----------|-------------|--------------|139| Active | 50mA | — | — |140| Low Power | 5mA | <1ms | Any interrupt |141| Sleep | 500μA | 5ms | BLE, GPIO, timer |142| Deep Sleep | 10μA | 500ms | RTC alarm |143144## Recovery Strategy145- [Watchdog configuration]146- [Crash dump approach]147- [Fail-safe boot mode]148```149150## Quality Checks151152- [ ] All task stack sizes are justified (not just "big enough")153- [ ] Memory layout accounts for OTA dual-partition scheme154- [ ] Power state machine has defined transitions and wake sources155- [ ] Watchdog timeout is appropriate for the slowest legitimate operation156- [ ] Static allocation is preferred over dynamic — heap usage is justified157- [ ] Battery life estimate is calculated from power state duty cycle158159## Evolution Notes160<!-- Observations appended after each use -->