Embedded C and C++ Programming Questions

Brief approach

Describe the register semantics first, prefer write-one-to-clear (W1C) / write-zero-to-ignore patterns or dedicated SET/CLEAR registers. If only a single read-modify-write (RMW) register exists and bits have side effects, implement atomicity at the software/hardware boundary: avoid touching W1C bits with a plain RMW; instead use read-only masks, separate set/clear paths, and protect RMW with interrupts disabled or a lock. When possible, use bus-supported atomic ops or peripheral-provided SET/CLEAR alias registers.

Concrete safe patterns

• If device provides R/W-set and R/W-clear alias addresses: use those (atomic).
• If only single register and bits are W1C: never write a 1 to a W1C bit unless you intend to clear it; preserve other bits by masking.
• Protect concurrent access with the smallest critical section (disable interrupts or spinlock) when RMW is unavoidable.

Example (embedded C)

volatile uint32_t *REG = (uint32_t *)0x40001000;
#define BIT_MASK   (1u << 3)

// Atomic set using alias (preferred)
volatile uint32_t *REG_SET = (uint32_t *)0x40001004;
*REG_SET = BIT_MASK; // sets bit atomically

// Safe RMW using critical section when no alias exists
void set_bit_safe(void) {
    uint32_t prim = __get_PRIMASK();
    __disable_irq();                  // small critical section
    uint32_t v = *REG;                // read current
    v |= BIT_MASK;                    // modify
    *REG = v;                         // write back (avoid writing 1 to W1C bits unintentionally)
    __set_PRIMASK(prim);
}

Why this works

• Alias SET/CLEAR registers implement atomic single-cycle semantics; use them if present.
• Disabling interrupts (or using a mutex in RTOS) prevents concurrent contexts from interleaving a read and write that would corrupt bits.
• Always construct write values so W1C bits are only set when you intend to clear them; for bits that are cleared by writing 1, write 0 to leave them unchanged unless you mean to clear.

Edge cases & best practices

• Minimize critical-section duration to meet real-time constraints.
• On SMP systems or DMA access, use hardware locks or bus atomic operations; CPU interrupt disable is insufficient.
• Read the datasheet: some status bits are cleared on read (ROC) — treat them differently.
• Add memory barriers (dmb/isb) if register ordering matters.
• Unit-test on target hardware and review with hardware engineer.

Definition — const correctness
Const correctness means marking data that should not be modified with const so the compiler enforces read-only semantics. In embedded code this prevents accidental writes to registers, ROM-backed structures, or shared data.

Key distinctions

• pointer to const T (read-only pointee): const T * p or T const * p
  • p can change, *p cannot.
• const pointer to T (fixed pointer): T * const p
  • p cannot change, *p can.
• both: const T * const p — fixed pointer to read-only data.

Function-signature patterns

• Accept read-only input: void handle(const Sensor *s); (cannot modify Sensor)
• Return or fill output via non-const pointer: int read_sensor(const Sensor *s, SensorReading *out);

Short API example (C)

// sensor.h
typedef struct { volatile uint16_t reg; /* hardware */ } Sensor;
typedef struct { float value; uint32_t timestamp; } SensorReading;

// read from sensor without modifying sensor struct or pointer
int read_sensor(const Sensor *s, SensorReading *out);

// process can accept fixed pointer but not modify pointee
void log_sensor_reading(const Sensor * const s, const SensorReading *r);

Why this helps: const prevents accidental writes to hardware-mapped structs, documents intent, and enables safer compiler checks—important in resource-constrained embedded systems.

Approach (brief)
Implement a slab-like fixed-block allocator: N size classes (configurable powers-of-two or custom sizes). Each class owns a contiguous region split into equal blocks and a singly-linked free list. Allocation/Free are O(1). Useful in embedded contexts for predictability and low overhead.

APIs

• void pool_init(pool_t *p, size_class_t *classes, int n_classes);
• void *pool_alloc(pool_t *p, size_t size);
• void pool_free(pool_t *p, void *ptr);
• diagnostics APIs: pool_stats(pool_t *p, stats_t *out);

Implementation sketch (C)

// simplified types
typedef struct block_hdr { struct block_hdr *next; } block_hdr_t;

typedef struct {
    size_t block_size;
    void *region;           // start of memory for this class
    block_hdr_t *free_list;
    uint32_t total_blocks;
    // diagnostics
    uint32_t free_count;
    uint32_t peak_used;
    uint32_t failed_allocs;
} size_class_t;

typedef struct { size_class_t *classes; int n; } pool_t;

Initialization: carve provided buffer per class, push all blocks onto free_list. Allocation: choose smallest class >= size, pop head, update counters. Free: push block back and sanity-check pointer/magic.

Avoiding fragmentation

