What Is an Embedded System?

An embedded system is a computer built into a product to do one job reliably — the controller in a washing machine, a car's airbag ECU, a pacemaker or a drone flight controller. Learn the building blocks (MCU, memory, peripherals, sensors, actuators, power), how embedded differs from desktop computing, real-time and resource constraints, the development workflow from toolchain to flashing, and the career map of this branch.

Over 98% of all processors ever made are not in PCs or phones — they are hidden inside products. A modern car contains 70–150 of them; a home may contain hundreds. Each runs firmware written for one specific purpose, often for years without a reboot.

Embedded engineering sits between electronics and software: you read datasheets and schematics, write C that touches hardware registers, meet timing deadlines measured in microseconds, squeeze code into kilobytes, and make batteries last for years. This branch takes you from a blinking LED to RTOS-based, secure, safety-certified systems.

An analogy

A desktop PC is a Swiss-army knife: it can do anything, reasonably well. An embedded system is a scalpel: designed for exactly one job, and it does that job perfectly, cheaply and predictably — every single time.

Anatomy of an embedded system

Every embedded product contains the same functional blocks:

Embedded vs general-purpose computing

A PC has gigabytes of RAM, an operating system and runs arbitrary programs. A typical MCU has 32–512 KB of Flash and 8–256 KB of RAM, often no OS, and runs one program forever. It must start in milliseconds, survive power glitches, cost cents to dollars, and sometimes run 10 years on a coin cell.

Real-time: correct AND on time

In an embedded system a late answer can be a wrong answer. An airbag must fire within ~20 ms; a motor controller updates PWM every 50 µs. Hard real-time: missing a deadline is a failure. Soft real-time: occasional misses degrade quality (audio glitches). Firmness of deadlines drives architecture choices: super loop, interrupts, or an RTOS.

The development workflow

From idea to product:

Design trade-offs

Every decision trades cost, power, performance, reliability, time-to-market and safety. Choosing a larger MCU simplifies software but adds cost for a million units; an RTOS eases complexity but costs RAM; floating point is convenient but a Cortex-M0 has no FPU. Professional embedded engineers make these trade-offs with numbers — the calculators throughout this branch give you those numbers.

Formulas

Worked example: Instruction timing

Given: Cortex-M3 at 72 MHz, ~1 instruction/cycle

Find: Instructions available in a 50 µs PWM period.

Answer: ≈ 3600 instructions per control period

Worked example: Battery life of a sensor

Given: 2000 mAh battery; 10 mA active for 1% of the time; 5 µA sleep

Find: Battery life.

Answer: ≈ 794 days (2.2 years)

Worked example: Choosing the processor

Given: Smart thermostat: touchscreen, Wi-Fi, 2 sensors

Find: MCU or MPU?

Answer: A Wi-Fi MCU (e.g. ESP32-S3 with PSRAM) — cheaper and lower power than an MPU running Linux.

The classic bare-metal 'super loop'

#include <stdint.h>
#include "board.h"            /* board support: pins, clocks */

int main(void)
{
    board_init();             /* clocks, GPIO, UART, ADC ... */

    for (;;) {                /* embedded programs never return */
        uint16_t raw = adc_read(TEMP_CHANNEL);
        int16_t  temp_c10 = adc_to_celsius_x10(raw);   /* 23.4 C -> 234 */

        if (temp_c10 > 800) {             /* above 80.0 C */
            gpio_write(FAN_PIN, 1);
        } else if (temp_c10 < 700) {      /* hysteresis: off below 70.0 C */
            gpio_write(FAN_PIN, 0);
        }

        led_toggle(STATUS_LED);           /* heartbeat */
        delay_ms(100);
    }
}

Read sensors → decide → drive actuators → repeat forever. Note integer 'tenths of a degree' instead of float and the 10 °C hysteresis band that stops the fan chattering on and off at the threshold.

Common mistakes

Applications

Key takeaways

Going further