Embedded Systems Engineer Interview Prep Guide

Bare-metal: direct hardware access, deterministic timing, minimal overhead, suitable for simple single-purpose systems. RTOS: task scheduling with priorities, inter-task communication (queues, semaphores), better code organization for complex systems. Choose bare-metal for cost-sensitive high-volume products with simple functionality. Choose RTOS when you need multiple concurrent tasks with different priorities, complex state machines, or network connectivity. Discuss preemptive vs cooperative scheduling.

Use volatile for shared variables, separate read and write indices, and ensure atomic operations on the index variables. The key insight is that with a single producer and single consumer, you only need memory barriers (not mutexes) if each index is written by only one side. Size the buffer as a power of 2 for efficient modulo with bitwise AND. Discuss cache coherency issues on multi-core systems.

Enable hard fault handler that saves the fault register values and stack frame. Check for: stack overflow (use stack guards or MPU), null pointer dereference, misaligned memory access, and buffer overflows. Use watchpoints to catch invalid memory writes. Enable static analysis tools (MISRA C checker, Polyspace). If timing-related, check for race conditions between ISRs and main code. Use a trace buffer (ETM/SWO) to capture execution history leading up to the fault.

Focus on power management: sleep modes (deep sleep consuming microamps), wake on interrupt, duty cycling (measure, transmit, sleep), and efficient communication protocol (LoRaWAN or BLE with minimal connection time). Software design: event-driven architecture with state machines, minimize active time, use DMA for data transfers to keep CPU sleeping, and implement adaptive sampling rates based on measured conditions. Discuss power budgeting calculations.

volatile tells the compiler not to optimize away reads/writes because the value can change outside program control. Three scenarios: 1) Hardware register access (status register that changes via hardware), 2) Shared variable between ISR and main code (flag set in ISR, polled in main loop), 3) Memory-mapped I/O (reading a FIFO that returns different values each read). Discuss that volatile alone is insufficient for multi-core systems where you also need memory barriers.

SPI: full-duplex, fast (up to 50+ MHz), requires more pins (CLK, MOSI, MISO, CS per device), no addressing. I2C: half-duplex, slower (100kHz-3.4MHz), 2 wires with addressing, supports multi-master. UART: point-to-point, asynchronous, simple but limited. Design example: SPI for high-speed sensor data (IMU), I2C for configuration of multiple low-bandwidth sensors (temperature, humidity), UART for debug console and GPS module. Discuss DMA integration for each.

Describe a specific scenario: incorrect sensor readings, communication failures, or timing issues. Explain how you isolated whether the issue was hardware (use oscilloscope, logic analyzer) or software (step through debugger, add instrumentation). Discuss your systematic approach: verify at the physical layer first, then protocol layer, then application layer. Include the resolution and what processes you put in place to prevent similar issues.

Discuss safety standards: ISO 26262 for automotive (ASIL levels), IEC 62304 for medical devices. Cover coding standards (MISRA C), static analysis, formal verification for critical paths, hardware watchdog timers, redundant computation with voting, memory protection units (MPU), and graceful degradation. Explain the V-model development process and requirements traceability. Mention certification requirements and documentation.