Embedded C and C Plus Plus Questions

Skills for writing correct, efficient, and deterministic C and C plus plus code in resource constrained and hardware close environments. Topics include pointer arithmetic and ownership, manual memory management, static versus dynamic allocation, stack and heap tradeoffs, const correctness, volatile qualifier usage, memory mapped input output, struct packing and alignment, bit manipulation, inline assembly basics, compiler optimizations and flags, avoiding or carefully using runtime features such as exceptions and heavy use of templates or virtual functions in constrained contexts, deterministic timing and real time considerations, defensive coding patterns for embedded systems, common embedded idioms and pitfalls, and debugging and toolchain practices such as cross compiling, linkers, and hardware debugging techniques.

EasyTechnical

43 practiced

You boot your microcontroller and it immediately triggers a HardFault. Outline a pragmatic, step-by-step debugging plan to find the root cause using typical embedded tools (JTAG/SWD, map files, symbol information, reading registers). Mention minimally intrusive techniques if the target hardware is fragile.

HardTechnical

41 practiced

You compiled with optimization and noticed a test that relied on a side-effecting read to a peripheral register no longer behaves correctly. The disassembled code shows the read was removed. Explain why this happened, how to fix the code, and how to design code and review practices to prevent such bugs across a codebase.

Sample Answer

**Why the read was removed**

The optimizer saw the register read as having no observable effect on program state (no used value, no volatile qualifier) and removed it (dead-store/elimination or common-subexpression elimination). Compilers assume ordinary memory reads/writes only affect program-visible memory; peripheral registers with side effects (clear-on-read, acknowledge) violate that assumption unless marked accordingly.

**How to fix (concrete example)**

Use volatile or an explicit accessor so reads/writes are treated as side‑effecting:

/* BEFORE - optimizer may drop this */
uint32_t tmp = REG_STATUS;   /* read used only for side-effect: may be removed */

/* AFTER - ensure side effect occurs */
volatile uint32_t * const REG_STATUS_V = (volatile uint32_t *)0x40001000;
uint32_t tmp = *REG_STATUS_V;   /* compiler must perform the read */

Or encapsulate in an accessor:

static inline uint32_t mmio_read(uint32_t addr) {
    return *((volatile uint32_t *)addr);
}

For ordering-sensitive operations, add compiler barriers or platform-specific memory barriers (asm volatile("" ::: "memory") or __DSB(), __ISB()).

**Preventing this across a codebase**

- Coding standard: mandate volatile/atomic/MMIO accessor for memory-mapped I/O; document when to use barriers.- Abstraction: central MMIO API (read/write) so all drivers use the correct pattern.- Code review checklist: verify volatile for peripheral registers, confirm side-effects, require accessor usage.- Tooling: static analysis checks, MISRA rules, grep for raw pointer derefs in drivers.- CI/tests: run integration/HIL tests with optimization flags (O2/O3) and regression tests that exercise side-effecting paths.- Documentation: hardware interface spec explicitly states which registers have side-effects.

These steps avoid silent optimizer-induced bugs while keeping code maintainable and reviewable.

MediumTechnical

54 practiced

A flag variable 'volatile uint8_t data_ready' is set in an ISR and cleared in the main loop. The main loop reads it in a while loop waiting for data_ready == 1. Describe data races, potential optimizations the compiler could do incorrectly if volatile is omitted, and write a robust pattern to safely set/clear and consume this flag including any required memory barriers or atomic semantics.

Sample Answer

**Situation & data-race summary**- data_ready set by ISR and cleared/read by main -> shared variable accessed from two contexts without synchronization.- Race: main may see stale value or perform non-atomic read/write torn on wider types; compiler may optimize away repeated reads or reorder accesses, and CPU may reorder memory operations across ISR boundary.

**What can go wrong if volatile omitted**- Compiler can cache data_ready in a register; the busy-wait may become an infinite loop.- Loads/stores can be reordered around other memory accesses, so main may observe data_ready==1 but not yet see associated data written by ISR (or vice versa).- Optimizer may eliminate "redundant" writes or moves thinking single-threaded semantics apply.

