A History of
Embedded Systems
Engineering

The Roots: Cybernetics, Feedback, and Wartime Control

The embedded computer did not appear from nowhere. It grew out of an urgent, concrete problem: during the Second World War, aircraft flew faster than the human eye and hand could follow, and the weapons trying to shoot them down could not compensate. Antiaircraft guns relied on human operators to predict where a plane would be by the time the shell arrived — a calculation that required estimating speed, trajectory, altitude, wind, and the projectile's own flight time, all in a matter of seconds. Humans were too slow and too inconsistent. The military needed a machine that could close the loop between observation and action faster than any person.

That is how Norbert Wiener, one of the 20th century's most unusual mathematicians, ended up at MIT during the war working on a problem that had nothing to do with his previous career. Wiener had earned his PhD from Harvard before the age of 20, studied under Bertrand Russell, contributed to stochastic processes and Brownian motion, and was known for the kind of restless intellectual range that made other academics nervous. He was assigned, under OSRD direction by Vannevar Bush, to design a mechanism to predict the future position of an enemy aircraft and aim a gun to meet it there. The radar would track the plane; a calculator would run the prediction; the gun would follow. Error between aim and position would feed back into the next correction.

The project was not, in the end, a technical success. The antiaircraft predictor was never deployed in a satisfying way. But what Wiener noticed while building it was more important than the device itself. The system he was designing — radar reading position, calculator predicting trajectory, gun adjusting aim, outcome feeding back to improve the next shot — had the same mathematical structure as a nervous system regulating a muscle, or a thermostat regulating a room, or a captain steering a ship by watching how far it has drifted from the intended course. The mechanism was universal.

In 1948, Wiener published those ideas as Cybernetics, and the word became the name for the field. The title was borrowed from the Greek kybernētēs — steersman — and the same root gives us the English word governor, both the political office and the mechanical device that holds an engine's speed steady. Wiener's argument was ambitious almost to the point of extravagance: the principles of control, communication, and feedback could describe machines, living organisms, and social systems in one unified framework. The book became a sensation well beyond engineering. But its engineering legacy was immediate and concrete: it gave the entire field of automatic control a theoretical foundation and a name.

Whirlwind: the first real-time computer

While Wiener was giving feedback theory its name, engineers at MIT's Servomechanisms Laboratory were building the first machine that put it to work in digital hardware. In 1944, the US Navy's Office of Naval Research commissioned a universal flight trainer that would simulate flight for bomber crews — not a fixed analogue of one specific aircraft, but a system that could be reconfigured for any plane. The key engineering constraint was that the computer had to respond to pilot inputs in real time, updating a simulated instrument panel continuously. A delay of even a second would destroy the illusion.

The project was led by Jay Forrester, a Nebraska farm boy who had built his first electrical system from old car parts in high school and had stayed at MIT after the war when he saw what computing could become. The initial design was analogue. By late 1945, Forrester had concluded that analogue was not feasible at the required speed and accuracy, and converted the project to digital — at a time when digital computers were essentially non-existent. By early 1946 the digital project was underway, with speed as its absolute priority.

The result, Whirlwind, ran at speeds no computer had yet achieved. In August 1953 it introduced core memory — a 32×32 array of 1,024 magnetic ferrite cores, addressing each by the intersection of two current pulses. The core memory was fast, reliable, non-volatile, and random-access in a way the earlier electrostatic storage was not. It became the basis for all computer memory until semiconductor RAM arrived in the 1970s. Whirlwind later became the computational core of SAGE — the Semi-Automatic Ground Environment — the Cold War's continent-spanning air defense network. Real-time computing had proved itself.

The transistor: the component that made it all possible

Underpinning all of this was a discovery made at Bell Labs on 16 December 1947. John Bardeen and Walter Brattain, working under William Shockley, demonstrated the first working transistor — a solid-state amplifier the size of a fingertip, with no moving parts, no heated filament, no vacuum to maintain. Computers in 1947 ran on vacuum tubes — hot, fragile, power-hungry glass bottles that burned out constantly. Whirlwind alone used 5,000 vacuum tubes and had a failure rate that required engineers to simply expect failures and design around them. The transistor promised to fix all three problems: it was smaller, cooler, and vastly more reliable.

It would take over a decade for that promise to fully materialise — transistors were expensive, and manufacturing them in large quantities without defects was genuinely hard. But the direction was set. Bardeen, Brattain, and Shockley shared the Nobel Prize in Physics in 1956. The semiconductor era had begun.

Apollo and the First Real Embedded Computer

On 25 May 1961, President Kennedy stood before Congress and committed the United States to landing a man on the Moon before the end of the decade. The engineers at MIT's Instrumentation Laboratory who received the contract to build the spacecraft's guidance system faced a problem no one had yet solved: they needed to put a real computer into a spacecraft.

Not a simulated one, not a remote one — a computer that would fly through 386,000 kilometres of space, operate continuously for up to twelve days, calculate orbital mechanics and lunar descent trajectories in real time, accept input from astronauts, respond to errors, and guide the spacecraft to a precision landing on a surface no human had visited. All while weighing under 32 kilograms and consuming under 55 watts. There was no room for mainframes, no connection to ground computers during critical phases, no opportunity to restart.

The Apollo Guidance Computer — the AGC — was, in every meaningful definition, the first embedded computer. Its design was driven entirely by the constraints of its environment and its job. It was not a general-purpose machine that happened to be on a spacecraft. It was designed around the requirements of one specific application in one specific environment, running continuously, with no reset button.

The hardware: silicon ICs enter the world

