mcpField
M
memory-budgeting

memory-budgeting

github.com/wedsamuel1230Development2854 installsUpdated 2w ago
Repository

About memory-budgeting

memory-budgeting is a skill for embedded C/C++ work that treats memory as a measured budget rather than a board specification. It guides developers through accounting, build-size inspection, runtime measurements, and stress testing.

Key features

  1. 01Separates memory usage categories
  2. 02Sets budgets and safety margins
  3. 03Inspects compiler size output
  4. 04Measures runtime heap and stack
  5. 05Checks memory under representative load

Use cases

  1. 01Estimating memory before adding a feature
  2. 02Investigating build-size changes
  3. 03Checking heap and stack during runtime
  4. 04Validating memory use under peak load

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/wedsamuel1230/embedded-engineering-skills --skill memory-budgeting

After installing, type/memory-budgetingin Claude Code to confirm it loaded.

Details

From the project README

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.
  2. Establish a numeric budget and minimum margin for every category. Use board references rather than copying a family-level number into a project claim.
  3. Capture compiler size output and map changes to a feature or dependency.
  4. Measure runtime free heap, largest block, stack high-water marks, and reset/ allocation failures under representative load where the framework exposes them.
  5. 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.
  6. Re-run the stress case after each memory-affecting change and record the tradeoff.

Anti-rationalization

ShortcutResponse
"The datasheet says 520 KB, so memory is fine."Separate usable heap, stacks, reserved regions, and radio/RTOS use.
"It compiled."Inspect size output and exercise runtime allocation paths.
"Make the buffer bigger."Bound the protocol and prove the required maximum.
"Use String everywhere."Check fragmentation and lifetime; use bounded alternatives where needed.
"OTA only needs the application image."Budget both update slots, bootloader, metadata, and rollback image.

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.

Comments

Markdown supported