Introduction to Embedded Systems

An embedded system is a computer built into a product to perform a dedicated job. It may not look like a computer, but it still has a processor, memory, inputs, outputs, firmware, and timing constraints.

A washing machine controller, smart meter, insulin pump, airbag controller, thermostat, router, CNC machine, and motor drive are all embedded systems. Their users care about the product behavior, not the processor inside.

Learning Objectives

By the end of this lesson, you should be able to:

Define an embedded system in practical engineering terms.
Identify the input, processing, output, and feedback parts of an embedded product.
Explain real-time constraints and resource constraints.
Compare microcontrollers, application processors, and FPGAs at a high level.
Recognize safety, reliability, and lifecycle issues that make embedded development different from desktop software.

What Makes a System Embedded?

A general-purpose computer runs many unrelated applications chosen by the user. An embedded system is designed around a specific product function.

flowchart TD A[Embedded System] --> B[Dedicated Function] A --> C[Real-Time Behavior] A --> D[Resource Constraints] A --> E[Direct Hardware Control] A --> F[Product Reliability] B --> B1["One main job"] C --> C1["Response must meet deadlines"] D --> D1["Limited CPU, RAM, power, cost"] E --> E1["Sensors, actuators, buses, registers"] F --> F1["Runs unattended for years"]

Property	General-Purpose Computer	Embedded System
Purpose	Flexible, user-selected tasks	Dedicated product function
Software	Many installable applications	Firmware tied to hardware
Hardware access	Mostly through OS drivers	Often direct register and interrupt access
Resources	GB of RAM, GHz CPU, large storage	Bytes to MB of RAM, kHz to MHz or low GHz CPU
Timing	Usually best-effort	Often deadline-driven
Failure mode	App crash or reboot	Product malfunction, field return, or safety hazard

Anatomy of an Embedded System

Every embedded system follows a sense-decide-act loop.

flowchart TD subgraph Input ["Input"] S1[Temperature sensor] S2[Button or switch] S3[ADC input] S4[Communication packet] end subgraph Processing ["Processing"] CPU[CPU core] MEM[Flash and RAM] PER[Peripherals] FW[Firmware] end subgraph Output ["Output"] A1[LED or display] A2[Motor or relay] A3[DAC or PWM] A4[Communication reply] end Input --> Processing Processing --> Output Output --> Input

The input may be physical, such as a sensor voltage, or digital, such as a CAN frame. The output may control power hardware, communicate status, update a display, or store data.

Worked Example: Thermostat Controller

Consider a room thermostat.

Part	Thermostat Example
Inputs	Temperature sensor, buttons, schedule, door/window sensor
Processing	Microcontroller compares measured temperature with setpoint
Outputs	Relay or triac for heater, display, wireless status
Timing	Sample temperature every second; debounce buttons in milliseconds
Safety	Avoid rapid compressor cycling; detect sensor failure
Non-volatile data	Setpoint, calibration, schedule

A simple control rule might be:

if temperature < setpoint - hysteresis:
    turn heater on
if temperature > setpoint + hysteresis:
    turn heater off

The rule is simple, but the real product also needs sensor filtering, relay lifetime protection, power-fail recovery, watchdog handling, and safe behavior when the sensor is disconnected.

Real-Time Requirements

Real-time does not mean "fast." It means "correct within a deadline."

flowchart TD R[Real-Time Requirement] --> H[Hard Real-Time] R --> F[Firm Real-Time] R --> S[Soft Real-Time] H --> H1["Missed deadline is failure"] H --> H2["Airbag, pacemaker, motor protection"] F --> F1["Late result has no value"] F --> F2["Industrial inspection frame"] S --> S1["Late result reduces quality"] S --> S2["Display refresh, media buffering"]

Hard real-time systems require careful interrupt latency, scheduling, worst-case execution time analysis, and testing. A firmware loop that "usually works" is not enough when a missed deadline can damage equipment or harm a person.

Resource Constraints