The hardware was led by Eldon C. Hall, an engineer at MIT's Instrumentation Lab. In 1959, Hall had met Jack Kilby, who was then considering integrated circuits for the Polaris missile guidance computer. Hall proposed them for Apollo. This was an extraordinary risk: in 1961, integrated circuits were new, expensive, largely unproven in high-reliability applications, and produced in tiny quantities. The Apollo program would have to trust them completely — if the ICs failed, the mission failed, and the crew died.

The Block I AGC, which flew the first unmanned test missions, used 4,100 ICs — every one of them a Fairchild three-input NOR gate. The refined Block II, which flew every crewed mission from Apollo 1 to Apollo 17, used 2,800 ICs in a more tightly engineered package. Apollo's demand for these components drove Fairchild Semiconductor's production lines so hard that the economics of IC manufacturing transformed: prices fell from roughly $1,000 per chip when the program began to around $3 per chip by the mid-1960s. The Apollo program did not merely use the integrated circuit industry — it created it as a mass-manufacturing enterprise.

Margaret Hamilton and the birth of software engineering

Margaret Hamilton joined MIT's Instrumentation Laboratory when the AGC project was already underway. She eventually led the Software Engineering Division — a team of up to 350 people at peak, working for 1,400 man-years to produce the flight software. There was no playbook. Nobody had written software for an embedded computer before, because no embedded computer had existed before. Hamilton and her team had to invent the discipline from scratch.

She coined the term "software engineering" while doing this work. It was not initially taken seriously — critics said she was inflating the importance of what was still seen as clerical work, the task of translating designs into instructions for a machine. Hamilton's argument was that software for a life-critical embedded system required exactly the rigour, methodology, and professional discipline that structural engineering required of bridges: formal specification, fault tolerance, tested resilience, and accountability. The joke stopped when Apollo succeeded.

The software she built was extraordinary even judged by modern standards. It implemented asynchronous multitasking with priority-driven scheduling — the operating system would preempt lower-priority tasks to ensure the most critical computations always completed in time. It had built-in fault detection and recovery. It could restart automatically if overloaded. The principle she designed it around — that software must degrade gracefully, not catastrophically — became a founding principle of embedded systems engineering.

The 1202 alarm: embedded software saves Apollo 11

The most dramatic proof came on 20 July 1969. The Eagle — Apollo 11's Lunar Module — was descending toward the Sea of Tranquility. At about 9,000 metres altitude, the DSKY flashed a 1202 alarm. The AGC had detected that it was being asked to do more work than it had time to complete. The rendezvous radar — which would be needed for docking after the landing — had been left active, feeding the computer a continuous stream of data it hadn't been asked for, consuming processing cycles that the descent guidance urgently needed.

The AGC responded exactly as Hamilton had designed it to: it identified the lower-priority tasks — the rendezvous radar processing — and dropped them, freeing cycles for the critical guidance computations. The alarm was a notification, not a failure. Mission Control guidance officer Steve Bales called "Go on that alarm." Armstrong took manual control for the final seconds, searching for a flat spot on the rocky terrain while monitoring altitude and velocity on the DSKY's five-digit displays. The Eagle landed with less than 30 seconds of fuel remaining.

The Microprocessor Changes Everything

Before 1971, building an embedded computer meant assembling custom logic from dozens of chips — a process that required specialist knowledge, large budgets, and months of development time. The Apollo Guidance Computer, for all its brilliance, was the product of a 350-person team working for years. After 1971, it became possible to build a computer from a single fingernail-sized chip and a handful of support components. The agent of this change was the microprocessor, and the agent of the microprocessor was a Japanese calculator company, an Intel engineer with a better idea, and a physicist who worked 70-hour weeks on what his company considered a side project.

The Busicom contract and Ted Hoff's insight

In 1969, Nippon Calculating Machine Corporation — better known by its brand name Busicom — approached Intel with a contract to design twelve custom chips for a printing calculator. The original plan was straightforward: twelve specialised chips, each hardwired to perform specific calculator functions. Intel engineer Ted Hoff looked at the plan and thought it was the wrong approach. Twelve chips was twelve times the design work, twelve times the manufacturing complexity, and would produce something that could only ever be a calculator.

Hoff proposed instead a set of four chips: a general-purpose 4-bit CPU, a ROM, a RAM, and an I/O shift register. The calculator's functions would be implemented in software, stored in the ROM. The hardware would be a general-purpose engine. The implication was radical: the same chip could be a calculator, a cash register, a traffic light controller, or the brain of an industrial machine. Intelligence became programmable rather than hardwired.

Federico Faggin and the silicon that made it real

Hoff's architecture was the insight. But in April 1970, Intel hired Federico Faggin, who had been working at Fairchild Semiconductor, where in 1968 he had invented silicon-gate MOS technology — a manufacturing process that could pack far more transistors into a chip than the older aluminium-gate methods permitted. Faggin was the person who actually made the 4004 physically exist, in a manic push that consumed most of 1970.

The project was badly understaffed. Faggin worked 70 to 80 hours a week on what Intel's management viewed as a customer job, not a strategic priority. Before taping out the final design, he added a personal mark: his initials, F.F., etched microscopically into the lower-right corner of the chip mask — visible only under an electron microscope, present on every Intel 4004 ever manufactured.

Chuck Peddle and the $25 chip that changed history

Intel's 4004 was followed by the 8-bit 8008 (1972) and the 8080 (1974). Motorola produced the 6800. All of these chips cost between $150 and $300 — serious money in 1975, enough to price out students, hobbyists, and small manufacturers. Chuck Peddle at Motorola believed a simpler, cheaper CPU would open vast new markets. Motorola's management was not interested in undercutting their own products. Peddle took seven engineers and left.