**Robust pattern (preferred, C11 atomics)**- Use atomic with acquire/release semantics so producer-consumer and compiler/CPU orderings are correct.

#include <stdatomic.h>
atomic_uint8_t data_ready = ATOMIC_VAR_INIT(0);

/* ISR: set flag after producing data */
void ISR_Handler(void) {
    // produce data into shared buffer...
    atomic_store_explicit(&data_ready, 1, memory_order_release);
}

/* Main: wait and consume */
void main_loop(void) {
    while (atomic_load_explicit(&data_ready, memory_order_acquire) == 0) {
        // optionally wait, sleep, or low-power
    }
    // now consume data (reads will see writes done before release)
    // clear flag
    atomic_store_explicit(&data_ready, 0, memory_order_release);
}

- memory_order_release in ISR ensures prior writes (the data) are visible before the flag set.- memory_order_acquire in main ensures after seeing flag==1, reads see the produced data.

**If C11 atomics not available**- Keep variable volatile, ensure atomicity by disabling interrupts around non-atomic clears or reads:

volatile uint8_t data_ready;
void ISR_Handler(void) { data_ready = 1; }
void main_loop(void) {
    while (1) {
        if (data_ready) {
            uint32_t prim = disable_interrupts();
            data_ready = 0;
            restore_interrupts(prim);
            // consume data
        }
    }
}

- Alternatively use compiler memory barrier "__asm__ __volatile__ ("" ::: "memory");" around critical ordering points.

**Notes & trade-offs**- Prefer C11 atomics for clarity and portability.- Disabling interrupts is simple but increases latency; use only around the minimal critical section.- Ensure the flag type is naturally atomic on the target (8/16/32-bit bus) or use atomic types to avoid torn writes.

HardSystem Design

52 practiced

Design a GPIO abstraction layer for an embedded platform that must support: 1) low-power safe operations (able to configure wake-up sources), 2) shared pins among multiple drivers with conflict resolution, and 3) IRQ-safe API for setting/clearing pins from ISRs. Sketch the API and describe internal data structures and locking strategies appropriate for small MCUs.

Sample Answer

**Design summary**Provide a small, deterministic GPIO HAL that: 1) preserves a persistent low-power wake config, 2) allows multiple drivers to share a pin via reference-counted ownership and priority arbitration, and 3) exposes IRQ-safe, lock-free operations for ISRs.

**API sketch**

// simple C API
typedef enum { GPIO_DIR_IN, GPIO_DIR_OUT } gpio_dir_t;
typedef enum { WAKE_NONE, WAKE_RISING, WAKE_FALLING, WAKE_BOTH, WAKE_LEVEL } gpio_wake_t;
typedef void (*gpio_cb_t)(uint16_t pin, void *ctx);

int gpio_request(uint16_t pin, uint8_t owner_id, uint8_t priority);
int gpio_release(uint16_t pin, uint8_t owner_id);
int gpio_config(uint16_t pin, gpio_dir_t dir, uint32_t flags); // non-ISR
int gpio_config_wake(uint16_t pin, gpio_wake_t wake); // must persist into low-power
int gpio_set_irqsafe(uint16_t pin, int level); // can be called from ISR
int gpio_clear_irqsafe(uint16_t pin);
int gpio_write_irqsafe(uint16_t pin, bool val); // lock-free for ISR
bool gpio_read(uint16_t pin);
int gpio_attach_callback(uint16_t pin, gpio_cb_t cb, void *ctx, uint8_t owner_id);

