1. Home
2. Academy
3. Embedded C from Zero
4. Volume 05

5.1 Local and global variables

Where you declare a variable decides two things: who can see it (its scope), and how long it lasts. Firmware cares about both, because a chip has very little memory to spend.

boot_count starts at 0 (globals begin at zero)
after two calls, boot_count = 2
inside = 1, and it starts again at 0 every call
inside = 1, and it starts again at 0 every call
in the inner block, deeper = 2
outside the block, value = 1

Local: born and gone with the call

A variable declared inside a function exists only while that function runs. Call the function again and you get a fresh one, which is why inside printed 1 both times.

Global: visible everywhere, for the whole run

A global is declared outside every function. It lives from power-on to power-off, and it starts at zero unless you say otherwise - the start-up code clears it before main runs, as Volume 09 will show.

5.2 static and extern

static means two different things. Inside a function, it makes a local remember its value. Outside one, it hides a name from the rest of the program.

static uint32_t next_id(void)
{
    static uint32_t id = 0u;      /* set up once, and remembered between calls */
    id++;
    return id;
}

next_id gives 1
next_id gives 2
next_id gives 3
three calls in one printf came out as 6, 5, 4
private_counter = 5 (this file only)
shared_ticks = 3 (counted in the other file)

The static local lives for the whole run, like a global, but only this function can reach it by name. That is exactly what you want for a counter, a small state machine, or a cached reading.

static on a global: private to this file

static uint32_t private_counter = 0u;   /* this file only */
uint32_t        shared_ticks    = 0u;   /* any file that declares it extern */

A static global cannot be reached from another file, even by a file that declares the same name. That is how a driver keeps its own state private, and it is the closest thing C has to a private member.

extern: the same variable, seen from another file

One file defines the variable. Every other file declares it:

uint32_t shared_ticks = 0u;      /* the one definition */

void tick(void)
{
    shared_ticks++;
}

extern uint32_t shared_ticks;    /* someone else owns this */
void tick(void);

...
printf("%u\n", shared_ticks);    /* prints 3 after three ticks */

5.3 const

const is a promise not to change something through that name. On a chip it has a second benefit: a const table can stay in flash instead of taking up RAM.

static const uint8_t gamma_table[8] = { 0u, 1u, 3u, 8u, 17u, 33u, 61u, 104u };
static const uint32_t baud_rate = 115200u;

static uint32_t sum_table(const uint8_t *table, unsigned count)   /* promises not to change it */
{
    uint32_t total = 0u;
    for (unsigned i = 0; i < count; i++) {
        total += table[i];
    }
    return total;
}

baud_rate = 115200
gamma_table[4] = 17
the whole table adds up to 227
limit = 100

Try to change it and the compiler stops you:

error: assignment of read-only location 'gamma_table[0]'

Why const matters more on a chip

A non-const table has to be copied from flash into RAM at start-up, because the program might change it. A const table can be left where it is and read straight from flash. On a chip with 2 KB of RAM and 32 KB of flash, that is the difference between fitting and not fitting.

5.4 volatile

volatile tells the compiler: this value can change on its own, so read it from memory every single time. Without it, an optimiser is free to read once and reuse the copy for ever.

Here are two identical-looking wait loops, one on a plain variable and one on a volatile:

static uint8_t          plain_flag    = 1u;
static volatile uint8_t volatile_flag = 1u;

unsigned wait_plain(void)
{
    unsigned turns = 0u;
    while (plain_flag != 0u && turns < 3u) { turns++; }
    return turns;
}

unsigned wait_volatile(void)
{
    unsigned turns = 0u;
    while (volatile_flag != 0u && turns < 3u) { turns++; }
    return turns;
}

Run them on a computer and both return 3. The difference is in the machine code the compiler writes. This is the real output of gcc -O2 -S:

wait_plain:
        endbr64
        movl    $3, %eax
        ret

wait_volatile:
        endbr64
        movzbl  volatile_flag(%rip), %eax
        testb   %al, %al
        je      .L6
        movzbl  volatile_flag(%rip), %eax
        testb   %al, %al
        je      .L7
        movzbl  volatile_flag(%rip), %eax
        ...

Look at what happened. Without volatile, the compiler never read the flag at all: it worked the answer out while compiling and returned the constant 3. With volatile, there is a fresh movzbl - a load from memory - before every test.

Where volatile is required

5.5 The stack and function calls

Every call takes a slice of the stack: its locals, its arguments and the address to come back to. The stack is the memory a small chip has least of, and nothing warns you when it runs out.

five nested calls moved the stack by 160 bytes
that is about 32 bytes per call, on this machine
each call also stores the return address and any saved registers

Each call adds a stack frame and each return takes one away. The frames pile up, so the deepest chain of calls in your program decides how much stack you need.

void parse(void)
{
    uint8_t buffer[1024];      /* all on the stack */
    ...
}

error: storing the address of local variable 'here' in 'deepest' [-Werror=dangling-pointer=]

5.6 Recursion, and why firmware avoids it

Recursion is elegant, and firmware mostly avoids it. Each call takes another frame, and the depth often depends on data you cannot see from the code.

uint32_t factorial_recursive(uint32_t n)
{
    if (n <= 1u) {
        return 1u;
    }
    return n * factorial_recursive(n - 1u);    /* one more frame, every time */
}

uint32_t factorial_loop(uint32_t n)
{
    uint32_t result = 1u;
    for (uint32_t i = 2u; i <= n; i++) {
        result *= i;
    }
    return result;                             /* one frame, always */
}

recursive 10! = 3628800, and it went 10 calls deep
loop      10! = 3628800, with one stack frame
both agree for 0! to 12!
13! would overflow a uint32_t, whichever way it is written

Same answers. One of them used ten stack frames to get there; the other used one.

Why firmware says no

• The depth is often unknown. It depends on the input, and the worst case is hard to prove.
• There is no safety net. A desktop gets a crash report. A microcontroller quietly overwrites its own variables, and the symptoms appear somewhere else entirely - a stack overflow.
• It is rarely faster. A loop with no call overhead usually wins.
• Safety standards forbid it. MISRA C and most automotive and medical rules ban recursion outright. Volume 16 covers those rules.

What you learned

• A local lives only while its function runs; a global lives for the whole program and starts at zero.
• static inside a function keeps the value between calls, and keeps the name private.
• static on a global hides it from other files; extern shares one definition between files.
• const is a promise not to change a value, and lets a table stay in flash instead of RAM.
• volatile forces a real read every time: without it, a wait loop can be optimised away entirely.
• Every call takes a stack frame, and a big local array takes it all at once.
• Recursion costs one frame per call, which is why firmware writes a loop instead.

Key words from this volume

Every word below has a plain-English entry in the glossary.

• Scope
• Global variable
• Stack
• static
• const
• volatile
• Stack frame
• Recursion
• Stack overflow

Practice

uint8_t data_ready = 0u;

void ISR_uart(void)     { data_ready = 1u; }

void wait_for_data(void)
{
    while (data_ready == 0u) {
        /* wait */
    }
}

volatile uint8_t data_ready = 0u;

static uint8_t rx_buffer[64];          /* private to this file */
static uint16_t rx_count;              /* private to this file */

static void push_byte(uint8_t b)       /* private helper */
{
    ...
}

void uart_send(const uint8_t *data, uint16_t length)   /* the public one */
{
    ...
}

Interview corner

Next, Volume 06 takes on arrays and strings: how they sit in memory, how to walk them safely, and how a buffer overflow really happens.