Volatile for Hardware Registers and Shared Memory

What Problem Does volatile Solve?

Modern C compilers are incredibly sophisticated. To generate fast code, they make a key assumption: a variable's value, once loaded into a CPU register, does not change unless the program explicitly modifies it within the current scope of analysis. This allows the compiler to avoid redundant memory reads.

However, this assumption breaks down in two common scenarios in embedded systems:

1. Memory-Mapped Hardware Registers: The value of a hardware status register (e.g., a timer counter, or a UART receive buffer status) can be changed by the hardware itself at any moment, completely independent of the running code.
2. Shared Memory Variables: A global variable might be modified by an Interrupt Service Routine (ISR) or, in a multi-threaded environment, another thread of execution.

In these cases, if the compiler caches the variable's value in a register, your program will miss the external change and operate on stale data, leading to serious bugs. volatile prevents this.

As the video demonstrates, volatile essentially tells the compiler: "Do not make any assumptions about this variable. Every single time my code reads from this variable, you must generate an instruction to load its value from memory. Every time my code writes to it, you must generate an instruction to store the value to memory."

Use Case 1: Memory-Mapped Hardware Registers

Your experience with microcontroller architecture means you're familiar with controlling peripherals like CAN controllers, GPIO, or timers by accessing their registers. In most modern architectures, this is done via Memory-Mapped I/O (MMIO).

From the C compiler's perspective, a hardware register is just a variable at a fixed memory address. Since the hardware can change the register's value at any time (e.g., a status bit flips when a CAN message is received), pointers used to access these registers must point to volatile data.

To solidify this, let's look at a classic example from John Regehr's expert blog post on volatile.

Use Case 2: Shared Variables with Asynchronous Routines

The second primary use case for volatile is for variables that are shared between your main application code and an asynchronous routine, such as an Interrupt Service Routine (ISR) or a signal handler.

Imagine a global flag is_data_ready that is set to 1 inside a CAN Rx interrupt handler. Your main loop polls this flag to know when to process new data.

// This variable can be modified by an ISR
volatile int is_data_ready = 0;

void CAN_RX_ISR(void) {
    // Hardware interrupt triggered by a new CAN message
    // ... code to read message from CAN hardware ...
    is_data_ready = 1; 
}

void main_loop(void) {
    while (1) {
        // Wait for the flag to be set by the ISR
        while (is_data_ready == 0) {
            // Spin
        }
        
        // Reset flag and process data
        is_data_ready = 0;
        process_can_message();
    }
}

Without volatile, the compiler might optimize the inner while (is_data_ready == 0) loop. It would read is_data_ready once, see it's 0, and assume it will stay 0 forever, transforming the loop into an infinite while(true). The volatile keyword forces the compiler to re-read the variable's value from memory on every iteration, ensuring it sees the change made by the ISR. The second example in the Regehr article you just read (the wait_for_done() function) illustrates exactly this scenario.

The Syntax of volatile Pointers

Just like with const, the placement of volatile in a pointer declaration is crucial. It determines whether the pointer itself is volatile or the data it points to is volatile.

Let's break down the different declarations.

Summary of Pointer Syntax:

• volatile int *p; (or int volatile *p;)

  • Meaning: p is a pointer to a volatile int.
  • Use Case: The data at the address can change unexpectedly. This is your go-to for memory-mapped I/O. The address stored in p is considered stable.

• int * volatile p;

  • Meaning: p is a volatile pointer to an int.
  • Use Case: The address stored in p can change unexpectedly (e.g., an ISR might retarget the pointer). The data at the address is considered normal.

• const volatile int *p;

  • Meaning: p is a pointer to a const volatile int.
  • Use Case: The data at the address can change unexpectedly, but your program is not allowed to write to it. This is perfect for a read-only hardware status register.

#include <stdint.h>

// 1. Declare the pointer to the control register here.

void start_and_wait_for_radar_sweep(void) {
    // 2. Start the sweep.
    
    // 3. Poll for completion.
}

#include <stdint.h>

// 1. Declare the pointer. It points to volatile data.
volatile uint32_t* const RADAR_CTRL_REG = (uint32_t*)0x400A8000;

#define ENABLE_BIT (1U << 0)
#define SWEEP_COMPLETE_BIT (1U << 31)

void start_and_wait_for_radar_sweep(void) {
    // 2. Start the sweep using a read-modify-write operation.
    *RADAR_CTRL_REG |= ENABLE_BIT;
    
    // 3. Poll for completion. The 'volatile' is crucial here.
    while ((*RADAR_CTRL_REG & SWEEP_COMPLETE_BIT) == 0) {
        // The compiler is forced to re-read the register from memory
        // in every iteration of this loop.
    }
    
    // Sweep is complete, can proceed...
}

Conclusion

Today we've demystified the volatile keyword, a critical tool for any C programmer working close to the hardware. Unlike const, which is a promise to the compiler, volatile is a command that enforces strict memory access rules.

Key Takeaways:

• volatile prevents the compiler from making assumptions about when a variable's value can change. It disables optimizations that might cache a variable in a CPU register or reorder accesses to it.
• It is essential for correctly accessing memory-mapped hardware registers, whose values can be altered by hardware at any time.
• It is also necessary for variables shared between main program logic and asynchronous routines like Interrupt Service Routines (ISRs).
• The placement of volatile in a pointer declaration is critical. For hardware access, you almost always want a pointer to volatile data: volatile type *ptr;.

Preview of the Next Lesson:
We have now covered const (for immutability) and volatile (for external changes). In the next lesson, we will examine a third, more subtle type qualifier: restrict. This keyword provides a promise to the compiler about pointer aliasing—that different pointers will not point to the same memory—allowing it to unlock another class of powerful optimizations.