How does program execution happen in firmware?

Question

I have heard from people working in firmware domain, that there is no Operating system controlling firmware (eg firmware in a USB drive). There is just a single thread running in a while loop waiting for an external command, and this is the start point for an interrupt to happen, followed by a ISR and the control flowing all the way till the hardware. But fundamentally what is that part of hardware that is executing the firmware code ? Is there a CPU or is it ASIC based code which is triggered as long the device is powered. I fail to understand the paradigm shift from a regular CPU-OS based system to a firmware.

Answer 1

There is no paradigm shift; in both cases a CPU is executing the software/firmware.

Firmware and software are the same thing; the only distinction is in how it's stored. Software is typically stored on a mass-storage device (e.g., disk drive) and loaded into volatile memory (e.g., DRAM) before being executed. It's easy to change software, by simply replacing the file containing it with a different one.

Firmware is typically stored in nonvolatile memory (e.g., FLASH) connected more-or-less directly to the CPU. It's harder to modify (hence the "firm") and it may or may not be transferred to a different memory for execution.

Really, the operation of a computer with an "operating system" is fundamentally no different from your description of firmware. Remember, the OS itself is just another piece of software — or more likely, a huge collection of mutually-dependent pieces of software. At the lowest level, the CPU is still sitting in a loop of some sort, waiting for things to do. It's just that that loop is buried inside the OS.

Answer 2

Even a "regular" CPU with an OS must execute firmware...it's usually called the BIOS in a generic PC. The firmware for any CPU is just the software that is always available when the power is turned on, whether the CPU is connected to any peripheral devices (disk drives, USB, etc.) or not. If you have a full-blown OS then the firmware just figures out what device (disk, USB drive, etc.) holds the code for the OS, copies the code into RAM, and runs it. For small embedded devices there is no need for a full OS because you aren't going to be loading different applications or connecting a variety of devices, so the small CPUs just use a very simple OS or perhaps a "task scheduler". Different tasks might be taking sensor readings, waiting for buttons to be pressed, and updating a display. For very simple applications the CPU has plenty of time to do all of the tasks so it just does each one in sequence, which is also known as a "round robin" approach. More sophisticated schedulers consider the priority of the tasks.

The basic point is that every CPU must have some code that is always available to execute when power is turned on. That code is usually stored in a relatively small "read only" memory, or ROM, although modern CPUs put the firmware into a Flash ROM that is "read mostly". The code that is stored in this way is the "firmware" for the CPU.

Answer 3

There seem to be some misconceptions in your question.

Firmware is just software in a fixed form, used to be in a plain (write-once or even mask-programmed) ROM, now mostly in flash (re-writeable) ROM. On some systems this firmware is the only software present, on others (like a regular PC) its main function is to load the other software.

An application can run under control of an OS, or it can run without an OS. The latter situation is often called 'bare metal': the application runs with nothing between it an the hardware 'metal'. The functions that are in the with-OS situation performed by the OS, for instance file system handling and provisions for multi-threading, can still be present in a bare-metal system, but in the form of libraries that are linked with the application.

Software can have a lot of different architectures. A very simple form is the 'get input, do processing, write output' loop. More complicated forms can include polling, interrupts, or multi-threading. Both OS-dependent and bare-metal applications can use all of these architectures.

These three issues are independent: for instance firmware can run bare-metal and use a multi-threaded architecture. Or the firmware be an operating system that loads an application from a floppy (sorry, flash card..) that uses the simple get-do-write loop architecture.

Answer 4

