Embedded Systems Overview
Introduction
An embedded system is a computer built into a larger product to perform a specific job: brake control in a car, a thermostat, a robot joint controller, or the firmware in a smart sensor. Unlike a laptop, you do not usually install apps or browse the web on it — the software is tailored to the device and often runs for years without user upgrades.
As an embedded engineer you work at the intersection of hardware, firmware, and often connectivity. This article explains what makes embedded systems special, how they relate to general-purpose computers, and where to go next in this knowledge base.
Defining characteristics
Dedicated function
An embedded system is designed for one primary task (or a small, fixed set of tasks). A dishwasher controller washes dishes; it is not expected to run spreadsheets. Requirements drive every design choice: which MCU, how much RAM, whether Wi-Fi is worth the power cost.
Limited and fixed resources
Memory, CPU speed, and storage are bounded and usually not user-upgradeable. You cannot assume 16 GB RAM — you count bytes and cycles. This constraint shapes algorithms (no giant in-memory caches), language choice (C over Python on small MCUs), and architecture (streaming vs buffering).
Different user interface
The UI may be minimal: LEDs, a small display, a mobile app talking over Bluetooth, or no UI at all (factory sensor node). Interaction is often through physical I/O rather than a desktop environment.
Same underlying principles
Despite differences, embedded systems still have:
- A CPU executing instructions from memory
- I/O to the real world
- Software often written in high-level languages (especially C) compiled to machine code
See Introduction to computer systems.
Embedded in the product lifecycle
Embedded work does not stop at "it compiles." You validate timing, power, environmental limits, and long-term reliability. Documentation (wiring diagrams, BOM, requirements traceability) is part of delivery — see Documenting your design.
Typical building blocks
| Block | Role | Examples |
|---|---|---|
| MCU / SoC | Compute | ARM Cortex-M, AVR, RISC-V |
| Sensors | Measure environment | Temperature, distance, current |
| Actuators | Affect environment | Motor, relay, valve |
| Communication | Link to other systems | UART, CAN, Ethernet, Wi-Fi |
| Power | Supply and regulation | Battery, LDO, DC–DC |
| Firmware | Behaviour | RTOS or bare-metal C |
Electronics fundamentals: Basics of electronics.
System structure: Hardware architecture.
Real-time behaviour
Many embedded systems must react within deadlines (motor control, safety interlocks, audio). Real-time is not "fast" — it is predictable. See Real-time systems and Operating systems (RTOS section).
Industrial and consumer examples
| Domain | Example | Notes |
|---|---|---|
| Consumer | Washing machine, TV remote | Cost-sensitive, high volume |
| Automotive | ECU, ABS | Safety, standards (ISO 26262) |
| Industrial | PLC, DCS | Harsh environment, fieldbuses — PLCs and industrial control |
| Medical | Infusion pump | Certification, fail-safe design |
| IoT | Environmental sensor | Connectivity, low power |
Relevant topics
- Introduction to computer systems
- Real-time systems
- Compilers and toolchains
- Computer architecture
- System architecture
- Embedded systems (Wikipedia)
Starting points
- List embedded devices you use daily — identify sensor, actuator, and "computer" in each.
- Compare a general-purpose PC spec sheet to your development board — RAM, storage, OS.
- Read one product teardown article (iFixit, blog) — note MCU and peripherals.
- Define whether your current project is hard, firm, or soft real-time.
Focus points
- Embedded ≠ weak — modern MCUs are powerful; constraints are about purpose and resources.
- Dedicated function simplifies testing but freezes requirements early — document assumptions.
- Resource limits are architectural inputs, not afterthoughts.
- Safety and reliability requirements can dominate consumer-style feature lists.
Key points
- Embedded systems have a specific task, limited resources, and often a minimal UI.
- They use the same CPU/memory/I/O model as general-purpose computers.
- Real-time, industrial, and IoT are common contexts with extra constraints.
- Profile practical skills live in Designing & Realising; this section builds the theory underneath.