Firmware, system software (also called embedded software), middleware and application software work collaboratively and perform specific functions in embedded systems. Firmware, system software, and middleware are generally preloaded in an MCU. Applications software may be preloaded but is often added after the system has been built.

This FAQ reviews the functions and interactions between firmware, system software, middleware, and application software and closes with a review of software development and integration into an MCU.

Firmware provides the lowest level of control. It’s “firm” because it’s infrequently updated or changed. It controls the startup of the MCU and enables the various MCU elements to work together. Its primary function is to boot a device and control the hardware peripherals. Firmware can also be used to check all the hardware components and ensure they operate properly using a power-on-self-test (POST) procedure.

It operates without going through application programming interfaces (APIs), the operating system, or device drivers. Firmware, such as the BIOS of a personal computer, includes the basic functions of a device and may provide higher-level software like an operating system (OS) with hardware abstraction services. No complex OS is needed for simple embedded devices and the firmware substitutes for an OS.

Firmware is a series of machine-language instructions. It may initially be written in a higher-level language, but it must be translated into machine language before being loaded into an MCU. Firmware is specific to an MCU or family of MCUs.

Embedded software

Firmware and embedded software are sometimes confused and even commingled as ‘embedded firmware,’ but they are not the same. Embedded software performs higher-level functions on an MCU, like an OS on a computer. Like firmware, embedded software is usually specific to an MCU or family of MCUs. That contrasts with an OS that is more generic and designed for use across numerous microprocessors.

Like firmware, embedded software comes preinstalled. Applications software may be user installed or preinstalled in the system. When the system starts up, the embedded software is loaded immediately following the boot-up using the firmware. The embedded software controls the device. The embedded software supports most or all system functionality in some embedded systems.

Embedded software and firmware complement each other (Figure 1). They are the primary, often the only, software in a range of embedded devices like motion detection in security cameras, traffic light control systems, home automation devices, some automotive electronic control units (ECUs), and so on. In the simplest devices, there’s only firmware and no need for embedded software.

What’s next in the hierarchy?

An OS like Linux or FreeRTOS is needed in more complex embedded systems to manage the MCU’s hardware resources, including input/output (I/O) devices, network connections, storage resources, and so on. The OS also supports the execution and management of applications and software programs that are often user provided.

Middleware is sometimes conflated with embedded software. For purposes of this discussion, middleware is the software that connects the OS with applications software. Middleware can simplify the development of embedded applications by:

• Handling the interactions of distributed applications
• Supporting seamless interactions between heterogeneous hardware, operating systems, and software protocols
• Making applications interoperable, portable, and reusable through common and high-level interfaces.
• Eliminating duplication of effort and enhancing collaboration between applications by delivering a common group of services

While firmware is used to start up an MCU and, after that, to control the hardware peripherals, middleware reaches higher up and provides services to the application software that are unavailable from the OS. Application software is the highest level of software. Unlike the lower levels of software, each application’s software package on an MCU is unique and tailored to perform a specific function. Application software runs on the OS and uses the services from the middleware.

While the general hierarchy of the various types of software is well established, the distinction between adjacent types of software can be blurry. For example, depending on the design environment, a given set of tasks might be assigned to the firmware, and in another instance, the same tasks can be handled by the embedded software (Figure 2).

Embedded software development

Another distinction between application software and the other levels of software is that application software tends to be generic and not customized for a specific MCU. Application software developers need to be expert in all aspects of the application but not familiar with the intricacies of MCU operation. Embedded software development is different.

Embedded software is specialized programming on non-computer devices. It can include firmware, system software, middleware, and even specialized applications. It’s used in an MCU or another device in an embedded system. Embedded software is optimized for the specific device it’s written to run on and must be written within the processing and memory restrictions of the target device.

In addition, embedded software development must also consider all the hardware elements of the embedded system. Embedded software is developed specifically to run on that hardware in that configuration. Characteristics of embedded software include:

• Its purpose-built and task-specific
• It must use resources in the most efficient manner
• It needs to be stable and operate reliably over an extended period

While application software development requires deep knowledge of a specific application, developing embedded software also requires developers to have significant knowledge about hardware operations and interactions.

Putting it together in an embedded system

Depending on their function, Embedded systems have different hardware configurations. Some systems have human-machine interfaces (HMIs), like a display and a keyboard. Others may have network connectivity without an HMI. The same variability is true for software components such as:

• The need for an OS, except in straightforward systems that operate firm firmware only
• Embedded software
• Middleware
• Drivers, software libraries, utilities, and so on
• Some embedded systems may be programmable and support software updates, while others don’t support those functions.

There are two types of OSs used in embedded systems:

• A general-purpose OS (GPOS) is used in systems where response times are not critical. A GPOS typically requires significant processing power to handle various functions and external devices.
• A real-time operating system (RTOS) is used in embedded systems where response time is critical and strict time constraints must be satisfied. An RTOS typically needs less processing power compared to a GPOS.

Real-time control is increasingly important in embedded systems ranging from automobiles, grid infrastructure, and Industry 4.0 systems like robotics to consumer appliances and medical electronics. Some require faster response times than others, but the time window for software execution gets smaller in each case. The embedded software is the critical differentiator in many MCUs for real-time systems. In fact, some real-time MCUs are described in the data sheet as “a collection of software components which enable easy use of the various hardware modules.”

Robotics is a good example of real-time control. Robotic arms need precise control of motor speed and positioning to support sub-100-µm accuracy. To realize that level of performance, it’s necessary to constantly monitor the motor position and motor drive current and voltage. It’s a complex process, and the MCU must compare the measured values with calculated values and adjust the operation of the motor drive in a few microseconds (Figure 3). If the control signal is not accurate or not timely, the system cannot meet the operational requirements.

Some real-time MCUs targeted at especially time-sensitive applications like robotics are based on a dual-core architecture. The main CPU includes an extensive selection of libraries for math, digital signal processing, control, and cryptographic functions. It also has a hardware accelerator to speed the implementation of trigonometric-based algorithms with CPU instructions such as sine, cosine, and arctangent functions, common in torque loop and position calculations in robotic systems. The real-time coprocessor, in this case, maybe a 32-bit floating-point unit that runs at the same speed as the primary CPU. It concurrently executes code and handles the needs of peripheral devices and time-critical functions, leaving the main CPU to handle communications, diagnostics, and other system functions.

Summary

Firmware, system software, middleware, and application software perform specific functions in a digital system. They form a hierarchy beginning with firmware that boots the system and enables various MCU elements to work together. System software or embedded software is preinstalled on the MCU and enables it to perform important system tasks. The middleware connects the MCU with any needed application software. Embedded systems, especially real-time embedded systems, often have strict requirements for the interactions between system hardware and the various types of software.

References

Firmware, Wikipedia
How Firmware Works, AndPLus
Software structure, Synapse Design
What is Embedded Software, Pyramid Solutions
What is “real-time control,” and why do you need it? Texas Instruments