C / C++ for Embedded Interviews: Pointers, volatile, Bits Interview Prep

Frequently asked questions

What does the volatile keyword actually do in embedded C?

volatile tells the compiler that a variable can change outside the normal flow of the program, so it must re-read the value from memory on every access and must not optimize the access away or reorder it. You need it for memory-mapped hardware registers, for variables shared with an interrupt service routine, and for flags a peripheral updates. Without volatile, a polling loop like while (!flag) {} can be hoisted into an infinite loop because the compiler proves flag never changes in that scope. A critical interview nuance: volatile guarantees the access is not optimized out, but it does NOT provide atomicity or memory ordering between threads — that needs disabling interrupts, a lock, or C11 atomics. Misusing volatile for concurrency is a classic firmware bug (see /topics/rtos).

How do you set, clear, and toggle a single bit in a hardware register?

Use bitwise operators against a mask, never magic literals. To set bit n: reg |= (1u << n). To clear it: reg &= ~(1u << n). To toggle it: reg ^= (1u << n). To test it: if (reg & (1u << n)). Always use an unsigned literal (1u) so the shift is well-defined and you avoid undefined behavior from shifting into the sign bit of a signed int. For a multi-bit field, mask then shift: (reg >> SHIFT) & MASK to read, and reg = (reg & ~(MASK << SHIFT)) | ((value & MASK) << SHIFT) to write without disturbing other fields. Interviewers watch for read-modify-write hazards on registers shared with an ISR, and for the unsigned-shift detail — both separate candidates who have actually driven hardware (see /topics/arm-cortex-architecture-for-embedded).

What is the difference between const, volatile, and a const volatile pointer?

const and volatile are independent qualifiers, and pointer declarations need careful reading. const means the program will not modify the object through this access; volatile means the value may change unexpectedly and accesses must not be optimized away. They combine: a read-only status register is best typed const volatile uint32_t* — you cannot write it, but every read goes to hardware. Pointer placement matters too: const uint8_t* p is a pointer to const data (you can move the pointer, not change what it points to), while uint8_t* const p is a const pointer to mutable data (fixed address, writable contents). Reading these declarations right-to-left and knowing when to combine const with volatile for memory-mapped I/O is a frequent embedded screening question.

Why is dynamic memory allocation discouraged in embedded firmware?

malloc/free and C++ new/delete bring problems that conflict with constrained, long-running, real-time systems. Heap fragmentation can leave enough total free memory but no contiguous block, causing a late, hard-to-reproduce allocation failure. Allocation time is non-deterministic, which breaks hard-real-time deadlines. On a small MCU there may be no MMU and only kilobytes of RAM, so a leak or fragmentation crashes the device. Standards like MISRA C and many safety profiles restrict or forbid dynamic allocation after init. The common alternatives are static allocation, fixed-size memory pools, and stack allocation, with bounded worst-case usage you can analyze. In interviews, being able to explain the fragmentation and determinism risks — and propose pools — signals real embedded judgment (see /topics/rtos).

How is fixed-point arithmetic used instead of floating point?

Fixed-point represents fractional numbers using integers by reserving a fixed number of bits for the fraction — a Q format. In Q16.16, the low 16 bits are the fraction, so a real value x is stored as round(x * 65536). Addition and subtraction work directly on the integers; multiplication needs a wider intermediate (multiply two Q16.16 values into a 64-bit result, then shift right by 16) to avoid overflow and to rescale. You use it because many MCUs lack a floating-point unit, so software floating point is slow and code-heavy, while fixed-point runs in a few integer instructions with deterministic timing. The trade-offs interviewers probe are range versus precision, overflow handling, and rounding. Knowing how to pick a Q format for a known signal range is a strong DSP/firmware signal.

What makes a C function safe to call from an interrupt service routine?

An ISR must be short, non-blocking, and reentrancy-aware. It must not call non-reentrant or blocking functions — no printf, no malloc, no mutex that could block — and it should not use static or global state that the main code touches without protection. Shared variables read or written by both the ISR and main code must be volatile and accessed atomically; on a small variable you may disable interrupts briefly, and for word-sized flags a single aligned access can be atomic on the target. The typical pattern is to do the minimum in the ISR (clear the source, capture data, set a flag or post to a queue) and defer the work to the main loop or an RTOS task. Demonstrating this ISR-to-task hand-off and the volatile-plus-atomicity rule is a core embedded interview discriminator (see /topics/embedded-engineer-interview-signals, /topics/rtos).

How should an embedded engineer prepare C/C++ topics for interviews?

Anchor on the constrained machine, not language trivia. Be fluent with the memory model: stack versus static versus heap, why heap is avoided, what a pointer really holds, and how to read layered const/volatile declarations. Practice bit manipulation against masks until set/clear/toggle/extract is automatic, and watch the unsigned-shift and read-modify-write hazards. Know volatile precisely — that it stops optimization but gives no atomicity — and pair it with interrupt-disable or atomics for shared state. Be ready to write ISR-safe code and the ISR-to-task hand-off, and to choose a fixed-point Q format for a given range. For C++, focus on what fits firmware: deterministic features, avoiding hidden allocation and exceptions. Tie it to the silicon and the OS you will face (see /topics/arm-cortex-architecture-for-embedded, /topics/embedded-linux-and-device-drivers, /topics/firmware-engineering-academia-to-industry).

Related topics