Embedded C Code Patterns

Quick Cap

Embedded C interviews almost always include a "write this on the whiteboard" moment, and the patterns they ask for are remarkably consistent: state machines, ring buffers, bit manipulation, and safe peripheral access. These are not textbook data structures -- they are the daily vocabulary of firmware engineering, shaped by the constraints of no heap, no exceptions, and hardware that only speaks through memory-mapped registers.

Interviewers test whether you can produce these patterns quickly, correctly, and with awareness of ISR safety, volatile correctness, and memory constraints.

Key Facts:

• State machines: The dominant control-flow pattern in firmware. Two flavors -- enum+switch (simple, debugger-friendly) and function-pointer table (scalable, O(1) dispatch).
• Ring / circular buffers: The standard ISR-to-main data path. Power-of-two sizing lets you replace modulo with a bitmask.
• Bit manipulation: Setting, clearing, toggling, and testing individual bits is how you talk to hardware registers. Master the four idioms: |=, &= ~, ^=, & mask.
• Error handling: Embedded C has no exceptions. Return codes, error structs, and sentinel values are the three main strategies.
• Memory-mapped I/O: Peripherals are accessed through volatile pointers to fixed addresses. The volatile keyword prevents the compiler from optimizing away reads or writes.
• Guard clauses: Early-return checks at function entry that prevent null-pointer dereference and invalid-parameter bugs before they propagate.

Deep Dive

At a Glance

State Machines

State machines are the backbone of embedded firmware. A motor controller, a protocol parser, a menu system -- all are state machines. Interviewers expect you to write one from scratch in under 10 minutes.

Pattern 1: Enum + Switch (simple, debugger-friendly)

typedef enum {
    STATE_IDLE, STATE_HEATING, STATE_READY, STATE_ERROR
} oven_state_t;

typedef enum {
    EVT_START, EVT_TEMP_OK, EVT_FAULT, EVT_RESET
} oven_event_t;

oven_state_t oven_step(oven_state_t s, oven_event_t e) {
    switch (s) {
    case STATE_IDLE:
        if (e == EVT_START) return STATE_HEATING;
        break;
    case STATE_HEATING:
        if (e == EVT_TEMP_OK) return STATE_READY;
        if (e == EVT_FAULT)   return STATE_ERROR;
        break;
    case STATE_READY:
        if (e == EVT_FAULT)   return STATE_ERROR;
        break;
    case STATE_ERROR:
        if (e == EVT_RESET)   return STATE_IDLE;
        break;
    }
    return s;  /* no transition -- stay in current state */
}

Pros: easy to step through in a debugger, compiler warns on missing enum cases. Cons: switch-within-switch grows unwieldy past ~8 states.

Pattern 2: Function-Pointer Table (scalable, O(1) dispatch)

typedef void (*state_handler_t)(oven_event_t evt);

static void on_idle(oven_event_t e);
static void on_heating(oven_event_t e);
static void on_ready(oven_event_t e);
static void on_error(oven_event_t e);

/* Table indexed by state enum -- O(1) dispatch */
static const state_handler_t handlers[] = {
    [STATE_IDLE]    = on_idle,
    [STATE_HEATING] = on_heating,
    [STATE_READY]   = on_ready,
    [STATE_ERROR]   = on_error,
};

void oven_dispatch(oven_state_t *state, oven_event_t evt) {
    handlers[*state](evt);
}

Pros: adding a state means adding one function and one table entry -- no existing code changes. Cons: slightly harder to follow in a debugger; the table sits in .rodata (flash).

Ring / Circular Buffers

The ring buffer is the universal ISR-to-main data pipe. A UART receive ISR pushes bytes in; the main loop pulls them out. The key constraint: it must be safe without disabling interrupts, which means single-producer/single-consumer with careful index management.

#define RB_SIZE 64                  /* must be power of 2 */
#define RB_MASK (RB_SIZE - 1)

typedef struct {
    volatile uint8_t buf[RB_SIZE];
    volatile uint16_t head;         /* write index (ISR) */
    volatile uint16_t tail;         /* read index (main) */
} ringbuf_t;

/* Called from ISR -- single producer */
static inline bool rb_put(ringbuf_t *rb, uint8_t byte) {
    uint16_t next = (rb->head + 1) & RB_MASK;
    if (next == rb->tail) return false;  /* full */
    rb->buf[rb->head] = byte;
    rb->head = next;
    return true;
}

/* Called from main loop -- single consumer */
static inline bool rb_get(ringbuf_t *rb, uint8_t *byte) {
    if (rb->head == rb->tail) return false;  /* empty */
    *byte = rb->buf[rb->tail];
    rb->tail = (rb->tail + 1) & RB_MASK;
    return true;
}

Why power-of-two sizing? (index + 1) & MASK is a single AND instruction, while (index + 1) % SIZE requires a division. On Cortex-M0 (no hardware divider), the modulo version is 10-20x slower.

This design wastes one slot (full = head one behind tail), but avoids the need for a separate count variable, which would require atomic access or interrupt disabling.

Bit Manipulation Patterns