Embedded systems are constrained because products are constrained.

Constraint	Why It Matters
RAM	Stack, heap, buffers, and global variables must fit reliably
Flash	Program code, constants, bootloader, and update images need space
CPU time	Control loops, communication, and UI compete for cycles
Power	Battery products may sleep most of the time
Cost	A few cents matter in high-volume products
Pins	Interfaces must fit the selected package
Environment	Temperature, vibration, EMI, moisture, and aging affect behavior

Embedded engineering is often the art of meeting product requirements with the smallest reliable hardware and the simplest maintainable firmware.

Common Processing Choices

flowchart LR A["8-bit MCU\nsmall sensors\nlow cost"] --> B["32-bit MCU\nmotor control\nIoT nodes"] --> C["Application Processor\nLinux HMI\nvision gateway"] --> D["FPGA\nparallel logic\nprecise timing"]

Device Type	Strength	Typical Use
8-bit MCU	Low cost, simple, low power	Basic control, small sensors
32-bit MCU	Good peripherals and performance	Motor control, industrial nodes, IoT
Application processor	Runs Linux and rich software stacks	HMI, gateways, camera systems
FPGA	Massive parallelism and deterministic timing	High-speed I/O, custom logic, signal processing

The right choice depends on timing, power, development cost, certification needs, available libraries, and production volume.

Embedded Development Stack

flowchart TD APP["Application logic"] HAL["HAL or board support package"] RTOS["Bare-metal loop or RTOS"] DRV["Peripheral drivers"] REG["Hardware registers"] HW["Microcontroller or SoC"] APP --> HAL APP --> RTOS HAL --> DRV RTOS --> DRV DRV --> REG REG --> HW

Unlike desktop applications, embedded firmware often controls hardware registers directly. A mistake may not produce a friendly exception; it may lock the bus, corrupt Flash, reset the watchdog, or drive an output at the wrong time.

Safety and Reliability Mindset

Even a non-life-critical embedded product should fail predictably.

Designers commonly use:

Watchdog timers to recover from software lockups.
Brown-out detection to avoid running at unsafe supply voltage.
CRC checks for stored settings and firmware images.
Input validation for communication packets.
Output defaults that are safe after reset.
Derating for voltage, current, temperature, and component lifetime.
Test points and logging hooks for field diagnosis.

For safety-critical products, follow the relevant standard and review process. Examples include IEC 61508 for functional safety, ISO 26262 for automotive, IEC 62304 for medical software, and DO-178C for avionics software.

Common Mistakes

Starting firmware before defining timing, power, and fault requirements.
Assuming the main loop is fast enough without measuring worst-case latency.
Ignoring stack size and interrupt nesting.
Using blocking delays in code that must service communication or control loops.
Treating noisy physical inputs as clean digital values.
Forgetting brown-out, watchdog, and reset behavior.
Building a prototype that works only on a bench supply and fails in the field.

Practice

Pick one product, such as a smart plug, water pump controller, digital weighing scale, or motorized valve. List:

Inputs.
Outputs.
Processor choice.
Memory needs.
Real-time deadlines.
Power constraints.
Safe state after reset.
One likely field failure and how firmware should detect it.

Summary

An embedded system is a dedicated computer inside a product. It senses the world, makes decisions, and controls outputs under limits of time, power, memory, cost, and reliability. Embedded development requires software skill, hardware awareness, and a disciplined approach to failure modes.

Mind Map

mindmap root((Embedded Systems)) Core Dedicated computer in a product Sense decide act loop Firmware tied to hardware Applications Appliances Automotive control Medical devices Industrial machines IoT nodes Constraints RAM and Flash limits CPU deadline limits Battery power Cost and pins Harsh environment Timing Hard real time deadlines Soft real time quality Interrupt latency Worst case execution time Design rules Define safe state Use watchdog and brownout Validate inputs Budget memory Measure latency Common mistakes Blocking delays everywhere No fault handling Stack not measured Bench-only testing