1. What Is a Storage Class?

Every variable in C has a type (what the bits mean) and a storage class (where and for how long the bits are kept). Lesson 4.2 showed that scope and lifetime are separate ideas; the storage classes in embedded C are the keywords that choose between them and, on a microcontroller, choose which physical memory the variable occupies. Every one of the storage classes in embedded C comes down to this.

C has four storage class specifiers that you will meet in everyday code. Each one answers three questions: how long does the object live, which other files can see it, and what does it contain before you assign anything? This is why storage classes in embedded C matter on a small SRAM.

2. auto: The Default for Locals

Inside a function every variable is auto unless you say otherwise. The keyword is almost never written, because writing int x; already means auto int x;. An auto variable is created when execution enters its block and disappears when the block ends. The compiler normally keeps it in a CPU register; if it needs more variables than there are registers, or you take its address, it spills the variable to the stack in SRAM.

Because the stack is reused by every call, an uninitialized auto variable contains whatever an earlier function left behind. On a Cortex-M4 the stack lives at the top of SRAM and grows downward, and it is shared by main(), every function it calls and every interrupt handler. A large automatic array is therefore a classic cause of stack overflow.

3. register: A Hint That Modern Compilers Ignore

register asks the compiler to keep a variable in a CPU register for speed. Two things matter in practice. First, it comes with a rule: you cannot take the address of a register variable, because registers have no addresses. Second, modern compilers allocate registers far better than a programmer can, so with optimization on, register changes nothing except that rule.

On the STM32F407 the Cortex-M4 core has thirteen general purpose registers (R0–R12), so only the hottest few variables of a function ever fit. The compiler decides which. The only remaining legitimate use is in rare hand-tuned inner loops on very old compilers; otherwise leave it out. In C++17 the keyword was removed altogether.

4. static: Program Lifetime in Two Flavours

Lesson 4.2 covered static in detail. The memory view adds one more fact: a static variable never lives on the stack. The linker gives it a fixed address in SRAM at build time. That has three consequences that matter in firmware:

• Its address is the same on every run and can be read from the .map file.
• It is never freed, so it permanently consumes SRAM whether or not its function ever runs.
• It starts at zero or at its initializer without any code in your function: the start-up code did the work before main().

5. extern: A Name Without Storage

extern does not allocate memory. It tells the compiler that an object with this name and type exists in another translation unit and the linker will connect them. Every global you share between files follows the pattern from Lesson 4.1: one definition in a .c file, an extern declaration in a header.

A function declared without a body behaves the same way: void led_toggle(uint8_t bit); is implicitly extern, which is why headers full of prototypes work.

6. The Memory Sections of a Firmware Image

When the linker builds your program it sorts everything into sections. A storage class decides which section a variable goes into, so the section names are essential vocabulary for the storage classes in embedded C:

7. Proof: Where Each Variable Really Goes

Instead of trusting a table, ask the toolchain. The program below is compiled to an object file and inspected with nm, which lists every symbol with a letter for its section. (Upper case = visible to the linker, lower case = local to the file.)

• g_init and s_total have non-zero initializers, so they are in .data.
• g_zero, s_blank and s_calls are zero, so they are in .bss: no initial value needs to be stored in flash.
• g_const and g_msg are const, so they are read-only data.
• a, the automatic variable, does not appear at all: it is a register or a stack slot decided at run time.
• Note the name s_total.N style suffix on static locals: the compiler invents a unique file-level name because the real name is only meaningful inside the function.

The section letters above come from a PC build. The classification is a rule of the C language, so an ARM build with arm-none-eabi-gcc sorts these same variables into the same sections, although the addresses differ. One ARM detail: with the default options, GCC for ARM may also place small const data in .rodata with extra names such as .rodata.str1.1 for string literals.

8. How Much Memory Does a Program Use? The size Command

Embedded builds end with a size report. The numbers map directly to the sections above and they answer the question “will this fit?”:

Rule of thumb for an STM32F407 build: Flash used = text + data and static SRAM used = data + bss. The heap and the stack come on top, so you still need free SRAM for them. A linker error such as “region ‘RAM’ overflowed by N bytes” means data + bss (+ the heap and stack you reserved) exceeded the 128 KB.

9. What the Start-up Code Does Before main()

Power-up leaves SRAM full of random bits. Before your main() can rely on the guarantees of the language, the reset handler must make two memory regions match the C rules. On the STM32F407 it runs this sequence on every reset:

The start-up file generated for the STM32F407 uses symbols created by the linker script to find the regions (typically _sidata for the load address in flash, _sdata/_edata for .data in SRAM and _sbss/_ebss for .bss). A host-side model of the two loops makes the idea visible:

10. Storage Classes in Embedded C: Embedded Significance

On a PC, memory is plentiful and the operating system hides placement. On an STM32F407 you have 1 MB of flash and 128 KB of main SRAM (plus 64 KB of core-coupled memory), so the storage class of each variable is a design decision.

The const trap

const on a global usually means flash, but const on a local only prevents assignment: the object is still on the stack. To keep a table in flash, make it a file-scope or static const object. Lesson 13 returns to this.

11. Common Mistakes With Storage Classes

12. Best Practices for Storage Classes in Embedded C

• Use the storage class that gives the smallest lifetime and visibility that works: locals first, file static next, true globals last.
• Never write auto; do not write register.
• Mark constant tables const at file scope so they stay in flash.
• Keep big buffers out of the stack: static or file-scope, with a clear owner.
• Declare shared variables extern in one header and define them in one source file that includes that header.
• After every build, read the size report and watch data + bss against the 128 KB limit.
• Open the linker map file at least once per project to see the real addresses.
• Initialize automatic variables where you declare them.

Key Takeaways — Lesson 4.3

• The four storage classes in embedded C are auto, register, static and extern.
• auto locals live on the stack (or in registers) and are not initialized.
• register is only a hint and forbids the address-of operator.
• static objects live at a fixed address in .data or .bss for the whole program.
• extern creates no storage; it refers to a definition elsewhere.
• .data uses flash and SRAM; .bss uses SRAM only; const globals use flash only.
• The start-up code copies .data and clears .bss before main().
• Tools: nm shows the section of each symbol and size totals them.

Frequently Asked Questions