What is an Embedded System? Components, Types, Examples and How It Works
An embedded system is a computer built into a product to do one job, usually under tight limits on timing, power and cost. Here are its parts, the main types, how the firmware runs, and the skills you need to work on one.

In short
- An embedded system is a computer built into a larger product to do one dedicated job, usually under tight limits on timing, power, memory and cost.
- It combines hardware (a microcontroller or processor, memory, peripherals, sensors and actuators) with firmware that runs the same control loop for the product's whole life.
- Small systems run bare-metal code, many run a real-time operating system (RTOS), and larger ones run embedded Linux.
- Embedded C remains the core skill, alongside microcontroller architecture, communication protocols and debugging on real hardware.
What is an embedded system?
An embedded system is a combination of computer hardware and software designed to perform a specific function inside a larger device. You do not "use" it the way you use a laptop. You use the washing machine, the car or the pacemaker, and the embedded system quietly runs it.
Three things set embedded systems apart from general-purpose computers:
- A dedicated job. An airbag controller does one thing, and it is designed, tested and certified for exactly that.
- Real-time behaviour. Many embedded systems must respond within a fixed time, not just "fast". A late answer can be as bad as a wrong one.
- Tight constraints. Limited memory, low power budgets (sometimes a coin cell for ten years), harsh temperatures and vibration, and unit costs where a few rupees per board matter at a volume of millions.
Examples of embedded systems
| Product | What the embedded system does | Typical hardware |
|---|---|---|
| Washing machine | Reads the program selection, water level and motor speed; runs wash, rinse and spin cycles | Low-cost 8-bit or 32-bit microcontroller |
| Car ABS module | Reads wheel speeds and modulates brake pressure many times a second to stop wheels locking | Automotive 32-bit MCU, CAN, safety-certified software |
| EV battery management system | Monitors every cell, estimates state of charge, protects the pack | Automotive MCU with cell-monitoring ICs |
| Smart electricity meter | Measures energy, stores readings, communicates with the utility | Low-power MCU with metering front-end and radio |
| Drone flight controller | Fuses IMU and GPS data and drives four motors to keep the drone stable | 32-bit MCU running an RTOS |
| Wi-Fi router | Routes packets, runs the web interface, manages security | Multi-core SoC running embedded Linux |
A modern car contains dozens of these controllers, called ECUs (electronic control units), for the engine or motor, brakes, airbags, body electronics, infotainment and driver assistance.
Embedded system vs general-purpose computer
| Embedded system | General-purpose computer | |
|---|---|---|
| Purpose | One dedicated function | Runs whatever software the user installs |
| Timing | Often hard or soft real-time deadlines | Best effort |
| Resources | Kilobytes to a few gigabytes of memory, milliwatts to a few watts | Gigabytes of memory, tens to hundreds of watts |
| User interface | None, or buttons, LEDs and a small display | Keyboard, mouse, large display |
| Software updates | Rare and controlled (bootloader, over-the-air) | Frequent |
| Lifetime | Often 10 to 20 years in the field | A few years |
Components of an embedded system
Hardware
- Processor. Most embedded systems use a microcontroller (MCU): CPU core, flash memory, RAM and peripherals on one chip, such as parts built on Arm Cortex-M cores. Bigger systems use a microprocessor or SoC with external memory and a memory management unit, able to run Linux. Signal-heavy work may use a DSP, and very high-speed or highly parallel logic may use an FPGA.
- Memory. Flash holds the program and constants; RAM holds variables and the stack. On a small MCU you count both in kilobytes, which shapes how you write code.
- Peripherals. ADCs read analogue sensors, timers generate PWM for motors and LEDs, GPIO pins read switches and drive relays, and communication blocks (UART, SPI, I²C, CAN) talk to other chips and controllers. A watchdog timer resets the system if the software hangs.
- Sensors and actuators. The link to the physical world: temperature, pressure, current, position and motion sensors on one side; motors, valves, heaters and displays on the other.
- Power, clock and reset. Voltage regulators, a crystal or oscillator, and brown-out detection so the system behaves predictably when the supply dips.
Software
- Startup code and bootloader: set up clocks and memory, and in many products allow the firmware to be updated safely.
- Drivers and hardware abstraction layer (HAL): code that talks to the peripherals so the rest of the program does not have to deal with registers directly.
- Operating system (optional): none for bare-metal designs, an RTOS for multitasking with deadlines, or embedded Linux for feature-rich devices.
- Middleware: communication stacks, file systems, security and update libraries.
- Application: the control logic that makes the product do its job.