Hardware registers are controlled bit-by-bit. The four fundamental operations:

#define BIT(n)  (1U << (n))

/* Set bit n */
reg |= BIT(n);

/* Clear bit n */
reg &= ~BIT(n);

/* Toggle bit n */
reg ^= BIT(n);

/* Test bit n */
if (reg & BIT(n)) { /* bit is set */ }

Multi-bit field access (e.g., a 3-bit prescaler in bits [6:4]):

#define PRESCALER_MASK  (0x7U << 4)   /* bits [6:4] */
#define PRESCALER_SHIFT 4

/* Read the field */
uint8_t prescaler = (reg & PRESCALER_MASK) >> PRESCALER_SHIFT;

/* Write the field without disturbing other bits */
reg = (reg & ~PRESCALER_MASK) | ((value << PRESCALER_SHIFT) & PRESCALER_MASK);

Always use 1U (unsigned) in shift expressions. 1 << 31 is undefined behavior on a 32-bit int because it overflows into the sign bit. 1U << 31 is well-defined.

Error Handling Patterns

Embedded C has no exceptions, no try/catch, and often no heap for error objects. Three common strategies:

Pattern 1: Return codes (most common)

typedef enum {
    ERR_OK = 0, ERR_TIMEOUT, ERR_CRC, ERR_BUSY, ERR_PARAM
} err_t;

err_t sensor_read(uint8_t addr, uint16_t *value) {
    if (addr > MAX_ADDR) return ERR_PARAM;
    if (!bus_ready())    return ERR_BUSY;
    /* ... perform read ... */
    if (timed_out)       return ERR_TIMEOUT;
    if (crc_bad)         return ERR_CRC;
    *value = raw;
    return ERR_OK;
}

Pattern 2: Error struct (when you need context)

typedef struct {
    err_t    code;
    uint16_t line;       /* __LINE__ of the failure */
    uint32_t timestamp;  /* tick count at failure */
} err_info_t;

static err_info_t last_error;

void record_error(err_t code, uint16_t line) {
    last_error.code      = code;
    last_error.line      = line;
    last_error.timestamp = tick_count;
}

Pattern 3: Sentinel values (lightweight but limited)

/* Return UINT16_MAX as "invalid" -- only works if that value is
   never a legitimate reading */
uint16_t adc_read(uint8_t ch) {
    if (ch >= NUM_CHANNELS) return UINT16_MAX;
    /* ... */
    return result;
}

In safety-critical code (MISRA, IEC 62304), all function return values must be checked. This makes Pattern 1 the default choice because it forces callers to inspect the result.

Memory-Mapped I/O Access

On bare-metal systems, peripherals are accessed by reading and writing to fixed memory addresses. The volatile keyword is mandatory -- without it, the compiler may cache a register read in a CPU register and never re-read the hardware.

/* Define a peripheral register block */
typedef struct {
    volatile uint32_t CR;    /* control register  */
    volatile uint32_t SR;    /* status register   */
    volatile uint32_t DR;    /* data register     */
} USART_t;

/* Place the struct at the peripheral's base address */
#define USART1 ((USART_t *)0x40011000U)

/* Access registers like struct fields */
void usart1_send(uint8_t byte) {
    while (!(USART1->SR & BIT(7)))  /* wait for TXE */
        ;
    USART1->DR = byte;
}

This pattern is how every vendor HAL (STM32 HAL, NXP SDK, TI DriverLib) defines peripheral access. Interviewers expect you to recognize it and explain why every field must be volatile.

Guard Clauses and Defensive Initialization

Guard clauses are early-return checks at the top of a function. They prevent null-pointer dereference and invalid-parameter bugs before any work is done:

err_t motor_set_speed(motor_t *m, int32_t rpm) {
    if (m == NULL)                  return ERR_PARAM;
    if (rpm < MIN_RPM || rpm > MAX_RPM) return ERR_PARAM;
    if (m->state != STATE_RUNNING)  return ERR_BUSY;

    /* Only reached with valid, non-null, in-range params */
    m->target_rpm = rpm;
    update_pwm(m);
    return ERR_OK;
}

For initialization, a common embedded pattern is the "init-once" guard:

static bool initialized = false;

err_t subsystem_init(void) {
    if (initialized) return ERR_OK;  /* idempotent */
    /* ... perform one-time hardware setup ... */
    initialized = true;
    return ERR_OK;
}

This makes initialization calls safe to repeat, which simplifies startup sequencing when multiple modules depend on the same subsystem.

Debugging Story: The State Machine That Never Left IDLE

A team building a Bluetooth LE beacon had a state machine that processed connection events. In testing, the device advertised correctly but never transitioned from STATE_ADVERTISING to STATE_CONNECTED -- even though the BLE stack was firing the connection event.

After hours of printf debugging, the root cause turned out to be trivial: the event dispatch function used a local copy of the state variable instead of a pointer to the actual state. Transitions happened to the copy and were discarded when the function returned.

/* Bug: state is passed by value -- transitions are lost */
void process(oven_state_t state, oven_event_t evt) {
    /* ... state = STATE_HEATING; -- modifies local copy only */
}