At MOS Technology, Peddle's team designed the 6502 — a simplified, less expensive version of the Motorola 6800 using depletion-load NMOS technology. In September 1975 they took it to the WESCON trade show and sold chips out of glass jars on a table, at $25 each, while Motorola's 6800 sold for $179. Many attendees assumed the price was a mistake and refused to believe it. It wasn't. The 6502 was faster than most of its competition, required fewer support components, and cost a fraction of the price.

The 6502 powered the Apple II, the Commodore 64, the BBC Micro, and the original Nintendo Entertainment System. It was the chip that put programmable silicon within reach of anyone who wanted it — and it was the chip that turned embedded systems from an aerospace specialty into a mass market.

The Microcontroller and the Factory Floor

While the aerospace and consumer electronics story of embedded systems unfolded in public — Apollo on television, microprocessors in electronics magazines — a parallel revolution was happening on the factory floor. Its roots go back three years before the Intel 4004, to 1968, to a man named Dick Morley and a problem General Motors needed to solve.

The PLC: embedded control for industry

Manufacturing in the 1960s ran on relay panels — banks of mechanical switches, contactors, and timing relays wired together to sequence the machinery on an assembly line. They were reliable and electricians understood them, but they were inflexible. When General Motors wanted to change the production sequence for a new car model, the cost was measured in weeks of downtime and hundreds of engineering hours of rewiring. Every model change meant a new panel, essentially from scratch.

In 1968, Morley's team at Bedford Associates produced the Modicon 084 — the company's 84th project. Modicon stood for Modular Digital Controller. It replaced relay logic with a programmable electronic device that stored control logic in software rather than wiring. The programming language, called ladder logic, was designed to look exactly like the relay circuit diagrams that electricians already knew — the same symbols, the same visual grammar, no learning curve. You could change the production sequence by modifying the program, not by pulling wire.

Intel 8051: the microcontroller that defined 40 years

The 8048 (1976) was Intel's first true microcontroller — a CPU, RAM, ROM, and I/O ports on a single chip. But its address-space limitations meant it was quickly outgrown. In 1980, Intel's John Wharton was assigned to fix this. By his own account, he sat down on a Friday after a lunch conversation with his manager and delivered the architecture of the 8051 by Monday morning.

That weekend design defined microcontroller architecture for over four decades. The MCS-51 instruction set — Harvard architecture, 8-bit data, 8K ROM, 256 bytes RAM, 32 I/O pins, two timers, a UART, and a dedicated Boolean processor for bit manipulation — hit exactly the right balance of capability and simplicity for embedded control. It was fast enough for real applications, simple enough to program in assembly, and cheap enough to put in anything. Derivatives of it are still being manufactured today.

Automotive: embedded systems enter the car

Bosch was the dominant force in embedding intelligence into the automobile. The ABS anti-lock braking system, introduced in 1978 with Mercedes-Benz on the W116 S-Class, put an embedded controller in charge of modulating brake pressure individually at each wheel during emergency braking — sensing wheel speed, detecting lockup, and reducing pressure in milliseconds to restore traction. This was the first time a computer was given direct authority over a car's fundamental safety systems. If the software failed, people could die. The design had to be correct.

The Motronic engine management system followed in 1979, using a Siemens-manufactured 8051 to manage fuel injection and ignition timing simultaneously from a single integrated unit. It was the first system that was necessary for the car to run at all — not an optional electronic enhancement but a core functional requirement. By 1988, Delco Electronics was producing 28,000 engine control units per day. The automobile had become a platform for embedded systems engineering.

Real-Time Operating Systems and When Software Kills

By the early 1980s embedded systems had spread from aerospace into hospitals, cars, factories, and consumer products. The engineering challenge had shifted: it was no longer whether you could build an embedded computer, but how you could build one that was guaranteed to behave correctly under all conditions — including conditions the designer had not anticipated. The answer required two things: a new class of software infrastructure, and a series of disasters that made the cost of getting it wrong impossible to ignore.

The real-time operating system

A general-purpose operating system like Unix was designed for interactive use. When the system is busy, your request waits. A half-second delay is invisible; a minute is inconvenient; a crash means you restart. An embedded OS governing a radiation therapy machine, an anti-lock brake controller, or a flight control surface operates under a completely different contract: every task has a deadline, missing a deadline is not a performance issue — it is a failure, and the failure may be lethal.

The first commercial RTOS was VRTX, released in September 1981 by Hunter & Ready, a company founded by James Ready and Colin Hunter the previous year. Ready, by his own account, essentially invented the commercial RTOS market. These systems did not sell on features — they sold on guarantees: provable worst-case response times, deterministic scheduling, priority inversion protection. Wind River's VxWorks followed in 1987. QNX, with its microkernel architecture, emerged in 1982. pSOS dominated Motorola 68k-based designs through the decade. Bosch's CAN bus protocol, published in 1986 and standardized as ISO 11898, gave embedded systems in vehicles a shared communication backbone.

Ada: a government forces software discipline

The US Department of Defense was managing a crisis it had largely created. By the mid-1970s it was running embedded computer projects in over 450 different programming languages — many of them obsolete, hardware-dependent, and none of them designed for safe, modular programming. A 1973 cost study found the DoD was spending $3 billion annually on software, much of it on embedded systems in a chaotic mix of proprietary dialects. A working group formed in 1975 to create a single, suitable language. The process — Strawman, Woodenman, Tinman, Ironman, Steelman — was a systematic narrowing of requirements over four years, evaluated against available languages. None of the existing languages passed the Steelman specification. The DoD commissioned a new one.

