12

Looking at the differences of device firmware vs driver, I don't really see why we technically need the distinction. I understand that firmware isn't easy to change, that it undertakes the low-level, device operation while drivers are there to communicate with the host OS.

The question is, why can't we just collapse those two layers into one. Just a driver that knows how to communicate with the OS and translates all the requests directly to low-level device operations. Is it for ease of development (i.e. reducing developer knowledge needed to develop this piece of software)? Isn't it possible to communicate to the device using software that doesn't reside in its flash memory?

PentaKon
  • 331
  • 2
  • 13
  • 2
    This question is likely to be answered with opinions rather than facts and citations. It should be updated so it will lead to fact-based answers. – Romeo Ninov Dec 16 '22 at 10:22
  • 2
    Is this an automated comment based on the word "Why" in the title? – PentaKon Dec 16 '22 at 10:25
  • 1
    Firmware tends to be low-level code flashed to an EPLD/EEPROM/IIC device. Drivers join the OS low-level code up to the firmware (in layman's terms) – spikey_richie Dec 16 '22 at 10:34
  • 5
    No, it's good comment, question is too broad. *Drivers and firmware are doing same thing in different places and with emphasis on different parts of work. Theoretically you can do them in one place, but due to opinions and comfort - youd don't* Some things (like direct current manipulations) are "usually" better to be done on-chip (yet often you can do them directly) and some (like high-level communication) are easier off-the-chip (but you still can do them inside of device and often do - ie. by creating webserver). – Aramil Dec 16 '22 at 10:38
  • I changed the title to allow for a very simple answer. *They don't have to be separate*. Whoever knows that to be the case please post the answer. – PentaKon Dec 16 '22 at 10:44
  • @PentaKon - All comments are manually created or selected by a human. In the case of the first comment that’s a copy and paste if the selected close reason – Ramhound Dec 16 '22 at 12:52
  • 3
    Does this answer your question? [Difference and relation between firmware and device driver](https://superuser.com/questions/299442/difference-and-relation-between-firmware-and-device-driver) Your question is complicated by the fact that the definition of "firmware" is fluid, and therefore is ambiguous. – sawdust Dec 17 '22 at 00:42
  • @sawdust no it does not answer my question and I had already looked at that question before posting. Please reopen this question as it is a totally different one (if you read it carefully). Thanks. – PentaKon Dec 18 '22 at 20:18
  • @PentaKon - I have read your your post carefully, and it lacks a clear meaning for "*firmware*". What is your definition of "*firmware*"? A common usage nowadays is "everything that gets written to NVM". In the Linux kernel, "firmware" can refer to a binary file that a device driver might load & then write to its device (because the peripheral device has an embedded microcontroller). USB Wifi adapters when used with Linux often require such a "firmware" (re)load. – sawdust Dec 18 '22 at 23:12
  • @PentaKon -- I have worked many decades as a software engineer, so the title of this post makes no sense to me. The rest of the post seems to be an argument based on the semantics of some unmentioned definitions for these words. Instead of arguing about such semantics or theoretical software, can you present an actual case/example of what you advocate? – sawdust Dec 18 '22 at 23:28
  • 1
    If we can't agree on what firmware means then the whole industry has a problem. Please view the accepted answer and another one. They are very clear and to the point and indicate that this question is valid in itself. Thank you. – PentaKon Dec 21 '22 at 12:17

3 Answers3

33

No, both types of software usually are running on a different type of machine.

Firmware is running on the processor/controller on the peripheral device, the driver is running on the CPU of your machine. Those usually even are different types.

In theory, one could task the CPU of your machine to do all the bit-banging in the peripheral device. This has been done in early computers. But this comes at a high price.

Often, external protocol involves hard timing restrictions (think network card, or a CRT display). Your CPU will need to handle a lot of interrupts to get the work done at the right moment. For that reason, on the famous Sinclair ZX-81, display went off when the CPU was doing hard work - no time for screen refresh :)

Hence, we try to uncouple the work of periphery devices nowadays. CPU will get notified when an full network packet arrived, and doesn't have to poll a wire for changing bits.

jvb
  • 3,065
  • 1
  • 16
  • 18
  • 12
    I am suddenly reminded of those awful [winmodems](https://en.wikipedia.org/wiki/Winmodem) that people bought because they were cheaper, but dragged system performance down considerably. – Booga Roo Dec 16 '22 at 20:15
  • 1
    @BoogaRoo: I've used an embedded modem chipset, and while a CPU was responsible for switching the audio circuitry into different modes during a connection, the hardware provided a serial bitstream once the connection was established. I wonder if Winmodems needed drivers to intercept each byte in order to communicate with the hardware, or to provide compatibility with software that expected to communicate using AT commands? – supercat Dec 16 '22 at 22:32
  • 1
    @supercat, winmodems basically send raw audio off the phone lines to the CPU, and it's the CPU's job to turn that into coherent data. (The few winmodems that *did* get Linux drivers saw some very clever hacks, such as using them for software-based answering machines.) – Mark Dec 17 '22 at 04:22
  • 1
    @Mark: I wouldn't think a 386-based PC would have been able to handle audio processing fast enough to perform audio demodulation in real time. Maybe some of the first Winmodems had audio modulation/demodulation hardware and relied upon the main CPU for supervisory tasks, but later ones shifted even more of the workload to the main CPU as the level of horsepower there improved? – supercat Dec 17 '22 at 05:11
  • 2
    This leaves out the fact that firmware is not OS-specific but drivers are. There has to be some software component that allows interoperation with the specific OS in use. Putting all the code for every OS into the firmware is inefficient. – Todd Wilcox Dec 17 '22 at 06:15
  • 1
    you either handle a lot of interrupts, _or_ you have to lock everything else and spin on a timing loop during at least the most critical part of the process. (Spinning might give better timing properties, but is obviously at least as bad as interrupting) – ilkkachu Dec 17 '22 at 10:18
  • @supercat, winmodems didn't show up until 1996, with the faster Pentiums. Everything before that was a hardware modem that did all the demodulation on the card and delivered a byte stream to the CPU. – Mark Dec 18 '22 at 06:53
  • @Mark: I recall when I was shopping for I think my 14400 modem, that there existed some I/O card modems that required special driver software that wasn't compatible with a lot of DOS programs. To avoid such issues, I bought an external modem that I knew would work with anything that could talk to a serial port. I don't know how much work was offloaded from the motor's controller. – supercat Dec 18 '22 at 17:33
10

Firmware runs on the device using the hardware of the device directly. One way to look at it, is the firmware is an API for the OS, it does not matter what OS the computer runs, if it receives x instruction, then the firmware will do y, and may return a value z. The device will have it own clock that will control the speed instructions are preformed, its own memory, and the processor on the device can be different then the computer, eg the computer may be an amd64, but the device has an arm64 processor. Firmware does not communicate with the CPU or ram directly, it takes instructions from the bus, and puts data back on the bus.

Drivers run on the Computer either at the OS kernel level, or the OS user level, a driver is OS dependent, and must meet the requirements of the OS to be able to function. A driver will generally handle any work that needs the CPU and or the RAM of the Computer, once the per-processing of the instruction has been completed, the instruction is passed to the device via the firmware.

Luke Attard
  • 179
  • 7
  • 1
    This is the answer. The device has one firmware, but one driver *per operating system*. – Nayuki Dec 17 '22 at 05:35
  • 1
    No it's not. There can just as easily be no software on the device and you only have a "driver" type software (for each OS) that receives commands from the OS and directly translates it to hardware commands. The marked answer explains why this is a *bad* (but not impossible) scenario. – PentaKon Dec 18 '22 at 20:17
  • You are asking a question about software, nothing is impossible, if the hardware can do it then software can control it, or read the output. It is for performance and reliability. A mainboard that has a NIC onboard, requires the CPU to do the all the work required with the network data received, resulting in IRQ's being triggered, etc etc. – Luke Attard Dec 19 '22 at 11:00
  • On the reliability side, if you want the software to do the work, the data must travel from the device, on the bus, to the memory, and then to the cpu and back, during this time, there is always a chance of bit flip, data error etc. An example is a Raid Card, having the cpu to do the checksum checks, and the calculations on where to store the checksum and the data in the array would effect performance and lead to more errors. – Luke Attard Dec 19 '22 at 11:02
  • 1
    With that said, if the software is ran by the OS, then it is a called a Driver If the software is on the device, in read only memory, that requires a special process or a external device to change the software. Then this is called firmware. so while you can have a device with no firmware, or a device with no driver. you can not run a driver from read only memory on a device, and you can not run firmware from an OS. Therefore they are separate because they are two different things, and that is what I explained in my answer. – Luke Attard Dec 19 '22 at 11:05
  • The question asks something very simple. Do they *have* to be separate. The answer is they don't and this is not something that is indicated in your answer. You describe the differences and what each thing is supposed to do. What we're looking for is if they *could potentially* be combined into a single thing and if yes, why don't we do it. The other answers explain this clearly. – PentaKon Dec 21 '22 at 12:22
1

In fact, they don't have to be separated.

In a lot of cases one can walk over the whole spectrum from controlling the hardware directly from the central CPU all the way to implementing as much as possible in the firmware.

Here is an incomplete list of design considerations about firmware/driver balance:

  1. Do you want to use a standard driver or interface?

Of course, one can create an USB flash memory stick that exposes the NAND semantics to the driver and save the controller chip. And distribute your exotic the driver somehow (for Windows, Linux, MAC, Konica printers, etc, etc...) . On the other hand, users and OS developers alike expect the USB stick to work with the standard block device driver. Optical mouse with non-HID interface? Not really a good idea either.

  1. Is some of your functionality patent/NDA/trade secret burdened?

The driver (even if compiled) is available for easy reverse-engineering and altering, the firmware - much less so. This is quite often the case with video chips.

  1. Regulations compliance?

A lot of radio-related firmwares (wifi, cell, bluetooth) enforce the compliance with the frequency spectrum regulations.

  1. Cost? There is usually an optimal point in regard to both design and manufacture expenses.

etc, etc...

On the top of this, there are quite a few devices that lack ROM memory so the firmware is actually a part of the driver and is uploaded to the device at every power-on.

fraxinus
  • 1,141
  • 5
  • 6