Embedded Systems

⏱ 8 min✏️ Quiz at the end

The Computers You Never See

Count the computers in your home. Laptop, phone, tablet… five? Ten? Try again: the washing machine has one. The microwave, the TV, the router, the thermostat, the dishwasher, the game controller, possibly the toothbrush. A modern car carries dozens. The overwhelming majority of the world's computers are not on desks — they are embedded systems: computers built inside other machines to control them.

An embedded system is still a real computer — a processor, memory, and a program — but with a defining difference: it is dedicated to one job. Your laptop is general-purpose, running whatever you install. The washing machine's computer runs the washing machine. Forever. That's the deal.

Anatomy: Sense, Decide, Act

Nearly every embedded system is the same pattern — the input → process → output loop, running continuously for the life of the device:

  • Sensors (inputs): temperature probes, buttons, water-level floats, accelerometers, light sensors
  • Controller (process): a small processor running the control program — reading sensors, applying conditions, deciding
  • Actuators (outputs): motors, valves, heaters, lights, buzzers, displays

A washing machine, in pseudocode:

WHILE cycle not finished
    read water level, temperature, door sensor
    IF door open THEN pause and alert
    IF water below target THEN open valve ELSE close valve
    IF temperature below target THEN heater on ELSE heater off
    run drum according to programme step
ENDWHILE

Everything you have learned applies unchanged — loops, selection, Boolean logic, events (the door opening is an event). The venue is just a drum full of socks instead of a screen.

Engineering Under Constraints

Embedded design is a masterclass in trade-offs, because the constraints are brutal:

  • Cost — a processor in a £40 kettle must cost pennies. Millions of units multiply every penny saved.
  • Power — a fitness tracker must live days on a battery smaller than a coin; a laptop-class chip would die in minutes. Low-power processors and sleep modes rule.
  • Size and toughness — the computer must fit in a toothbrush handle, or survive a car engine bay's heat and vibration for fifteen years.
  • Memory — kilobytes, sometimes, not gigabytes. Code must be lean; there is no room for waste.

So while your phone's processor sprints, the microwave's ambles — and that is correct engineering. Matching the machine to the job, rather than maximising specs, is the discipline.

Reliability towers above all. A frozen laptop gets rebooted with a sigh. A frozen anti-lock-brake controller is a catastrophe. Many embedded systems carry real-time requirements: respond within a guaranteed deadline, every time — an airbag controller has about 15 milliseconds from crash detection to inflation, and "usually fast enough" is not a passing grade. This is why embedded software is tested to standards most app developers never meet, and why updating it is so careful: a device with no screen, half-updated when power fails, can be permanently dead ("bricked"). Update mechanisms must be failure-proof by design.

The Internet of Things

The newest chapter: embedded systems that talk. Give the thermostat Wi-Fi and it becomes "smart" — adjustable from your phone, aware of the weather forecast. Connected embedded devices are called the Internet of Things (IoT): smart bulbs, doorbell cameras, irrigation controllers, industrial sensors by the billion.

Connection cuts both ways. A thermostat you can reach over the internet is a thermostat someone else might reach too — and cheap devices with never-updated software are famously soft targets. IoT security (default passwords, missing encryption) is one of computing's live problems, and knowing that is part of buying and owning these devices wisely.

Try It Yourself

Pick a device at home with a hidden computer — kettle with temperature display, microwave, bike light with modes. List its sensors, its actuators, and write pseudocode for its control loop. Then the design question: what should it do if a sensor fails — and does the real device seem to have an answer?

Worked Example — Designing a Smart Doorbell's Firmware

Trace through the pseudocode for a smart video doorbell, another embedded system built entirely from ideas already covered in this course:

WHILE device is powered on
    IF motion sensor triggers THEN
        capture a short video clip
        IF battery level < 10% THEN
            send low-battery alert instead of video
        ELSE
            send video alert to owner's phone over Wi-Fi
        ENDIF
    ENDIF
    IF doorbell button pressed THEN
        play a chime sound
        send "someone's at the door" alert
    ENDIF
ENDWHILE

This is the same sense-decide-act loop from earlier in the lesson, but notice the nested condition checking battery level before deciding what to send — a small design decision with a real consequence: without it, a nearly-dead doorbell would keep trying to send power-hungry video and might die completely, silently, right when someone is at the door. This is exactly the kind of edge case testing programs exists to catch: what happens at the boundary (battery almost empty) matters as much as what happens in the ordinary case.

Why Embedded Failures Are Handled Differently

A crashed phone app is an inconvenience — restart it. A crashed pacemaker, insulin pump, or car braking controller is not a "restart and try again" situation; there may be no time, and no way, to recover. This is why safety-critical embedded systems are often built with deliberate redundancy: two independent processors running the same calculation and comparing answers, or a simple hardware backup circuit that can act even if the main software fails completely. It is the embedded-world equivalent of the redundancy principle behind backups and 3-2-1 storage — never trust a single point of failure when the cost of failure is severe, whether that single point is a hard drive, a network cable, or a single unchecked processor.

Key Words

  • Embedded system — a computer built into a device, dedicated to controlling it
  • Sensor / actuator — the inputs it measures with / the outputs it acts through
  • Real-time — required to respond within a guaranteed deadline
  • Firmware — the control software living permanently in the device
  • Internet of Things (IoT) — embedded systems connected to the internet
Related Topics