The result was Ada, named after Ada Lovelace. Standardized as MIL-STD-1815 in 1983 and mandated for all DoD embedded projects, Ada enforced discipline by design: strong static typing, mandatory exception handling, built-in concurrency constructs, range checks that threw errors instead of silently wrapping integers. By 1996 the total number of languages in use for DoD embedded projects had fallen from 450 to 37. Ada was not elegant to program in. It was rigorous. That was the point.

The Therac-25: when embedded software kills

The Therac-25 was a computer-controlled radiation therapy machine built by Atomic Energy of Canada Limited. Between 1985 and 1987 it delivered massive overdoses of radiation to at least six patients. Three died. The doses were up to 100 times the intended level — in the range of 10,000 to 20,000 rads, more than enough to kill.

The root cause was a race condition — a concurrency bug in the machine's control software written on a PDP-11. The Therac-25 had two operating modes: a low-power electron beam mode for treating shallow tissue, and a high-power X-ray mode for deep tissue. In X-ray mode, a metal target and a beam-spreading collimator had to rotate into position before the beam fired. This rotation took about 8 seconds. If an operator typed commands quickly enough — entering a mode selection, noticing an error, and correcting it within that 8-second window — the software's input handler and beam logic could race: the machine would configure itself for the corrected mode in its UI while actually firing in the previous, uncorrected mode, at full X-ray power, with no target and no collimator in place.

Nancy Leveson's 1993 IEEE Computer paper investigating the Therac-25 accidents became the founding document of embedded software safety engineering. The investigation revealed not just a race condition but a systematic set of failures: poor testing practices, no independent software review, opaque error messages that operators learned to dismiss, and a manufacturer who resisted any suggestion that the software was at fault for months after the first accidents. The lesson was as much organisational as technical.

ARM, RISC, and the Mobile Revolution

In 1983, a small British computer company called Acorn — based in Cambridge, building machines for schools under a BBC contract — needed a processor that didn't exist. The available options were too slow, too power-hungry, too expensive, or all three. Two engineers decided to design their own.

Sophie Wilson, Steve Furber, and Project A

Sophie Wilson designed the instruction set. She had been reading papers from the Berkeley RISC project — which showed that a processor with a small, uniform instruction set could outperform complex architectures by executing each instruction in a single clock cycle. She also visited the Western Design Centre in Phoenix, where the 6502 was being updated by a team of just a few people in a couple of bungalows. The visit was reassuring: you did not need a huge team or state-of-the-art facilities to design a competitive processor.

Wilson wrote the entire instruction set simulator in 808 lines of BBC BASIC, running on a BBC Micro — proof of concept before a single transistor had been laid out. The chip was named the Acorn RISC Machine, ARM. Steve Furber led the hardware architecture: a three-stage pipeline, a barrel shifter, 25,000 transistors in a 3-micron process. Ten people. Eighteen months.

The first ARM1 silicon arrived from VLSI Technology on 26 April 1985, at 3pm. They plugged it into a development board and it worked. Almost immediately. There was one minor bug, found after the celebrations. But the more memorable discovery came when Furber connected an ammeter to measure power consumption: the needle read zero. He investigated, and found that the development board itself had a fault — it was not delivering power to the chip's supply lines at all. The ARM1 was running entirely on leakage current from its own I/O signal lines. It was consuming so little power that the meter could not register it.

The low power consumption had been a side effect, not a design goal. Acorn's primary constraint was cost — cheap enough to package in plastic, which meant keeping thermal dissipation under one watt. But in 1985 that frugality looked like a footnote on a desktop coprocessor. A decade later, when the world wanted computers in pockets, ARM's accidental power efficiency became the most valuable property in computing.

ARM Ltd. and the licensing model

Apple was developing the Newton PDA in the late 1980s and needed a low-power processor. Acorn's ARM was the obvious candidate — but Acorn, struggling financially, could not supply it reliably at scale. In late 1990, Acorn, Apple, and VLSI Technology formed a joint venture: ARM Ltd., a new company that would own the architecture and license it to anyone who wanted to manufacture chips based on it. Robin Saxby, an ex-Motorola executive, became the first CEO and drove the strategy that defined ARM: design the architecture, never manufacture. Collect royalties from every chip that implements it. The model inverted the normal semiconductor business and proved to be extraordinarily effective. By 2018, 150 billion ARM processors had been shipped.

Ariane 5: what happens when safety discipline fails

On 4 June 1996, Ariane flight V88 — the maiden flight of the Ariane 5 rocket — ended 37 seconds after launch when the vehicle veered off its flight path and the range safety officer destroyed it. The cause was a software bug: a 64-bit floating-point number was converted to a 16-bit signed integer without adequate protection against overflow. The number was the horizontal velocity component, which on Ariane 5's faster trajectory produced a value outside the range a 16-bit integer can represent. The overflow raised an exception. The exception handling code, as specified, shut down the processor. The backup inertial reference system, running the same code and experiencing the same conditions, failed the same way, almost immediately afterward.

Connected Devices and the Birth of IoT

In 1999, a Procter & Gamble brand manager named Kevin Ashton was trying to solve an inventory problem. Lipstick kept going out of stock without the supply chain knowing about it. His proposed solution used RFID tags on individual products that would report their location automatically. To give the idea a memorable frame when presenting it to management, he called it the Internet of Things — physical objects connected to digital networks, reporting their state continuously. It was the first recorded use of the phrase. Ashton later co-founded the MIT Auto-ID Center with Sanjay Sarma and David Brock, drawing in roughly 100 companies and seven universities. His original vision was modest: smarter logistics. The phrase went much further.