**Internal data structures**- struct gpio_pin { - uint16_t pin; - uint8_t owners_bitmap; // small bitmap or fixed array of owner_ids - uint8_t refcount; - uint8_t active_owner; // selected by arbitration - uint8_t priority_map[ MAX_OWNERS ]; - volatile uint32_t hw_state_bits; // reflects output/input and IRQ-safe cached value - gpio_wake_t wake_cfg; // persisted to retained RAM or hardware registers - irq_callback_list_t callbacks; // small fixed-size array - uint8_t flags; }

Store table per port to batch atomic ops.

**Locking & concurrency**- For thread context: use a lightweight mutex or RTOS spinlock per-port for operations that modify owner lists, priorities, or non-ISR config.- For ISR context: provide only bounded, lock-free functions: - Use atomic bit-set/clear (CMSIS LDREX/STREX or single-instruction bit ops) for output toggles. - Keep a small cached hw_state_bits in RAM updated atomically; gpio_write_irqsafe modifies this with atomic ops then writes to ODR. - gpio_config_wake writes hardware wake registers (must be done in thread context); the ISR API only toggles runtime state.- Critical sections: where atomic ops unavailable, temporarily disable interrupts for < 50 cycles to update shared data (document worst-case).

**Conflict resolution**- Request includes owner_id + priority. When multiple owners request conflicting modes (e.g., pull-up vs pull-down), arbitration picks the highest priority owner. Lower-priority owners get error or fallback mode.- Implement a resolve() callback per-pin for special cases (ADC vs GPIO).

**Low-power**- Expose gpio_config_wake storing wake_cfg into retained RAM and configuring hardware wake registers before sleep.- On suspend, freeze current active_owner and wake_cfg; on resume, re-evaluate owner priorities.

**ISR callbacks**- IRQ handler enqueues minimal work: use lock-free ring buffer or set an atomic flag per-pin; actual callbacks run in thread/deferred context to avoid long ISR work. Offer an optional immediate minimal callback for hard real-time needs (document restrictions).

This design keeps ISR paths short and deterministic, supports multi-owner policies, and explicitly separates wake configuration (thread-safe) from IRQ-safe runtime toggles.

HardTechnical

40 practiced

You have a templated C++ utility that is instantiated in many translation units leading to code bloat and long link times. As an embedded developer, propose refactoring techniques to reduce code size and compilation/link times while preserving type safety: consider explicit instantiation, pimpl/type-erasure, reducing template parameter space, or moving heavy templates to single compilation units.

Sample Answer

**Clarify goal & constraints**- Reduce generated code across TUs and link time while preserving type safety and low RAM/flash for embedded targets. Keep predictable performance and no RTTI if constrained.

**Practical techniques**

1) Explicit instantiation / extern template- Move heavy template impl to one .cpp and instantiate only needed types.

cpp

// heavy.h
template<typename T> T heavy_op(T);
// heavy.cpp
#include "heavy.h"
template<typename T> T heavy_op<T>(T x){ /*...*/ }
template double heavy_op<double>(double);
// user.cpp
extern template double heavy_op<double>(double);

- Result: only one copy of code emitted.

2) Pimpl / move implementation to single TU- Expose thin non-template façade in headers, template internals in .cpp via concrete types or small virtual interface when few types exist.- Trade-off: small vtable overhead vs code size savings.

3) Type-erasure / runtime-polymorphism for many template combos- Use small type-erasure wrapper (inlined small-buffer) to hold different concrete instantiations but compile one implementation path.

cpp

// simplified: store callable with erased type to avoid templating across TUs
class Erased {
  struct I { virtual void run()=0; };
  template<typename F> struct Impl : I { F f; void run() override{ f(); } };
  std::unique_ptr<I> p;
public:
  template<typename F> Erased(F fn): p(new Impl<F>{fn}){}
  void run(){ p->run(); }
};

- Preserves safety at runtime, reduces template explosion.

4) Reduce template parameter space- Narrow template axes: prefer traits, enums, tag types, or constexpr parameters grouped into bitfields so compiler sees fewer unique instantiations.- Example: replace bool template params with runtime flags or a single enum tag.

5) Move heavy templates to single TU (monolithic instantiation)- If a template truly needs to be generic, provide explicit instantiations for supported types only; reject others with static_assert.

**Trade-offs & metrics**- Measure binary size and link time before/after; check stack/heap impact of indirection/vtables.- Prefer explicit instantiation for deterministic embedded performance; use type-erasure when many combinations impossible to statically enumerate.

**Recommendation**Start with extern template/explicit instantiation for top offenders, add Pimpl for large classes, then consider type-erasure or parameter consolidation if instantiation count remains high.

Unlock Full Question Bank

Get access to hundreds of Embedded C and C Plus Plus interview questions and detailed answers.

Join thousands of developers preparing for their dream job.