F() macro storage behavior in Arduino AVR core 2.0.x for Print function arguments

Answer the question first

In AVR core 2.0.x F() is still required whenever you want a string literal to stay in flash and not be copied into SRAM when you call Print::print(). The core has not changed the way literals are placed or the overload resolution logic compared to 1.8.x.

Why the macro is still needed

• Every string literal in C/C++ is stored in program memory. On AVR the compiler emits the literal in the .progmem section.
• When you pass a literal directly to print(), the compiler chooses the overload that expects a const char*. That overload reads the bytes through a RAM pointer, so the literal is copied into .data (SRAM) at startup.
• F() expands to (const __FlashStringHelper*), forcing the compiler to select the overload that takes a const __FlashStringHelper*. That overload uses pgm_read_byte() to fetch bytes from flash, keeping the literal in program memory.

How to verify the behaviour

1. Compile‑time check: Build the sketch and run avr-size -C -m mcu=atmega328p output.hex. The .data section will contain the size of the literal when not wrapped in F(), but will be zero when it is wrapped.
2. Runtime check: Add a small sketch that prints a known large literal with and without F() and prints the free SRAM before and after print(). The SRAM consumption will drop from the literal size to almost nothing when F() is used.
3. Listing check: Enable -S to generate assembly. When F() is used you will see pgm_read_byte calls; without it you will see normal memory loads.

When you must use F()

• Any argument to Print::print() or Serial.print() that you want to stay in flash (e.g., long messages, constant tables).
• When the literal is larger than the available SRAM or you want to keep SRAM free for dynamic data.

When you can skip it

• Short literals that comfortably fit in SRAM and where you do not care about the extra RAM usage.
• When you need a mutable char* or a pointer to RAM for other APIs (e.g., strcpy(), sprintf(), or user libraries that expect a RAM buffer). Passing an F() string to these APIs will either fail to compile or read garbage.

Did core 2.0.x change anything?

No documented change in literal placement or overload resolution was introduced between 1.8.x and 2.0.x. The behaviour is identical; the macro remains an explicit opt‑in. Release notes for core 2.0.x focus on toolchain updates and new libraries, not on string handling.

What to do if you’re unsure

Compile the sketch with the board’s default core (e.g., avr-gcc 7.x for 2.0.x) and inspect the output as described above. If the literal ends up in .data when you did not use F(), you need to wrap it. If it does not, you can safely omit F() for that literal.

Missing diagnostic detail

To give a board‑specific recommendation, could you tell me which AVR board you are targeting (e.g., Uno, Nano, Pro Mini) and the exact core version you have installed? That will let me confirm the SRAM usage numbers for your setup.