The technical infrastructure for connected embedded devices came together in the late 1990s. Bluetooth 1.0 shipped in 1999. Wi-Fi's 802.11b standard — fast enough for practical consumer use — followed the same year. The combination meant that for the first time, embedded devices could connect wirelessly to networks without custom radio hardware. By the mid-2000s, connecting a device to the internet had become an engineering problem with a known solution rather than a research challenge.

The iPhone in 2007 redefined what an ARM-based embedded computer was understood to be, and what people expected from any connected device. It ran a full operating system — a derivative of macOS — on a chip that drew milliwatts. It set the experience expectation for every touchscreen, every app, every connected consumer product that followed. IoT was no longer a logistics concept. It was an expectation about how the world should work.

The Maker Movement Democratises Embedded

For most of its history, embedded systems engineering required specialist knowledge, expensive tools, and institutional access. Programming a microcontroller in 2003 meant reading dense datasheets, buying a hardware programmer, writing C or assembly, and understanding hardware at a level that took years to acquire. The boards that art and design students at the Interaction Design Institute Ivrea used cost $100 each. That was the barrier that one Colombian student's master's thesis began to demolish.

Wiring, Arduino, and the open-source microcontroller

In 2003, Hernando Barragán began work on a thesis project at IDII under supervisors Massimo Banzi and Casey Reas. His goal was to create a low-cost, easy-to-use platform so that non-engineers — artists, designers, students — could build physical interactive projects. The result was Wiring: a programming environment based on Processing's IDE, running on an ATmega microcontroller, with a library of simple functions that abstracted away the hardware complexity. You didn't need to know what a UART register was. You just called Serial.println().

In 2005, the Interaction Design Institute Ivrea was facing closure, merging with the Domus Academy. Massimo Banzi, along with David Mellis, David Cuartielles, Gianluca Martino, and Tom Igoe, took Wiring's environment and built a cheaper, simpler version based on the less expensive ATmega8 microcontroller. The platform was open-source under Creative Commons. They needed a name. Banzi named it after the bar where they regularly met: Bar di Re Arduino — King Arduino's Bar — itself named after Arduin of Ivrea, a medieval king who ruled from 1002 to 1004 before being deposed by Henry II. The first production run was 200 boards, assembled by hand by Martino.

Raspberry Pi: Linux on a $35 board

In Cambridge, Eben Upton had noticed a problem. CS applications to Cambridge had fallen from around 600 per year in 1999 to around 200 by 2008. Students were arriving without the programming background they'd had a decade earlier. Upton traced the change partly to the shift from 8-bit home computers — where teenagers could just type code — to locked-down games consoles and Windows PCs where the interface was a browser, not a prompt.

The Raspberry Pi Foundation was established with David Braben, Jack Lang, Pete Lomas, Rob Mullins, and Alan Mycroft. Upton had been prototyping since 2006. On 29 February 2012 — deliberately chosen as a leap-day birthday — the Raspberry Pi Model B went on sale. The target price was $35. 100,000 units sold on the first day, crashing the foundation's servers. Over 60 million have been sold since. Today roughly 40–50% of production goes to industrial and commercial customers rather than education, used in everything from industrial monitoring to point-of-sale terminals.

ESP8266: Wi-Fi for $3

In August 2014, a Chinese manufacturer called Ai-Thinker released a module built around a chip from Espressif Systems in Shanghai: the ESP8266. The chip had been in production since late 2013. It was a microcontroller with built-in Wi-Fi. It cost $3. The module appeared on English-language maker forums in August 2014 and spread explosively — the ability to connect any project to a network for three dollars was qualitatively different from anything that had existed before. Espressif released an official SDK in October 2014 and the chip became the basis for thousands of IoT products. The ESP32, released in September 2016, added Bluetooth and a dual-core processor. Espressif's later ESP32-C3 adopted the RISC-V open architecture.

Modern ESE: Safety, Security, AI at the Edge, and RISC-V

On 21 October 2016, large parts of the internet went dark. Twitter, Reddit, Netflix, GitHub, and the New York Times were unreachable for hours. The cause was a distributed denial-of-service attack against Dyn, a DNS provider that handled routing for many major services. The attack used tens of millions of IoT devices — home routers, IP cameras, digital video recorders — that had been recruited into a botnet called Mirai. Most of these devices were still running the factory-default username and password they had shipped with. Mirai's code brute-forced its way in using a list of 60 common default credentials. Peak attack traffic reached 1.2 terabits per second.

Mirai's source code had been published online on 30 September 2016, three weeks before the Dyn attack, by a user trying to establish plausible deniability. The code ran on embedded Linux, written in C. The devices it exploited were not running vulnerable software — they were running functional software that had never been secured. No one had changed the passwords. No one had designed the update mechanism. No one had assumed the device would be attacked.

RISC-V: an open architecture for an open future

In the summer of 2010, Krste Asanović at UC Berkeley needed an open-source CPU for a research project. Rather than use an existing open architecture — OpenRISC, OpenSPARC — he decided to design a new one in a three-month summer project with graduate students Yunsup Lee and Andrew Waterman. The resulting instruction set, RISC-V, was published openly. It was designed for implementation simplicity, modularity, and longevity — a base ISA that would not change, with optional extensions for specific applications.

RISC-V's public release in 2014 arrived at the right moment. ARM's licensing model was under growing scrutiny. The semiconductor industry's consolidation — Western Digital, SiFive, and others — wanted an architecture nobody owned. RISC-V International, the non-profit governing body, formed in 2015. By 2020, Espressif's ESP32-C3 became one of the first mass-market IoT chips to adopt RISC-V. The architecture is now used in Google's Titan M security chips, NVIDIA's GPU microcontrollers, and hundreds of startup SoC designs. The ARM–x86 duopoly that had defined embedded and desktop computing for forty years has a credible challenger that belongs to no one.

