Make an Uno SRAM Budget Before Adding Features

Tested with Circuitera 1.0.0: the article’s complete C++ sketch compiled for Arduino Uno R3 using avr-gcc-wasm@0.2.0 on 2026-10-31 (UTC). No modeled execution is claimed for this article. No physical board was tested.

The build succeeds, yet a sketch becomes unreliable after a display, another message buffer or a longer menu is added. Flash usage still looks comfortable. The missing resource may be SRAM: on a classic Uno R3, the running program has far less working memory than it has program storage.

Treat memory as a budget before trying random code deletions. The AVR compilation article distinguishes flash from SRAM at build time. Here the practical question is what occupies working memory during execution, where fixed data belongs and what a static size report cannot tell you.

Count bytes, not variable names

The ATmega328P on the Uno R3 has 2 KB of SRAM. Global and static objects occupy part of that space. The stack uses space for active function calls and local state. Dynamically allocated objects use the heap. Interrupt handlers also need runtime resources, and library internals can consume buffers that are not obvious from the sketch's top-level declarations.

A 400-element byte buffer consumes 400 bytes; a 400-element array of 16-bit integers consumes 800. A name such as smallBuffer does not change that arithmetic. Include terminators in text buffers: room for ten visible characters does not automatically include the final zero required by a C string.

Write down the largest simultaneous working set

List fixed arrays, message buffers and state objects. Then follow the deepest plausible call path, including any large local arrays. Ask which objects exist at the same time. Reusing one buffer between strictly sequential operations can save memory, but sharing it across callbacks or interrupts without an ownership policy can introduce corruption instead.

The linker can report statically allocated memory, but it does not execute every future branch or discover the peak depth of your application's stack. A comfortable static number is helpful evidence, not a guarantee. Conversely, a large runtime symptom should not immediately be blamed on the heap before checking ordinary out-of-bounds writes.

Keep constant messages out of copied SRAM

On classic AVR, Arduino's F() macro lets compatible printing functions read a fixed string from program memory. Serial.println(F("Ready")) is useful when a message never changes. It is not a general transformation that makes arbitrary string operations compatible with flash addresses.

The following complete Uno R3 example also stores a small lookup table in program memory. It reads values with the AVR access helper instead of treating the flash address as a normal SRAM array. No external wiring is required; open Serial Monitor at 9600 baud.

#include <avr/pgmspace.h>
const byte levels[] PROGMEM = {0, 16, 64, 128, 192, 255};
byte index = 0;
unsigned long printedAt = 0;

void setup() {
  Serial.begin(9600);
  Serial.println(F("Table stored in AVR program memory"));
}

void loop() {
  const unsigned long now = millis();
  if (now - printedAt < 500UL) return;
  printedAt = now;
  const byte value = pgm_read_byte(&levels[index]);
  Serial.print(F("level="));
  Serial.println(value);
  index = (index + 1) % (sizeof(levels) / sizeof(levels[0]));
}

The table is small so the example is easy to inspect; it is not presented as a benchmark or a dramatic memory saving. The same placement decision becomes more significant for longer fixed tables. All indices remain within the declared table, and the program prints a retrieved value rather than dereferencing program memory through an ordinary byte access.

Const and PROGMEM answer different questions

const describes whether a program is allowed to modify an object through that declaration. On this AVR target, it does not by itself provide the complete storage-and-access contract demonstrated by PROGMEM and pgm_read_byte(). Different architectures and toolchains arrange read-only data differently, so do not copy AVR memory advice unchanged into an ESP32 project.

Use the helper that matches the stored type. Reading one byte from the address of a multi-byte value does not reconstruct the whole value. For structures or strings, use the appropriate documented program-memory functions and be explicit about the destination buffer's size.

Dynamic strings need a lifetime policy

Arduino String objects can be convenient, but repeated allocation and resizing can complicate a tiny memory budget. Different allocation lifetimes may leave holes between live objects. That does not mean every String operation immediately fragments all memory, nor that replacing the word String with char fixes every bug.

Prefer bounded message sizes, known lifetimes and predictable reuse. A fixed char array can still be unsafe if a copy exceeds its bounds or a parser forgets termination. Check lengths before copying input, and reject or explicitly truncate oversized messages rather than writing beyond the buffer and hoping a reset makes the symptom disappear.

A stack failure can imitate a wiring problem

Deep recursion, large local arrays and accidental re-entry can consume stack space unexpectedly. Memory corruption may alter a pin number or a state variable before the board visibly restarts. If the failure appears only after one command sequence, record that sequence and the last known valid state rather than changing the power supply and code simultaneously.

The reset investigation provides a complementary power-versus-firmware workflow. Neither a low static SRAM figure nor a stable supply rules out an indexing bug. Small, repeatable tests help distinguish the possibilities.

Compare builds with one deliberate change

Compile a version with a fixed message, then one using F() where appropriate. Compare the toolchain's reported sections for the same board, core and optimization settings. Do not publish a universal byte-saving figure from one sketch: linker decisions, library use and compiler options affect the result.

Keep source and build details together in Circuitera, and consult the Uno reference for the selected target. This example can be compile-checked with Circuitera's AVR toolchain; no physical peak-memory or endurance measurement is implied. A useful budget leaves deliberate headroom and records which runtime paths still need testing.