Category: Core Concepts

Many embedded systems must react or respond to events in a well defined, limited amount of time. We call these real-time computing systems. While efficient code design is always important, most computer programs do not face real-time constraints. For most applications, the exact execution time does not define success or failure as long as the program generates the expected results. If a block of code executes in X milliseconds or Y milliseconds, as long as the code provides the correct output. For example, most users don’t care if a disc drive system responds to a read request in 0.5 milliseconds or 0.55 milliseconds, as long as the program returns the correct data. Similarly, if your embedded system is monitoring the temperature of a cooler and turning on and off a refrigeration system to maintain temperature, it probably doesn’t matter if the control system checks the temperature every 5 seconds or every 10 seconds.

In contrast, for real-time computing systems, timing is everything. Real-time computing systems have well-defined time constraints for the time that can pass before they respond to an event. If the program cannot meet the timing constraints, the system will not function properly. Looking back at our disc drive example, while the exact time required to retrieve data varies, the servo loop that controls the head location is a real-time system. The head position control algorithm is designed to run at a specific interval. During time interval the software must read the head position, calculate an error, and then calculate a control output to adjust the head position. If these calculations are not complete before the end of the interval, the control system will fail. Similarly, if the ignition control in a car engine does not fire at the correct instant in the compression cycle, the car’s engine could be severely damaged.

In each of these real-time examples, the computer system must respond to event. For the servo control example, the event is the expiration of a timer. For the engine control example, the event might be a sensor detecting piston position in its stroke. In each case, the real-time constraints start with a trigger. The maximum time allowed for a computer system response is the deadline.

Wikipedia describes three categories for real-time systems:

• • Hard – missing a deadline is a total system failure.
  • Firm – infrequent deadline misses are tolerable, but may degrade the system’s quality of service. The usefulness of a result is zero after its deadline.
  • Soft – the usefulness of a result degrades after its deadline, thereby degrading the system’s quality of service.

For the purposes of the projects discussed on this site, we will use the hard deadline real-time system definition.

Note that real-time programming does not simply mean maximizing program throughput.  The event trigger and response deadline mark the beginning and end of a time constraint that is defined by an external system and measured in clock time.

These concepts are closely related to the concept of Event Driven – Asynchronous Programming, and I encourage you to read that post.

Let’s dive a little deeper into the components that make up an embedded system. The Introduction To Embedded Systems post gave a broad definition of an embedded system, along with some real-world examples. All embedded systems have hardware components and firmware. Rarely, for larger embedded systems, there may also be a software component. While technically firmware is software, for this post and the posts on this site, we will distinguish between firmware and software.

Hardware

The CPU or micro-controller in any embedded system provides the foundation for the entire design. The selection must satisfy all the design requirements listed in the Introduction. There are literally thousands of options for CPUs. Designers typically pay close attention to new offerings from chip manufacturers. 

The application may require additional peripherals beyond the CPU. The designer will select other devices that fit within the overall design plan and support communications compatible with the CPU. Instruments exist to measure or sense almost anything. It is up to the designer to identify the right device and create the circuit for their application.

Firmware

Firmware is a hardware-specific program that is closely coupled to the hardware and essential for proper operation of the system.  It is stored on the hardware portion of the system and is loaded when the system is powered on.  The firmware programs must be compiled (translated) into chip level instructions (machine code) that is specific to the hardware platform.  Because we are talking about compact systems optimized for a specific application, the firmware typically only contains the logic required to complete the required task.  Optimizing the firmware to the minimum required functionality can pay dividends by minimizing the memory used.

Software

As I mentioned above, the firmware is software designed specifically to manipulate the hardware of the embedded system.   For most embedded systems, the firmware is the only software.  A few larger embedded systems use general-purpose programs to complete their task. Obviously, any program that runs on a CPU or micro-controller must run in chip-specific instructions at its base level. On this site, we will differentiate Software as a program written without platform-specific hardware knowledge.

Putting It All Together
Now that we understand each of the components of an embedded system let’s look at how they fit together.  The diagram below shows a pictorial representation of all these pieces and how they fit together.  The hardware provides the foundation, the firmware acts as an interface to the hardware, and software sits on top of the firmware.

Let’s be honest, for most, the phrase Embedded System does not elicit much excitement…which is unfortunate. This somewhat sterile term is used to describe a broad category of computer applications that are an integral part of our everyday lives. For me, embedded systems represent some of the most exciting computer engineering applications where the proverbial computing ‘rubber’ hits the real-world ‘road.’

There are many unofficial definitions of embedded systems but most boil down to some version of the following:

A computer system that is optimized to perform a finite set of specific tasks.

It is worth pointing out that this definition is focused on the functional purpose of a computer system. It does not include any reference to the system size, number of components, or end product. Also, this definition does not include small single-board computers like Raspberry Pi and PC104. Both are powerful general-purpose, stand-alone computers capable of performing many tasks but not optimized for a set of specific tasks.

So why are embedded systems so important? As I mentioned above, embedded systems are where the rubber hits the road. These are the computer systems that operate in the world beyond a personal workstation, laptop, or gaming console. Embedded Systems are also where the vast majority of the small CPUs and micro-controllers are used. According to this Wikipedia article, 98% of all micro-controllers are part of embedded systems.

Wikipedia contains an overview and history of embedded systems here. I always find formal definitions of limited value and prefer to teach using examples. Some examples of embedded systems we encounter every day are:

Automobiles
Thermostats
Refrigerators
Digital Clocks
Digital Cameras
Computer Disk Drives

Computer Modems
Electronic Toys
Personal Music Players
DVD Players
Televisions

The list is nearly endless.

Now that we’ve established what defines an embedded system lets dive into the components of an embedded system and some of the challenges faced when designing them.