TinyML: intelligence at the edge

In 2019, Pete Warden — a founding member of TensorFlow's team at Google — and Daniel Situnayake published an O'Reilly book called TinyML: Machine Learning with TensorFlow Lite on Arduino and Ultra-Low-Power Microcontrollers. The book described a new engineering discipline: training neural networks on large servers, then compressing and deploying them onto microcontrollers drawing milliwatts. Google's voice assistant wake-word detector — the model that listens for "OK Google" — fits in 14 kilobytes and runs on a Cortex-M microcontroller at 250 kHz. The model that recognizes a face, classifies a sound, or detects a fall can run on a chip costing less than a dollar, without any internet connection, in real time.

How Embedded Systems Engineering Is Taught

For most of its history, embedded systems engineering was not taught at all — at least not as a named discipline. The people who built the Apollo Guidance Computer were mathematicians, electrical engineers, and a handful of people who had essentially invented their own jobs. The people who programmed the first Intel 4004-based products were hardware engineers who had learned to write assembly by necessity. There was no degree called embedded systems engineering. There was barely a consensus on what the field was.

The trajectory from "something people figured out on the job" to "a structured academic discipline with accredited degree programmes" took roughly forty years. It happened in stages, driven by industry demand, by the catastrophic cost of getting safety-critical software wrong, and by a growing consensus in engineering academia that neither computer science nor electrical engineering, taken alone, produced graduates equipped for the field.

The problem with the old model

Through the 1970s and 1980s, embedded engineers typically came from one of two backgrounds. Electrical engineers understood hardware — circuits, signal processing, power systems — but often had minimal exposure to software beyond simple control logic. Computer scientists understood software architecture and algorithms but had little experience with hardware constraints, real-time requirements, or the physical consequences of failure. The embedded systems engineer sat at the intersection, and the universities of the era mostly hadn't noticed that intersection existed.

The Therac-25 disaster and the Ariane 5 failure made the gap visible in the worst possible way. Both catastrophes involved software engineers who didn't fully understand the physical systems their code was controlling, and hardware designers who hadn't anticipated what software could get wrong. After Leveson's 1993 Therac-25 investigation and the Ariane 5 inquiry board's 1996 report, the argument for interdisciplinary embedded education became impossible to ignore.

The emergence of embedded systems courses

The first academic courses specifically labelled as embedded systems appeared at graduate level in leading US universities in the late 1990s. UC Berkeley's EE249 — Introduction to Embedded Systems — became one of the earliest and most influential, developed by Edward Lee and colleagues. Lee's framing was explicitly interdisciplinary: embedded systems were cyber-physical, meaning they were about the interaction between computation and physical processes, and understanding that interaction required knowledge that neither EE nor CS departments could provide alone. His textbook, co-authored with Sanjit Seshia, became a standard reference.

The natural path in leading US universities, as Berkeley's own course development reflected, was to start at graduate level — where researchers could develop and stabilise the teaching material — and then gradually move content into the undergraduate curriculum as it matured. By the early 2000s, undergraduate embedded systems modules were common in electrical engineering and computer engineering degrees. By the 2010s, standalone embedded systems engineering degree programmes had appeared at institutions across the US and Europe.

What the curriculum contains — and what it still struggles with

A 2005 ACM paper from Ohio University proposed a curriculum for a four-year ESE undergraduate programme built around sixteen knowledge areas: real-time systems, hardware/software co-design, digital signal processing, embedded software, computer architecture, operating systems, communications, safety and reliability, and several more. The paper explicitly used the IEEE-CS/ACM Computer Engineering Body of Knowledge as a reference — signalling that embedded systems engineering was now considered a peer discipline, not a subspecialty.

What the early curricula struggled to cover — and what still poses a challenge — is the relentless expansion of what an embedded systems engineer needs to know. A 2022 survey of embedded systems education noted that design challenges now span many more scientific areas than they did a few decades ago: security, machine learning at the edge, wireless protocol stacks, functional safety certification, and hardware-software co-verification have all become core competencies that weren't on the curriculum in 2005. Covering everything of something — deep dives into a small number of topics — risks producing graduates with gaps that industry immediately notices.

HAN and the European model

In the Netherlands and more broadly in Europe, the applied science university model — the hogeschool — offered a different approach to the problem. Where research universities tended to develop ESE as a graduate specialism built on top of computer engineering or electrical engineering undergraduate programmes, applied universities like HAN University of Applied Sciences built dedicated four-year bachelor's programmes in Embedded Systems Engineering from the ground up, with a project-driven, industry-oriented structure. Students spend substantial time on hands-on embedded projects from the first year, and the curriculum is shaped in direct dialogue with regional employers. The result is a graduate profile closely matched to what embedded systems roles in industry actually require — not the theoretical foundations first, practice later model of research universities, but an integrated approach where theory and practice develop together from the start.

Open Source Hardware and the Commons

When Federico Faggin designed the Intel 4004 in 1970, the tools he used — the layout editor, the design rule checker, the simulation environment — were proprietary, expensive, and available only to companies large enough to afford them. For the next three decades this remained true across the entire embedded systems toolchain: the EDA software to design a PCB, the RTOS to run on it, the compiler to build the firmware, the debugger to test it — all of it was either proprietary software sold by commercial vendors or tools that companies developed internally and kept private. Entry into professional embedded engineering required access to an institution that could afford these tools. The open-source movement changed this completely.

