When you think of embedded electronics, what traits define it? Here are a sample of definitions, taken from top results of search engines:
An embedded computer, which is an integral component of most embedded systems, is a combination of hardware and software that is designated to perform a highly specific function.
Embedded computing systems are made up of both hardware and software, and they are designed to perform one specific task.
Jonathan Valvano, University of Texas, Austin:
An embedded system is the combination of electrical, chemical, mechanical, optical, computer, software, all combined, for a dedicated purpose.
Wikipedia, as of this article's date:
An embedded system is a computer system—a combination of a computer processor, computer memory, and input/output peripheral devices—that has a dedicated function within a larger mechanical or electrical system.
To provide more flexibility, here are three definitions we'll use in this article. These aren't the only ones you could come up with, but they're a good start, and offer more precision than using a single definition. They're independent, but are frequently found together. We'll reference these throughout this article.
Computers with limited resources compared to the desktops, laptops, and tablets we're used to. This introduces new constraints, like managing a relatively low clock speed, or limited memory available for short and long-term storage. They might be expected to run on batteries, consuming as little power as practical.
For example, a modern microcontroller (MCU) might have 64 KB of Flash memory, 16 KB RAM, and operate with a clock speed of 72Mhz. How does this compare to your smart phone? Your laptop? The graphics card on your desktop?
When you use a laptop, the main input are keyboard, mouse, or touch screen, to let you send commands to it using your hands, and sometimes a microphone and webcam. The latter two may be used to record or transmit your voice and image to others; or, in some cases issue voice commands. It outputs info on a screen, or through speakers or headphones. All of these are aimed at direct interactions with users.
Embedded systems might share some of these input and output, and might do other things as well, like controlling motors, servos, light etc. This could manifest in factory and medical robots, self-driving cars, drones, spacecraft, pacemakers, or your dryer.
Your laptop and phone run complex, general-purpose operating systems (GPOS). These are compatible with number of programs, and run many at once. They have authentication and security systems, drivers for peripherals, (including ones that may not be connected), included critical and non-critical software, software management systems, configuration options etc. As a result, even computers with powerful hardware may not run smoothly, due to the large number of tasks they carry out. Even tasks that appear simple, like powering on and editing a document require many CPU cycles, and consume a deceptively high amount of memory.
An embedded system might run only one program, and take full advantage of the hardware available. Or run on a lightweight Real-Time Operating System(RTOS) that can manage multiple tasks, while providing guarantees about their performance in a given circumstance. Its behavior is (somewhat) deterministic: it's expected to perform tasks reliably under time constraints. It's definitely not going to shut your program down to perform a system update! In a more complex operating system like Windows or Linux, there are no such guarantees - a program might fail to run, run more slowly, or have a delay due to unrelated software running on the same device. The hardware itself may be designed with this constraint. For example, a real-time MCU might be designed to respond to interrupts in < 40 CPU cycles, while a larger, more varied tolerance, like 50-1,000 cycles is acceptable in other cases.
Hardware interrupt are another key feature: The ability to stop whatever the system is running to do a specific task when it receives a signal.
Let's revisit #1: Because of #3, embedded systems needn't be slow to respond - even if they have (comparably) slower components. Doing a simple task like booting up and writing text might be faster on a specially designed embedded device, since it avoids the complexities and conflicts of a GPOS, at the cost of flexibility.
You can imagine systems that fit into one, two, or all of these categories. Here are some examples:
A portable music player might fit into #1 and #3: Specialized hardware and software to maximize battery life, on a low-powered computer designed to minimize size and maximize battery life. Its interactions aren't a good fit for #2, since it interacts with the world through the same things a general-purpose computer does: Buttons, displays, and sound.
Flight computers on consumer drones fit into all 3: Battery life and weight are critical, so they fit #1. They interact with the world by actuating motors, and radio communications, so they fit #2 as well.
Using single board computers like Raspberry Pi is popular for home automation - for example, the Home Assistant project. These devices use signals to control devices like outlets, lights, thermostats, appliances, and security systems. They interact with the environment in many ways, which fit #2, but don't fit #1 or #3: They run a GPOS, and the hardware was designed without this specific use in mind.
A classic graphing calculator, like a TI-83 fits #1 due to its limited hardware capabilities. It doesn't fit #2. It partially fits #3: Its hardware and software were designed in conjunction, but it uses a general purpose MCU, and can run user-added programs that may have nothing to do with its main functions. Also note that main software may be more complicated compared to say, an alarm clock. It can add, subtract etc, display graphs, solve equations, and perform a range of simple and complex mathematical operations. General purpose MCUs are interesting in themselves. Modern ones like the STM32 or ATmega include many peripherals on-chip that have traditionally been separate: ADCs, DACs, op amps, pull-up resistors, Realtime clocks, oscillators etc. They're not manufactured for a specific purpose: This is determined by the user. Compared to designing or using specialized MCUs, or offboard components, this simplifies design and use. Richard Hamming describes the following advantages in The Art of Doing Science and Engineering:
- Other users of the chip will help find the errors, or other weaknesses, if there are any.
- Other users will help write the manuals needed to use it.
- Other users, including the manufacturer, will suggest upgrades of the chip, hence you can expect a steady stream of improved chips with little or no effort on your part.
- Inventory will not be a serious problem.
- Since, as I have been repeatedly said, technical progress is going on at an increasing rate, it follows technological obsolescence will be much more rapid in the future than it is now. You will hardly get a system installed and working before there are significant improvements which you can adapt by mere program changes If you have used general purpose chips and good programming methods rather than your special purpose chip which will almost certainly tie you down to your first design.
Look at the devices around you: What categories do they fit? Do you think these categories are appropriate? Examples to consider:
Embedded systems that fit #2 and #3 may be applied to safety critical situations unsuitable for a GPOS. Think self-driving cars, aircraft, spacecraft, or industrial robots. A malfunction in this realm could cause death, injury, or loss of expensive equipment. The system must be able to run deterministically, and response quickly. For example, a flight control computer in a fighter jet actuating control surfaces precisely to make an unstable plane do what the pilot wishes. Whether you've thought about this before or not, you can likely imagine a number of unpleasant behavior your computer or phone has done in the past that would be dangerous in this application!
Systems under definition #2 and #3 offer a powerful way to interact with the world. It expands the role of programmers programmers beyond changing content on a screen - it lets them have arbitrary interactions with the world. Programming and hardware form a powerful bond in these systems, that expand what programs can do. Using only definition #1 above, or the definitions from sources at the top of this article, it's easy to miss the beauty in this.
Single-board computers like the Raspberry Pi don't fit neatly into our categories. They're small, and physically look more like the circuit board for a microcontroller than a laptop computer. We looked at an example of them in a specific use above (home automation). They don't really fit #1 - they have much more RAM, and a faster CPU than most embedded MCUs. Depending on their use, they may or may not fit #2: Having a range of exposed GPIO pins, they can be used for arbitrary things - with or without an accompanying keyboard, mouse, and display. They might control a robot, fitting the definition, or be used as a server for home automation.
Real-time operating systems (RTOS) allow embedded systems that fit #1 and #3 to run multiple programs. (WIP)
Categories guide us, but only in some cases. In others, they fail to describe things well, and applying them naively can be misleading.
Picture a modern desktop computer. It normally runs a GPOS like Linux or Windows. No one would call it an embedded system. It's possible to write a program, for example, in C, that runs in place of the normal OS. It could interact with hardware by manipulating registers directly, and use other embedded programming techniques. Using our definitions above, it certainly wouldn't fit #1. It wouldn't fit #2 either: Its peripherals are the same as the desktop computer. It fits #3, since we've eschewed the complex OS, and can write a program that takes full advantage of the hardware.
What if we connect a peripheral that exposes a CAN bus, or GPIO header? A small hardware addition could make #2 fit.
Definition #1 is relative. How powerful must a computer be to not be embedded? How much memory?
What about supercomputers? Powerful machines composed from smaller computers that run specialty code, perhaps to compute a tedious differential equation with no analytic solution.
Like any category, Embedded systems helps us describe the world. When a job application lists embedded software engineer, it's clear the job description won't involve working with web pages. Likewise, one for frontend developer won't involve programming automotive robots. Is writing home automation software for a Raspberry Pi embedded? Maybe. Who cares? A modern STM32 is usually classified as embedded, but would the same definition fit for something with the same specs in the 80s?
In some cases, it's easy to delineate embedded systems from other computers. In others, it's not as clear. Our 3-definition approach provides more flexibility, but still has gray areas, and cases it's not appropriate for. The word embedded implies a part of a whole - an embedded system is one part of a larger device or system. This could mean a dedicated hardware circuit connected to a laptop, or the flight computer (or part of it!) on the space shuttle - one of many components working together to accomplish a goal.
