Proposal: Embedded Programming and Design
Do we plan on separating the two concepts of Firmware and BIOS programming ?
Or will both be part of this proposed group ?
For that matter, it would be quite plausible for an embedded systems device to have a BIOS of its own; firmware, and possibly dynamically loaded software.
Conversely, I can see people thinking of embedded firmware and the acronym "BIOS" as two synonyms.
Can we clarify this ?
Making the firmware of a processor that is embedded in a larger device definitely counts as embedded programming. So firmware as in the code that executes on a modem, a motor controller, a sound processor, a sensor, etc. would definitely be on-topic on an embedded programming site.
The word “firmware” is very broad, so there are things that are called firmware that will be off-topic, such as a smartphone firmware image would be off-topic.
A BIOS is the firmware of the main CPU of a PC, so I'd expect that to be generally on-topic.
In this case, a picture's worth a thousand words.
EFI is the new BIOS in case anyone who comes across this didn't know. From a separate question it was determined that driver level questions were on topic, which sits under the operating system and (arguably) next to the BIOS, so by definition BIOS level questions would have to be on topic. User space apps would not be on topic, unless they're written in assembly (!).
As far as separating the two topics, assuming you're referring to tags, I say yes. I say this because (personally) when I think of a BIOS, taking an embedded device such as a soekris box as a great example, it has a BIOS, which allows you to set options such as com port bitrate and parity, and other options like boot to network, etc.
Now, firmware is something a little different, User.1 pointed out that it's loaded onto the device and is rarely if ever changed by UI (sometimes, think internet firmware updates). I like to refer to it as 'extremely embedded', but a common term is 'deeply embedded'. However, this becomes essential when you look at how a BIOS might interact with a subsystem that's controlled by firmware, a hard drive is a perfect example, as a BIOS would communicate to the firmware and not the platters themselves to find out space, speed, and all the gushy details that makes people rush out to stores and.... I'm sure you get the point.
The moral is sometimes the BIOS and firmware are mushed together, but a lot of the time they aren't. They deserve their own tags, and in questions where both tags are warranted, it shall be sanctioned and implemented by whomever takes the initiative. :D
I have been working professionally with both embedded and Desktop programming for the last 20 years. I would say that Firmware is a lot closer to embedded than a BIOS. Technically they are the same thing, reside on the hardware platform and executed at boot. Generally speaking, if you mention BIOS, most people will think of a PC BIOS.
A BIOS, by definition, is providing a Basic Input/Output System (BIOS), while a Firmware (FW) is everything, both main, library, API and data storage in one piece. The firmware is working directly with the hardware and usually don't rely on external drivers to be loaded in runtime.
In some larger embedded systems an RTOS (Real Time Operating System) is also a part of the Firmware.
As @Gilles pointed out, Firmware is very broad, so are also "embedded systems". Where do we draw the line? In theory, everything is an embedded system.