How an embedded system works
Almost every embedded system runs the same loop: sense, decide, act, then repeat, forever. A motor controller reads current and position, computes the next PWM duty cycle, updates the output, and does it again a few microseconds later.
Timing is the heart of it. Suppose a control loop must run at 1 kHz on an MCU clocked at 160 MHz. That gives 160,000,000 / 1,000 = 160,000 clock cycles per period for reading sensors, running the control law, handling communication and any background work. If one path through the code occasionally takes longer, the loop misses its deadline. Embedded engineers measure worst-case execution time, not just the average, for exactly this reason.
A minimal bare-metal pattern looks like this: a hardware timer interrupt fires every millisecond, sets a flag, and the main loop does the work when the flag is set.
volatile uint8_t tick = 0;
/* timer interrupt: fires every 1 ms */
void TIMER_IRQHandler(void) {
clear_timer_flag();
tick = 1;
}
int main(void) {
system_init(); /* clocks, I/O, timer */
for (;;) {
if (tick) {
tick = 0;
float t = read_temp();
float duty = control(t);
set_pwm(duty);
}
kick_watchdog();
}
}
The interrupt keeps the timing exact, the main loop keeps the logic simple, and the watchdog resets the MCU if anything ever stops the loop from running.
Bare metal, RTOS or embedded Linux?
- Bare metal: a super loop plus interrupts, like the example above. Smallest, fastest to start, easiest to reason about for simple products.
- RTOS: when the product has several jobs with different deadlines (control, communication, logging, user interface), a real-time operating system such as FreeRTOS or Zephyr schedules them as separate tasks with priorities, and provides queues, semaphores and timers.
- Embedded Linux: for devices that need networking stacks, file systems, displays, cameras or complex software, built with tools such as Yocto or Buildroot on an SoC with an MMU. It is powerful but not hard real-time on its own, so time-critical control often stays on a separate MCU.
Types of embedded systems
By performance and complexity
- Small-scale: 8-bit or small 32-bit MCUs, kilobytes of memory, bare-metal code. Toys, remote controls, simple appliances.
- Medium-scale: 32-bit MCUs, often with an RTOS and several communication interfaces. Motor drives, BMS, industrial controllers, most automotive ECUs.
- Sophisticated: multi-core SoCs, sometimes with GPUs or AI accelerators, running Linux or a hypervisor. Infotainment, ADAS, routers, medical imaging.
By function and timing
- Standalone: works on its own, such as a digital thermometer or microwave oven.
- Real-time: must meet deadlines. In hard real-time systems (airbags, ABS, pacemakers) a missed deadline is a failure. In soft real-time systems (video streaming, a set-top box) an occasional miss degrades quality.
- Networked: depends on communication with other nodes, such as IoT sensors, smart meters and vehicle ECUs on a CAN bus.
- Mobile and wearable: battery-powered, where energy per operation drives every design choice.
Communication protocols you will meet
| Protocol | Typical use | Notes |
|---|---|---|
| UART | Debug consoles, GPS modules, simple links | Two wires, point to point, asynchronous |
| SPI | Flash memory, displays, fast sensors, ADCs | Fast, full duplex, one chip-select per device |
| I²C | Low-speed sensors, EEPROMs, power management chips | Two wires, many devices on one bus with addresses |
| CAN / CAN FD | Vehicle ECUs, industrial machines, BMS | Robust differential bus with arbitration and error handling |
| LIN | Low-cost vehicle body functions: windows, mirrors, seats | Single wire, one master |
| Ethernet | Automotive backbones, cameras, industrial networks | High bandwidth; automotive variants run over a single twisted pair |
| BLE, Wi-Fi, LoRa | Wearables, IoT devices | Wireless, with power and range trade-offs |
Our post on the advantages of the CAN protocol explains why CAN became the standard in vehicles.
Embedded systems in vehicles: AUTOSAR, ISO 26262 and MISRA C
Automotive is one of the largest employers of embedded engineers, and it adds its own layer of standards:
- AUTOSAR defines a standard software architecture for ECUs. The Classic Platform targets deeply embedded, real-time ECUs; the Adaptive Platform targets high-performance computers for driver assistance and connected features.
- ISO 26262 is the functional safety standard for road vehicles. Its current edition was published in 2018, and a new edition is in development. It defines safety integrity levels (ASIL A to D) and the development and verification work each level requires.
- MISRA C is a set of coding guidelines for C in safety-critical systems. The current version is MISRA C:2025, published in March 2025.
The industry is also moving from dozens of separate ECUs towards fewer, more powerful zonal and central computers (often called the software-defined vehicle), which increases demand for engineers who understand both low-level firmware and larger software platforms.
How embedded products are developed
- Requirements: what the product must do, its timing, power, safety and cost targets.
- Hardware and software architecture: choose the processor, peripherals and OS, and split the work between hardware and software.
- Board bring-up: get the first boards running: clocks, power, debug connection, basic drivers.
- Drivers and application code: often in C, sometimes C++; in automotive, much of the control logic is designed in MATLAB and Simulink and turned into code automatically.
- Testing: unit tests on a PC, tests on the target hardware, and hardware-in-the-loop (HIL) rigs that simulate the rest of the system.
- Debugging: JTAG or SWD debuggers, logic analysers and oscilloscopes are everyday tools.
- Production and updates: programming at the factory, and secure update mechanisms for fixing bugs in the field.
Skills you need to become an embedded engineer
- Embedded C, including pointers, bit manipulation, volatile, memory layout and interrupt-safe code.
- Microcontroller architecture: registers, clocks, interrupts, DMA, timers and how to read a reference manual.
- Electronics basics: reading schematics, pull-ups, ADC resolution, noise and grounding.
- Communication protocols: UART, SPI, I²C and CAN at minimum.
- RTOS concepts: tasks, priorities, scheduling, synchronisation and their pitfalls.
- Debugging on hardware with a debugger, oscilloscope and logic analyser.
- For automotive roles: AUTOSAR, ISO 26262 awareness, MISRA C, and MATLAB/Simulink for model-based design.
Structured ways to build these at Skill-Lync:
- Fundamentals of Embedded Systems and Embedded Programming Essentials for the core.
- Introduction to Automotive Embedded Systems and AUTOSAR for the automotive stack.
- PG Program in Embedded Systems for EV Applications for an end-to-end program with projects.
Frequently asked questions
What is a simple example of an embedded system?
A digital thermostat: it reads a temperature sensor, compares it with the set point, switches a heater or compressor on or off, and shows the temperature on a small display. One job, running continuously, on a small microcontroller.
Is Python or C better for embedded systems?
C is still the main language for firmware, with C++ common in larger systems. Python is widely used around embedded work, for test automation, data analysis and tooling, and MicroPython is handy for prototyping. Rust is gaining attention for memory safety; MISRA has even published guidance assessing its guidelines against Rust. Learn C well first.
Why is it called "embedded"?
Because the computer is embedded inside the product it controls, rather than being a separate machine the user interacts with directly.
Is Arduino an embedded system?
An Arduino board is a microcontroller development board, and a project built on it is an embedded system. Arduino is excellent for learning; professional products usually move to custom boards, vendor toolchains and more rigorous software practices.
What is the difference between a microcontroller and a microprocessor?
A microcontroller integrates CPU, memory and peripherals on one chip and runs a single firmware image, often without an OS. A microprocessor relies on external memory and usually runs a full operating system such as Linux.
Is embedded systems a good career for ECE and EEE graduates?
Yes, especially in automotive, EV, industrial automation, consumer electronics and medical devices. Employers look for strong C fundamentals and evidence that you have built and debugged real hardware projects.
Sources and further reading
- MISRA, MISRA C:2025 and MISRA publications
- ISO, ISO 26262-1:2018 Road vehicles: Functional safety
- Wikipedia, Embedded system (history and software architectures)