OS and CPU are different concepts. Yes, there is a CPU, which is the key piece of hardware at the heart of the machine. It fetches the firmware instructions from firmware memory and carries them out. (Nowadays it is common for even small systems to have multiple CPU's for parallel execution, by the way; so it is somewhat outdated to speak exclusively about the CPU.)

Firmware is software which is stored in non-volatile (or perhaps even read-only) memory. Because it is in such memory, firmware is available when the machine is turned on. The machine may almost immediately begin executing firmware when it is turned on, or some small boot program (itself firmware) can pull the bigger firmware from some electronic storage such as flash and put it into RAM, and then execute it. The modern use of flash storage these days is why sometimes you may hear the phrase "flashing the new firmware", referring to an upgrade procedure. Firmware doesn't have to be easily upgradable like this. It might come on an integrated circuit chip, so that updating a device to new firmware might involve removing an integrated circuit ("EPROM chip") from a socket and plugging in a new one. PC BIOS's used to be updated in this way, and myriads of other devices. This is really where the word comes from. Some people were uncomfortable with calling a program "software", if they had to swap a chip or circuit board to replace it, which looks more like a hardware update. Hence "firmware" was coined: something "harder" to change than software.

Firmware can be a "full blown" operating system. For example, Tomato is a Linux-based firmware for wireless routers:

http://www.polarcloud.com/tomato

We can log into Tomato via ssh, and get a Linux prompt. So it is an advanced operating system, and it is firmware. But if the router had a hard disk in it, and if the same OS had to be loaded from that disk at startup, it could no longer be legitimately called firmware. Firmware has to be in electronic storage that is accessible to the processor immediately on power up, like flash memory or EPROM chips.

Many consumer devices nowadays have upgradable firmware. If you have a digital camera, for example, you should find its website and see whether a newer firmware version isn't available which fixes some problems that may be present in the factory installed firmware. It is easy to update firmware nowadays even for relatively non-technical end users. The aforementioned Tomato is an example of third-party open source firmware which replaces the factory firmware.

The word "operating system" simply refers to a control program which has a certain degree of sophistication and completeness in managing the resources of the machine and providing reasonably high level services to programs: features like file systems, network protocols, memory and process management, high level access to devices, and perhaps some model of a user as well as security. Not all of these have to be present in an operating system. Usually the memory, process management and I/O are the key. If the control program allows other programs to execute, giving those programs an identity through which they are associated with their own resources, and if it provides services to them for managing the processor and memory, and doing I/O, we may call that control program an operating system.

Since you're curious, you might really enjoy some textbooks on computer architectures, like those by William Stallings, or by Hennesy and Patterson.

Answer 5

At the most fundamental level, a CPU is just a state machine stepping through a sequence of instructions which alter its own internal state and/or produces some output. Abstract and refine this concept to a very high level and you get the latest desktop and mobile processor offerings fro Intel. But the underlying principle is fairly simple - you can build a very basic processor with about a dozen TTL integrated circuits, and microprocessors from the early to mid 1970s, designed for use in desktop calculators and traffic light controllers, were not terribly more complicated than this. Obviously, Moore's law has taken this to a whole other level, and modern high-performance processors bear little resemblance to their ancestors from 35 years ago.

Even so, there is still a huge market for processors (usually called microcontrollers) which are significantly less complex than the cutting edge; these are the types of processors you might find on your USB drive, for example. To address your question - it is possible that some functions of the devices you mention might be handled by an ASIC, but if your colleagues are talking about threads and interrupts this generally indicates that there is a CPU of some time involved, probably on a microcontroller. These are indeed fully-fledged computers in the sense that they have an ALU, registers, a program counter, a stack, etc., but they are very low power and very inexpensive, and might have only a few dozen instructions, rather than the hundreds of the x86 architecture.

There is no requirement that these devices have an operating system of any kind or any concept of context switching (though it is possible in some cases), all that is required of it for its application is to step through the instructions in its program one after the other, and as you say it may be a very simple program indeed.

Answer 6

Minus some permissions, a CPU won't know if its executing code from an OS or any other kind of program. To a CPU, it's just executing instructions fetched from memory.

Let's not forget what an operating system is: a program that is always in memory which is responsible for safely handling and scheduling multiple tasks. The terminology that we use to describe an independent task is a "process". OS's allow processes to share resources (the hardware, memory, etc) safely and schedules and prioritizes their execution, it also provides features like inter-process communication. All of this arises from the need to support multiple concurrent tasks. Minus some permission levels, to the CPU it's just executing instructions OS or no OS - it doesn't know the difference.

When we write firmware for a microcontroller, typically we don't have this extra program (the OS) always in memory to manage tasks for us. Why? Because we do not have a need for multiple concurrent tasks - embedded systems are usually designed and programmed to do just one application well. Contrast this to a PC which is expected to be very flexible and be able to run all kinds of applications at once.

There is no longer a concern of one process occupying and trouncing another process' memory space or one process hogging all the CPU time. This is because we are writing a single program that has access to all resources at any time since it is the sole program running on the system and thus we do not need another program like an OS to manage it. Again, to the CPU, it's just executing instructions fetched from memory, it can't tell the difference, OS or no OS.