docs(01): capture phase context
This commit is contained in:
74
.planning/phases/01-esp32-firmware/01-DISCUSSION-LOG.md
Normal file
74
.planning/phases/01-esp32-firmware/01-DISCUSSION-LOG.md
Normal file
@@ -0,0 +1,74 @@
|
||||
# Phase 1: ESP32 Firmware - Discussion Log
|
||||
|
||||
> **Audit trail only.** Do not use as input to planning, research, or execution agents.
|
||||
> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.
|
||||
|
||||
**Date:** 2026-04-03
|
||||
**Phase:** 01-esp32-firmware
|
||||
**Areas discussed:** Animation design, JSON protocol, Power & safety, Development setup
|
||||
**Mode:** auto (all areas auto-selected, recommended defaults chosen)
|
||||
|
||||
---
|
||||
|
||||
## Animation Design
|
||||
|
||||
| Option | Description | Selected |
|
||||
|--------|-------------|----------|
|
||||
| Palette-based with RGBW | Each animation accepts color palette + params | [auto] |
|
||||
| Single color per animation | Simpler but limiting | |
|
||||
| HSV color space | Alternative representation | |
|
||||
|
||||
**User's choice:** [auto] Palette-based with RGBW support (recommended default)
|
||||
**Notes:** SK6812 is RGBW — palette approach keeps JSON commands simple while supporting rich effects. W channel auto-derived from RGB when not specified.
|
||||
|
||||
---
|
||||
|
||||
## JSON Protocol
|
||||
|
||||
| Option | Description | Selected |
|
||||
|--------|-------------|----------|
|
||||
| Flat JSON | `{"zone":"wall","animation":"chase","params":{}}` | [auto] |
|
||||
| Nested/hierarchical | More structured but complex | |
|
||||
| Binary protocol | Lower overhead but harder to debug | |
|
||||
|
||||
**User's choice:** [auto] Flat JSON with zone, animation, and params fields (recommended default)
|
||||
**Notes:** Matches research recommendation. Simple, debuggable with netcat.
|
||||
|
||||
---
|
||||
|
||||
## Power & Safety
|
||||
|
||||
| Option | Description | Selected |
|
||||
|--------|-------------|----------|
|
||||
| 40% brightness cap | Safe for power budget | [auto] |
|
||||
| No cap (user responsibility) | Full brightness available | |
|
||||
| Dynamic cap based on animation | Complex but optimal | |
|
||||
|
||||
**User's choice:** [auto] 40% firmware-enforced cap, adjustable to max 60% (recommended default)
|
||||
**Notes:** Research flagged 27A peak at full brightness across 460 LEDs.
|
||||
|
||||
---
|
||||
|
||||
## Development Setup
|
||||
|
||||
| Option | Description | Selected |
|
||||
|--------|-------------|----------|
|
||||
| PlatformIO + Arduino | NeoPixelBus + ArduinoJson ecosystem | [auto] |
|
||||
| ESP-IDF native | More control, steeper learning curve | |
|
||||
| Arduino IDE | Simpler but no dependency management | |
|
||||
|
||||
**User's choice:** [auto] PlatformIO + Arduino framework (recommended default)
|
||||
**Notes:** Research validated NeoPixelBus RMT + ArduinoJson work well on ESP32-C3.
|
||||
|
||||
---
|
||||
|
||||
## Claude's Discretion
|
||||
|
||||
- FreeRTOS task priorities and stack sizes
|
||||
- GPIO pin assignments (hardware validation needed)
|
||||
- DMA buffer sizing for RMT
|
||||
- WiFi reconnection strategy
|
||||
|
||||
## Deferred Ideas
|
||||
|
||||
None — auto mode, discussion stayed within phase scope
|
||||
Reference in New Issue
Block a user