From Apollo to IoT
Every embedded systems course online eventually asks: where did all this come from? Understanding the history of embedded systems isn’t trivia — it explains why today’s tools look the way they do. The move from hand-wired logic to C, from bare-metal to RTOS, from RTOS to embedded Linux, and from isolated devices to cloud-connected IoT is a direct response to real engineering pressures at each stage. This lecture walks through six decades of that evolution.
What You Will Learn
1960s–1970s: The Hardwired Origins
Aerospace and Military First
The earliest embedded systems weren’t consumer products at all — they were built for aerospace and military applications where reliability mattered more than cost. Logic was frequently hardwired rather than software-driven, and there was no concept of a “firmware update” — once built, the behavior was permanent.
Landmark Example: The Apollo Guidance Computer
Flown on the Apollo missions, it used core-rope memory — software literally woven by hand into physical wire — and had less computing power than a modern calculator, yet it successfully guided spacecraft to the Moon. It’s the textbook example every embedded systems training program uses to show how far the field has come.
1980s: The Microcontroller Era
This decade fundamentally changed the field: integrating the CPU, memory, and I/O onto a single chip gave rise to the modern microcontroller.
| Development | Impact |
|---|---|
| Intel 8051, Microchip PIC families launched | Made single-chip embedded design commercially practical |
| Embedded C programming emerges | Firmware could finally be written and maintained faster than assembly |
| ROM-based firmware becomes standard | Software could be mass-produced and burned into chips reliably |
The habits formed here — small, efficient, register-close C code — still shape modern firmware development practices, even on today’s much more powerful chips.
1990s: Industrial Expansion
With cheap, reliable microcontrollers now available, embedded systems spread rapidly out of aerospace/military niches and into everyday industry:
This is also the decade where embedded systems training began to formalize into a distinct engineering discipline, separate from general computer science, with its own curricula around hardware interfacing and real-time constraints.
2000s: RTOS and Connectivity
As embedded applications grew more complex — multiple sensors, multiple timing-critical tasks running “simultaneously” — bare-metal superloops started to strain. This decade’s answer was the Real-Time Operating System (RTOS): a minimal, deterministic scheduler that manages multiple tasks while still honoring hard deadlines.
RTOS Task Scheduling
An RTOS assigns each task a priority and guarantees the highest-priority ready task always runs next, giving developers a structured way to meet multiple deadlines instead of hand-rolling one giant loop.
This decade also standardized connectivity: Ethernet, CAN bus, and USB became common in embedded designs, letting devices talk to each other and to the outside world in ways the earlier decades never could. RTOS concepts remain a core subject in every embedded software course today.
2010s–Present: IoT and Smart Devices
The most recent era is defined by three simultaneous shifts:
ARM Cortex Dominance
ARM Cortex-M (for MCU-class real-time work) and Cortex-A (for Linux-capable SoCs) became the de facto standard architecture across the industry, from wearables to industrial gateways.
Embedded Linux Goes Mainstream
Devices needing rich networking, file systems, and multi-process applications increasingly run embedded Linux instead of a bare RTOS — routers, smart TVs, and industrial gateways being prime examples.
Wireless Everywhere + OTA Updates
Wi-Fi and Bluetooth Low Energy (BLE) turned isolated devices into connected ones, and over-the-air (OTA) firmware updates finally broke the old “burn it once, it’s permanent” model from the 1960s–80s.
Modern embedded systems training now routinely includes Linux, networking, and security — topics that simply didn’t exist in the field’s early decades.
How Tooling Evolved Alongside Hardware
| Era | Dominant Programming Approach | Dominant OS Choice |
|---|---|---|
| 1960s-70s | Hardwired logic, hand-assembled code | None |
| 1980s | Assembly, early Embedded C | None (bare-metal) |
| 1990s | Embedded C, structured design | Bare-metal, early proprietary RTOS |
| 2000s | Embedded C/C++ | RTOS (VxWorks, QNX, early FreeRTOS) |
| 2010s-present | C/C++, some Rust; Python for tooling | RTOS + Embedded Linux side by side |
Common Beginner Mistakes
Assuming RTOS replaced bare-metal entirely
It didn’t — the majority of simple, cost-sensitive embedded products (a microwave keypad controller, a basic sensor node) are still built bare-metal today; RTOS is chosen when task complexity genuinely demands it.
Thinking embedded Linux replaced RTOS/bare-metal
These three approaches coexist today, each chosen based on the product’s real-time needs, resource budget, and connectivity requirements — not a strict timeline where the newest always wins.
Best Practices When Studying This History
- Map each era to the engineering problem it solved — that’s more useful than memorizing dates.
- Notice the recurring pattern: complexity grows → new tooling emerges to manage it → old approaches don’t disappear, they specialize.
- Connect the OTA update capability of modern IoT devices back to the security implications it introduces — a topic worth studying early.
Summary and Key Takeaways
- Embedded systems began as hardwired, single-purpose aerospace/military hardware with no update capability.
- The 1980s microcontroller era made single-chip, C-programmable embedded design mainstream.
- The 1990s spread embedded systems into automotive and industrial automation and formalized the discipline.
- The 2000s introduced RTOS scheduling and standard connectivity (Ethernet, CAN, USB).
- The 2010s onward brought ARM Cortex dominance, embedded Linux, wireless connectivity, and OTA updates — the IoT era.
Interview Questions on This Topic
Q1. What problem did the RTOS solve that bare-metal superloops couldn’t?
Managing multiple tasks with different priorities and deadlines running concurrently, while still providing deterministic, guaranteed scheduling — something a single hand-rolled loop struggles to scale to.
Q2. Why did ARM Cortex become so dominant in modern embedded design?
A unified architecture family spanning ultra-low-power Cortex-M microcontrollers to Linux-capable Cortex-A application processors let the industry standardize toolchains, compilers, and developer skills across a huge range of device classes.
Q3. What’s the practical difference between choosing bare-metal, RTOS, or embedded Linux for a new product?
Bare-metal suits simple, highly resource-constrained, single-purpose tasks; RTOS suits multi-task real-time products with moderate resources; embedded Linux suits products needing rich networking, file systems, or multiple concurrent applications, at the cost of higher resource requirements.
Q4. What security concern did OTA updates introduce that older embedded systems never had to consider?
A network-reachable update mechanism creates a new attack surface — if not cryptographically signed and verified, OTA updates can be hijacked to install malicious firmware remotely.
Frequently Asked Questions
Is the Apollo Guidance Computer really considered an embedded system?
Yes — it was dedicated hardware and software built for one purpose (spacecraft guidance and control), which is exactly the definition of an embedded system, even though the term wasn’t in common use yet.
Did assembly language disappear after the 1980s?
No — assembly is still used today for the most performance- or timing-critical routines, though the bulk of firmware has moved to C since the 1980s.
Why do some modern products still use bare-metal instead of embedded Linux?
Cost, power budget, and startup-time requirements often rule out Linux’s larger resource footprint, especially for simple, low-cost, always-on products.
What’s the next major shift expected in embedded systems?
Increasing on-device AI/ML inference (TinyML), tighter security requirements, and further convergence between RTOS and Linux environments are widely discussed as the field’s next direction.
Ready for Lecture 4?
Next: embedded systems in everyday life, firmware development in depth, and how to actually start a career in this field.
Continue to Lecture 4 Back to Course Index
2 Comments