/* Fix: pass pointer so transitions persist */
void process(oven_state_t *state, oven_event_t evt) {
    /* ... *state = STATE_HEATING; -- modifies the real state */
}

Lesson: In C, function arguments are always passed by value. If a function needs to modify a variable that outlives the call, it must receive a pointer to that variable. This is especially easy to forget with enum types because they behave like plain integers.

What interviewers want to hear: You can write a state machine in two forms (switch and function-pointer table) and explain the trade-offs. You implement ring buffers with power-of-two sizing and understand why a count variable introduces a race condition between ISR and main. Your bit manipulation uses 1U (unsigned) shifts and you can access multi-bit fields with mask-and-shift. You handle errors with return codes and always check them. You know that peripheral registers require volatile pointers, and you start every function with guard clauses for null and out-of-range parameters.

Interview Focus

Classic Embedded C Pattern Interview Questions

Q1: "Implement a state machine for a simple device with IDLE, RUNNING, and ERROR states."

Model Answer Starter: "I'd define an enum for states and an enum for events, then write a transition function using a switch statement. Each case handles the events valid for that state and returns the new state. For a more scalable approach, I'd use a function-pointer table indexed by the state enum -- adding a new state is just adding a handler function and a table entry, with no modifications to existing code. Either way, I always handle the default case to catch unexpected states or events."

Q2: "Write a circular buffer for a UART receive ISR."

Model Answer Starter: "I'd use a fixed-size array with head and tail indices. The ISR writes at head and advances it; the main loop reads at tail and advances it. I size the buffer to a power of two so I can use & MASK instead of modulo for wrapping. I detect full/empty by comparing head and tail directly, sacrificing one slot to avoid needing a count variable -- a count would require atomic access or critical sections because both the ISR and main touch it."

Q3: "How do you set, clear, and toggle specific bits in a hardware register?"

Model Answer Starter: "Set with reg |= (1U << n), clear with reg &= ~(1U << n), toggle with reg ^= (1U << n), test with if (reg & (1U << n)). I always use 1U instead of 1 to avoid undefined behavior when shifting into the sign bit on a 32-bit int. For multi-bit fields I define a mask and shift value, read with (reg & MASK) >> SHIFT, and write with reg = (reg & ~MASK) | ((val << SHIFT) & MASK) to avoid disturbing other bits."

Q4: "How do you handle errors in embedded C without exceptions?"

Model Answer Starter: "I use an error enum returned from every function that can fail -- ERR_OK is always zero so callers can do if (result) to check for errors. For functions that return data, the data goes through an output pointer parameter. For richer diagnostics, I keep a global last_error struct with the error code, source line, and timestamp. In safety-critical code, MISRA requires every return value to be checked, which makes the return-code pattern mandatory."

Q5: "Why must peripheral register pointers be declared volatile?"

Model Answer Starter: "Without volatile, the compiler is free to optimize based on the C abstract machine, where memory only changes when the program writes to it. A hardware status register changes asynchronously -- the TXE flag gets set by the UART peripheral, not by your code. Without volatile, the compiler may read the status register once, cache the result in a CPU register, and never re-read it, turning a polling loop into an infinite loop. volatile tells the compiler that every read and write must go to actual memory."

Trap Alerts

• Don't say: "I'd use malloc for the ring buffer" -- embedded ring buffers use statically allocated arrays. Heap allocation in an ISR is a disqualifying answer.
• Don't forget: The 1U in (1U << n). Using signed 1 and shifting left by 31 is undefined behavior on a 32-bit int, and interviewers know this.
• Don't ignore: ISR safety in ring buffers. If you use a count variable modified by both ISR and main without protection, you have a race condition.

Follow-up Questions

• "How would you extend your state machine to support entry and exit actions?"
• "What happens to your ring buffer if interrupts are nested and two ISRs write to it?"
• "How would you make your error-handling pattern thread-safe under an RTOS?"
• "Can you read-modify-write a hardware register safely from both main and ISR context?"

Practice

Real-World Tie-In

Automotive HVAC Controller -- A climate control module used a 12-state function-pointer state machine to manage blower speed, temperature blend, and recirculation mode. When a new "defrost priority" mode was added, the developer added one handler function and one table entry without touching the other 12 handlers. The change passed integration testing on the first attempt because the existing state transitions were untouched.

Industrial Sensor Hub -- A vibration monitoring system buffered ADC samples at 10 kHz in a 1024-element ring buffer (power-of-two). The ISR wrote samples and the main loop ran an FFT when 512 samples accumulated. The original design used a count variable, which caused occasional off-by-one glitches in the FFT input. Switching to head/tail-only full/empty detection eliminated the glitch entirely.

Medical Infusion Pump Audit -- During FDA 510(k) review, every function in the pump's firmware was required to check input parameters and return a defined error code on failure. The team had used guard clauses consistently, which allowed the auditor to trace every failure path from function entry to error return in under 30 minutes per module -- a process that typically takes hours with ad-hoc error handling.