Embedded systems fundamentals

That it exists to control something physical, and that the physical thing sets the requirements. A web service can be a second late and nobody dies; a motor commutation routine that is a hundred microseconds late destroys the motor. From that follow the properties people list as characteristics: fixed and small memory, no operating system or a very thin one, a single application that owns the whole machine, and a strong preference for behaviour that is predictable over behaviour that is fast on average. The consequence for interviews is that questions about worst cases matter more than questions about throughput, because the deadline is the requirement and the average is not.

A microcontroller integrates the CPU, its memory and its peripherals on one die, and it boots straight into your code out of on-chip flash. A microprocessor is a CPU that expects external DRAM, external storage, a bootloader and usually a full operating system with virtual memory. The practical differences that matter are memory scale, from tens of kilobytes against gigabytes, and memory protection: a microcontroller commonly has no MMU, so there is one flat address space with no process isolation and a bad pointer corrupts whatever it points at. Choosing between them is really choosing whether you want Linux and its ecosystem or determinism and instant boot.

That your code is the only software on the part. There is no scheduler, so nothing preempts your main loop except interrupts you enabled. There is no memory manager, so the addresses in your pointers are physical addresses of real SRAM and real peripheral registers. There is no driver layer unless you wrote it, so configuring a UART means writing specific bits into specific registers described in a reference manual. And there is no process to kill when something goes wrong, so an infinite loop is the end of the device until something resets it. The freedom and the exposure are the same fact.

Flash and RAM hold different things for different reasons, and candidates who blur them cannot explain start-up.

region  contents                          writable   survives power   who fills it
------  --------------------------------  ---------  --------------   ----------------------
flash   .text  machine code               no*        yes              programmer or bootloader
flash   .rodata constants, lookup tables  no*        yes              programmer or bootloader
flash   init images for .data             no*        yes              programmer or bootloader
RAM     .data  initialised globals        yes        no               start-up copy from flash
RAM     .bss   zero-init globals          yes        no               start-up memset to zero
RAM     heap   if present at all          yes        no               allocator at run time
RAM     stack  call frames, ISR frames    yes        no               hardware and compiler

* erasable and rewritable in blocks, but not byte-writable at run speed

The row that explains most confusion is .data. An initialised global costs you space twice: once in flash for the initial values and once in RAM for the live copy, plus start-up time to copy between them. A const table costs only flash, which is why moving a large lookup table to const can free kilobytes of RAM without changing a line of logic.

The other row worth reading carefully is flash's write behaviour. Flash is read like memory but written like a device: you erase a whole page, then programme within it, and both operations take orders of magnitude longer than a RAM write and often stall instruction fetch from the same bank. That is why a firmware update is a scheduling problem, not just a data-transfer problem, and why a variable you want to persist cannot simply be assigned to.

Nothing in the RAM rows survives a power cycle, which is why persistent settings need flash or an external EEPROM and a plan for what happens if power is lost half-way through writing them.

A hard real-time system has deadlines where a late answer is a wrong answer, and the design must guarantee the worst case rather than optimise the average. Soft real-time means lateness degrades quality — a dropped audio sample, a stuttering display — without making the result invalid. Firm sits between: the late result is useless but not dangerous. The distinction drives everything else. A hard deadline bans unbounded constructs, so no dynamic allocation in the path, no unbounded loops, no waiting on something with no timeout, and it forces you to be able to state the worst-case execution time of the code involved.

Jitter is the variation in when a periodic thing actually happens. A control loop nominally running every millisecond that in reality runs at 0.9 and then 1.1 milliseconds has 200 microseconds of jitter, and its average is perfect. It matters more than the average because control mathematics assumes a fixed sample interval: variable timing shows up as noise in the derivative term, as distortion in sampled audio, and as commutation error in a motor drive. Its usual sources are interrupts of differing duration, code paths with data-dependent branches, and cache or flash-accelerator behaviour that varies by address.

A hardware abstraction layer wraps peripheral registers in functions so application code says "send this buffer over SPI" rather than writing bits into a control register. A board support package is the layer above it that encodes the specific board: which pin the LED is on, which I2C address the temperature sensor answers to, what the crystal frequency is, and the pin multiplexing that routes internal peripherals to physical pins. The distinction matters because a HAL is portable across boards using the same chip family and a BSP is not, and mixing board-specific constants into driver code is the usual reason a firmware port to the next revision of the hardware takes weeks.