• Use fixed-size blocks => no internal fragmentation within a block; choose size classes to limit waste (power-of-two or tuned to app patterns).
• Avoid external fragmentation by not supporting variable-sized allocations inside these pools.
• For large objects, use a separate contiguous allocator or direct malloc; avoid mixing.
• Use alignment and per-class dedicated regions so blocks are compact and cache-friendly.

Bookkeeping & diagnostics

• Per-class: total_blocks, free_count, peak_used, failed_allocs, region start/end.
• Global: allocation/frees counters, current memory in use, max usage.
• Optional per-block guard word / checksum to detect corruption.
• Leak detection: maintain optional bitmap or store an owner ID in block footer for traced allocations (only in debug builds).
• Expose stats via pool_stats and print functions for runtime telemetry.

Complexity & safety

• Alloc/free: O(1). Memory overhead: small per-class metadata. Ensure interrupts disabled or use a lightweight lock when used in ISRs/RTOS contexts.

Definition & primitives (brief)

Atomic operations in C11 live in <stdatomic.h>. They provide lock-free read-modify-write and load/store operations plus explicit memory orderings:

• atomic_load_explicit / atomic_store_explicit
• atomic_fetch_add/ sub / and/or / exchange / compare_exchange_{weak,strong}_explicit
  Memory order enums: memory_order_relaxed, acquire, release, acq_rel, seq_cst.

Example — atomic increment with acquire-release

#include <stdatomic.h>

atomic_uint counter;

void atomic_increment_acqrel(void) {
    // RMW with acquire-release semantics: ensures prior releases from other threads
    // are visible after this operation, and this release is visible to following acquires.
    atomic_fetch_add_explicit(&counter, 1u, memory_order_acq_rel);
}

Explanation: fetch_add is an atomic read-modify-write. Using memory_order_acq_rel guarantees this operation acts as a release on the write side and an acquire on the read side, suitable when the increment synchronizes both sides (e.g., producer updates state and increments a shared counter).

When to use weaker or stronger orderings (embedded focus)

• memory_order_relaxed: use for performance-critical counters/metrics where only atomicity is needed, not ordering (e.g., IRQ incrementing an event count read later without depending on other memory).
• acquire/release or acq_rel: use when you need to order metadata and payload (e.g., producer writes buffer then releases counter; consumer acquires counter then reads buffer).
• memory_order_seq_cst: use when global total ordering is required or for correctness when reasoning about complex interactions across CPUs; costly on some MCUs or when hardware lacks strong fences.
• In constrained embedded systems prefer the weakest ordering that provides correctness to save cycles/power; use stronger orders or explicit fences when interacting with DMA, peripherals, or interrupt handlers that need strict visibility.

Approach / constraints
Keep it very small (few bytes per task), low runtime cost, works on resource-constrained RTOS, and gives actionable behavior in production (safe fail + minimal diagnostics).

Design

• Place a 32-bit canary at the known stack boundary (stack base / high address depending on architecture). Initialize at task create. Also optionally place a mirror at stack top for double-checking.
• Check the canary on every context switch for that task (when popping its context), and on task delete / dynamic stack resize. In debug builds you can check more often (e.g., on syscall entry).
• On detection: avoid complex diagnostics. Increment a persisted error counter / set a non-volatile fault flag, attempt graceful shutdown of the task, and transition device to a safe state. If recovery fails, trigger a controlled reboot with a bootloop protection counter and preserve minimal crash info (task id, stack pointer, canary value) in reserved RAM/MCU backup registers for later retrieval.

Example (C-like)

// assume downward-growing stack: stack_base = high addr
#define CANARY 0xCAFEBABEU

void task_init_stack(TaskControlBlock *tcb, uint8_t *stack_base, size_t size){
    // place canary at stack_base (highest word)
    *((uint32_t*)stack_base) = CANARY;
    tcb->stack_base = stack_base;
    tcb->stack_size = size;
}

bool check_canary(TaskControlBlock *tcb){
    if (*((uint32_t*)tcb->stack_base) != CANARY){
        record_fault(tcb->id);
        attempt_task_shutdown(tcb);
        return false;
    }
    return true;
}

Production handling

• Minimal persisted metadata: fault_count, last_fault_task, last_sp (store in small reserved RAM or RTC backup).
• On fault: try to stop/sandbox offending task; if system integrity is compromised, perform controlled reboot. Use a boot-counter to avoid endless reboot cycles and fall back to a safe minimal firmware mode.
• Telemetry: send a short alert (error code + task id) to backend when network available.

Trade-offs

• Checking on every context switch adds a small CPU cost but catches corruption early; less frequent checks reduce cost but increase time-to-detect.
• Canary size: 32-bit is a good compromise; make it random per-boot to hinder trivial attacks.

This yields a lightweight, low-cost protection with predictable, safe behavior and minimal production diagnostics.