KiCad: open EDA from a French classroom

In 1992, Jean-Pierre Charras, an electronics professor at IUT de Grenoble in France, needed a way to teach his students PCB layout without spending money the department didn't have on commercial EDA licenses. He started writing his own tool. His motivation, as he later described it, was partly pedagogical and partly personal: he also wanted to learn C++. The result was KiCad — the name combining "Ki" (the first letters of a friend's company) with "Cad." It started as a solo project, remained one for years, and was slow to gain traction outside France.

The turning point came in 2013, when CERN's BE-CO-HT section — the electronics group responsible for beam control hardware — began contributing engineering resources to KiCad. CERN was building open hardware for its accelerators and needed an open EDA tool that matched the quality of commercial software. Their engineers added differential pair routing, track length control, and a host of professional-grade features. KiCad joined the Linux Foundation in 2019. Today it supports over 39 languages, runs on Windows, Linux, and macOS, and is used by professional engineers and students alike. The tool that started in a French classroom because commercial software was too expensive is now legitimately competitive with tools that cost thousands of dollars per seat.

OpenOCD, GDB, and the open debugging chain

Debugging embedded firmware on proprietary hardware required proprietary debug probes and proprietary software for most of the field's history. OpenOCD — Open On-Chip Debugger — changed this. Started in 2005 by Dominic Rath as a diploma thesis at the University of Applied Sciences Augsburg, OpenOCD provided an open-source implementation of the JTAG protocol, allowing any compatible debug probe to communicate with any compatible microcontroller through a standard interface. Combined with GDB — the GNU Debugger, part of the free software ecosystem since 1986 — OpenOCD gave embedded engineers a complete, free, cross-platform debugging chain. Most modern embedded development environments, including VS Code with the Cortex-Debug extension, use OpenOCD and GDB under the hood.

FreeRTOS: open real-time scheduling

FreeRTOS was created by Richard Barry in 2003. Where the commercial RTOS vendors of the 1980s and 1990s sold their systems for hundreds or thousands of dollars per unit — licensing structures that made sense for large-scale industrial deployments but excluded hobbyists, students, and small teams — FreeRTOS was released under a modified GPL licence that allowed use in commercial products without licensing fees, as long as the RTOS kernel source itself remained open. Amazon acquired FreeRTOS in 2017 and released it under the MIT licence, making it even more permissively available. Today FreeRTOS runs on over 40 hardware platforms and is the most widely deployed RTOS in the world by device count.

Zephyr RTOS: the Linux Foundation's answer

By the mid-2010s, embedded Linux was flourishing for higher-end systems — devices with enough RAM and flash to run a full OS — but there was no comparable vendor-neutral, open-source RTOS for constrained microcontrollers. The Linux Foundation recognised this gap. In 2014, Intel started an internal project codenamed "Rocket." In February 2016, the Linux Foundation publicly announced the Zephyr Project, with founding members Intel, Wind River, Synopsys, and NXP. Wind River contributed the kernel of its Rocket RTOS, itself descended from a proprietary OS called Virtuoso developed by Eonic Systems in the 1990s. Zephyr was released under the Apache 2.0 licence — permissive enough that companies could ship commercial products without open-sourcing their application code.

Zephyr has grown substantially. Today it supports over 750 board configurations, runs on ARM, RISC-V, Xtensa, x86, and other architectures, and has major contributions from Nordic Semiconductor (which alone contributes roughly 25% of upstream code), STMicroelectronics, NXP, and Meta. It is increasingly described as "Linux for microcontrollers" — meaning it brings the same open, collaborative development model that made Linux dominant on servers to the world of constrained embedded devices.

RISC-V: the open instruction set

The most fundamental element of embedded hardware — the instruction set architecture, the definition of what a CPU can do and how software talks to it — was, for the field's entire history, proprietary. ARM charged licensing fees. x86 was Intel's. MIPS, PowerPC, SuperH — all owned by someone. RISC-V, published by UC Berkeley in 2014, was the first open ISA to achieve serious industrial traction. By 2023, over 60 billion RISC-V cores had been shipped. The EU Chips Act explicitly promotes RISC-V for strategic independence. RISC-V International, the non-profit governing body, counts hundreds of member organisations including Google, NVIDIA, Qualcomm, and Samsung. An instruction set owned by no one — and therefore freely implementable by anyone — had arrived.

What Comes Next: Beyond Silicon, Beyond Moore

Gordon Moore's 1965 observation — that the number of transistors on an integrated circuit doubles roughly every two years — governed the semiconductor industry for sixty years. It was not a law of physics. It was a prediction about engineering ambition and economic incentive, and for six decades it proved accurate enough to plan a global industry around. Transistors shrank from 10 micrometres in 1971 to 2 nanometres in 2024. The Intel 4004 had 2,300 transistors. A modern Apple M3 chip has 25 billion. But the physical limits of silicon are now measurable in numbers of atoms, and the engineering cost of each new process node has become so extreme that only three companies on earth — TSMC, Samsung, and Intel Foundry — can manufacture at the leading edge. Moore's Law has not ended, but it has become something different: slower, more expensive, and available only to those with billions of dollars to invest in a single fabrication facility.

For embedded systems engineering, the implications are significant. The assumption that next year's chip will be faster, smaller, and cheaper than this year's has driven product roadmaps and architecture decisions for five decades. As that assumption weakens, the field must find other ways to improve performance and reduce power — and several credible paths are emerging.

Neuromorphic computing: Steve Furber's second act

