wedsamuel1230/arduino-skills/memory-budgeting

Memory Budgeting

Make memory a measured budget, not a nominal board label. The implementation is embedded C/C++; scripts may parse build or runtime logs when that is the useful deterministic tool.

Intake

Record exact board/module, flash/RAM/EEPROM/PSRAM, bootloader and partition layout, framework, compiler flags, libraries, static buffers, task stacks, filesystem/OTA needs, peak protocol sizes, and available measurement output.

Process

1. Separate static data, code/flash, heap, task stacks, interrupt state,

filesystem, bootloader, and OTA/update slots.

1. Establish a numeric budget and minimum margin for every category. Use board

references rather than copying a family-level number into a project claim.

1. Capture compiler size output and map changes to a feature or dependency.
2. Measure runtime free heap, largest block, stack high-water marks, and reset/

allocation failures under representative load where the framework exposes them.

1. On AVR, keep literals in flash with F() where appropriate, prefer bounded buffers and fixed-size storage, and avoid unbounded dynamic String use. On ESP32/RP2040,

still bound buffers and distinguish heap, stack, flash, and filesystem.

1. Re-run the stress case after each memory-affecting change and record the

tradeoff.

Anti-rationalization

Verification

• Build-size output and runtime memory evidence name the exact target/version.
• Each budget has a margin and a failure response.
• Stress tests cover peak message, sensor, logging, radio, and task load as

applicable.

• Optimization does not remove bounds, safety checks, or recovery behavior.

Shared output contract

Use the shared Arduino skill contract: state assumptions, required tools and versions, implementation steps, tests/evidence by proof stage, known limitations, and recovery/security notes.