After leaving Acorn in 1990 to join the University of Manchester as ICL Professor of Computer Engineering, Steve Furber — co-designer of the ARM processor — spent thirty years on a completely different problem: how do you build a computer that works like a brain? Biological neurons don't process data in clock cycles. They communicate asynchronously, via discrete electrical spikes, consuming power only when active. A human brain runs on roughly 20 watts and performs tasks no conventional computer approaches at any power level.

Furber's answer was SpiNNaker — the Spiking Neural Network Architecture. The project was 20 years in conception and 12 years in construction, beginning in 2006 with £15 million from the UK's Engineering and Physical Sciences Research Council. When it was switched on in November 2018, SpiNNaker contained one million ARM968E-S processors — each identical to the kind used in mobile phones — arranged in a massively parallel mesh network, communicating via spikes rather than clocked data transfers. The machine can model spiking neural networks at the scale of a mouse brain in biological real time. SpiNNaker 2, under development at TU Dresden, extends the architecture to ten million cores.

The relevance for embedded systems is not that we'll soon have SpiNNaker-scale machines in products. It's that the principles neuromorphic computing demonstrates — event-driven processing, asynchronous communication, power consumption proportional to activity rather than clock speed — are influencing the design of ultra-low-power embedded chips. Intel's Loihi, IBM's NorthPole, and startups like BrainChip are all exploring neuromorphic-inspired architectures for edge AI inference, aiming for the same efficiency that biological neurons achieve.

Photonic computing: light instead of electrons

Electronic computing moves data by pushing electrons through conductors. Electrons have mass, generate heat, and can only move so fast before the resistance and capacitance of the wire become the limiting factor. Photons have no mass, generate essentially no heat in transit, and travel at the speed of light. Photonic computing — processing information using light — has been a research goal since the 1980s, but has faced fundamental challenges: while light is fast for communication, making it perform computation (not just transmission) requires non-linear optical effects that are difficult to engineer at chip scale.

The picture is changing. Companies like Lightmatter are building photonic co-processors for AI inference workloads, where the matrix-multiplication operations that dominate neural network computation map elegantly onto optical interference patterns. CERN's photonic research has produced chips that perform multiply-accumulate operations in the optical domain. The most realistic near-term application is photonic interconnects — replacing the copper wires that move data between chips with optical fibres etched onto silicon, dramatically reducing the energy cost of data movement, which now dominates the power budget of large chips.

Quantum-resistant cryptography: securing embedded devices for the post-quantum era

Most public-key cryptography currently used to secure embedded devices — TLS for HTTPS, the RSA and ECDSA algorithms used in device certificates and firmware signing — rests on mathematical problems that a sufficiently powerful quantum computer could solve efficiently. Shor's algorithm, published in 1994, provides a quantum algorithm for factoring large integers and computing discrete logarithms in polynomial time; these are exactly the hard problems that RSA and elliptic-curve cryptography rely on. A quantum computer powerful enough to run Shor's algorithm at useful scale does not yet exist, but the cryptographic community is not waiting for it to appear.

In 2024, NIST finalised the first set of post-quantum cryptographic standards: ML-KEM (based on the CRYSTALS-Kyber algorithm) for key encapsulation, and ML-DSA (CRYSTALS-Dilithium) and SLH-DSA for digital signatures. These algorithms are designed to be secure against both quantum and classical computers. The challenge for embedded systems is significant: post-quantum algorithms are computationally heavier than their classical equivalents, requiring more RAM, more flash, and more processing cycles. Implementing ML-KEM on a Cortex-M4 is feasible. Implementing it on a Cortex-M0 with 8KB of RAM requires careful optimisation. The embedded community has five to fifteen years — estimates vary — before the quantum threat is real, but updating billions of deployed devices is not something that can be done quickly. The work has to start now.

The end of Moore's Law as an engineering constraint

For an embedded systems engineer, the practical consequences of Moore's Law slowing are already visible. The chip shortage of 2020–2022 — when a shortage of mature-node (28nm, 40nm) microcontrollers shut down automotive production lines globally — revealed that the industry's assumption of abundant, cheap silicon was fragile. The most useful embedded microcontrollers are not built on the leading-edge processes that get the headlines; they run on process nodes that are ten to twenty years old, which are profitable enough to run but not glamorous enough to receive new investment. When pandemic-related demand disruptions hit those fabs, the entire embedded supply chain froze.

The response has been a recognition that domain-specific architectures — chips designed for one class of workload rather than general-purpose computation — extract more value from each transistor by tailoring the hardware to the software it runs. Google's TPU, Apple's Neural Engine, and the proliferation of AI accelerators in embedded SoCs are all examples of this approach applied to machine learning inference. The same principle applies more broadly: rather than waiting for a faster general-purpose core, design the hardware around the specific constraints and workloads of your application.

Sources

All sources consulted during research for this book are listed below, organised by chapter. Web sources were accessed between September 2026 and the date of publication. Where a source supports multiple chapters it is listed under its primary chapter.

Chapter 1 — Cybernetics, Feedback, and Wartime Control

Chapter 2 — Apollo and the First Real Embedded Computer

Chapter 3 — The Microprocessor Changes Everything

Chapter 4 — The Microcontroller and the Factory Floor

Chapter 5 — Real-Time Operating Systems and When Software Kills

Chapter 6 — ARM, RISC, and the Mobile Revolution

Chapter 7 — Connected Devices and the Birth of IoT

Chapter 8 — The Maker Movement

Chapter 9 — Modern ESE: Safety, Security, AI at the Edge

Chapter 10 — How ESE Is Taught

Chapter 11 — Open Source Hardware and the Commons

Chapter 12 — What Comes Next

General references used across multiple chapters