Is there a restriction that firmware can be written only in compiled languages or Assembly languages or Machine code? Can Interpreted languages or Just In Time Compiled languages be used?
\$\begingroup\$
\$\endgroup\$
14
-
3\$\begingroup\$ Firmware is "firm" in the sense that it's not easily modifiable or directly accessible by the user. As a developer you can use whatever gets the job done. BTW how do you think firmware is written before C was invented? \$\endgroup\$– user3528438Commented May 8, 2020 at 8:27
-
2\$\begingroup\$ The only limitation is your available toolset. I have done embedded projects from hand assembled machine code and others in a number of high level languages. Remember that ultimately it is machine code that actually executes. \$\endgroup\$– Peter SmithCommented May 8, 2020 at 8:39
-
1\$\begingroup\$ Not all firmware runs in hard real time or care about performance. Plenty of applications uses excessive hardware on simple tasks, like a raspberry pi for a digital sign board. \$\endgroup\$– user3528438Commented May 8, 2020 at 8:54
-
2\$\begingroup\$ If you speak of actual microcontroller programming, then in practice C is the only viable option nowadays, assembler turning into a thing of the past. There are some languages like Ada, Python or C++ that can in theory be used too, but I would not recommend those for the purpose of embedded systems. As for interpreted languages, they don't make much sense to use close to hardware. On the FPGA/PLD/SoC side of things, there's hardware definition languages like VHDL and Verilog. \$\endgroup\$– LundinCommented May 8, 2020 at 10:12
-
2\$\begingroup\$ OK, now you are changing the definition of firmware. And that's where I hoped this would lead. Because I can write Python on my laptop, save it on my flash hard drive, make it twiddle my USB serial port, and have it start running when the machine powers up...and meet all of your requirements for "firmware". My entire point is that there is no definition for "firmware" that is universally accepted. The line is very blurry. \$\endgroup\$– Elliot AldersonCommented May 8, 2020 at 21:15
|
Show 9 more comments
7 Answers
\$\begingroup\$
\$\endgroup\$
Embedded firmware is still software, so it is possible to write it in any Turing Complete language given sufficient time and memory (strictly speaking a Turing complete language has infinite resources). We often refer to the languages we use as Turing complete even though the machines do not have infinite resources.
Therefore a program could be written in native machine code, assembler (both of which require quite detailed knowledge of the internals of the device) or a higher level language (which may be compiled or interpreted).
The only real limitation is the available toolset.
Compiled languages are quite efficient but sometimes don't do precisely what you really want (optmisers will strip out instructions that it believes are not necessary even when you think they are although there are ways around that).
The only way to define precisely what is actually run is to write the code with a non-optimising assembler or by hand assembling machine code. This may or may not be more efficient than a compiled solution (it can be depending on how you structure the code).
In some circumstances, we use a compiler and hand tweak the assembly output (not for the faint of heart) in some very demanding situataions.
So the answer is that there is no technical reason that any language could not be used.
answered May 8, 2020 at 10:35
\$\begingroup\$
\$\endgroup\$
3
"The definition of firmware need to be rock solid to continue with this question" is spot-on observation made by @Jeroen3 in this answer.
Any software running on MCU is after all just a bunch of hardware-defined instructions. There are three ways to go from programming language to these instructions:
- Use language which semantics covers the hardware architecture. These languages can be directly compiled into binary code for uploading to MCU.
- Use linked framework libraries providing hardware-level translation of the language abstractions. This approach allows pretty much ANY language to be used for writing firmware. But the framework itself still falls into the category 1.
- Use an interpreted language with interpreter or Virtual Machine (VM) which is written in the language of category 1 or 2.
As you can see, whatever language is used for the bulk of firmware code, there always will be a layer of the category 1 language somewhere before you get your firmware binary or the VM on which to execute it.
So, the answer does depend on the definition of firmware. Or rather on whether or not you include underlying layers into the definition.
-
1\$\begingroup\$ But firmware doesn't have to run on an MCU. \$\endgroup\$– SteveShCommented May 8, 2020 at 20:09
-
\$\begingroup\$ @SteveSh And yet, it is where it usually runs, simply because we use different names for SW running everywhere else, e.g. "BIOS", "HDL" etc. In fact, despite having a "but" in it, your comment actually emphasizes the main point of this post - that without strict definition of firmware OP question cannot have definite answer. \$\endgroup\$– MapleCommented May 10, 2020 at 11:34
-
\$\begingroup\$ I don't disagree. What I am getting around to is that my company has adopted a practice of referring FPGA code as firmware. Right, or wrong (I'm personally not a fan of that), that's the way it is. Almost of these designs are coded in VHDL or Verilog - HDLs, not general purpose programming languages. Hence those designs do not run on a CPU/MCU. Another thing this led to are attempts to bring FPGA/hardware designers into our software organization, and to try and have them follow what's considered "good" software development practices. \$\endgroup\$– SteveShCommented May 10, 2020 at 12:35
\$\begingroup\$
\$\endgroup\$
6
Yes, e.g.:
-
1\$\begingroup\$ I would consider your examples to be applications rather than firmware. \$\endgroup\$ Commented May 8, 2020 at 15:39
-
1\$\begingroup\$ @ElliotAlderson Like I said in the question's comment. Firmware is "firm" from the user's view. Anything other than user-choice programs is considered firmware. Once you pack the whole software stack into a end product that doesn't allow user to add or remove programs from it, then it "firms up" to firmware. \$\endgroup\$ Commented May 8, 2020 at 16:09
-
\$\begingroup\$ So if Android is firmware, I guess Windows is as well? \$\endgroup\$ Commented May 8, 2020 at 17:02
-
1\$\begingroup\$ @ElliotAlderson If the hardware locks down the OS tighter then everyone will consider it firmware, e.g. windows mobile, windows RT, windows on arm laptops, windows powered industrial equipment and medical devices. ChromeOS is considered firmware by most people today, Playstation and XBox OS are considered fimware by everybody. Like I said, software become firmware when the use loses the ability to modify them. It depends on the way software is presented to the user, not software itself. \$\endgroup\$ Commented May 8, 2020 at 17:26
-
1\$\begingroup\$ But by definition anything that is open-source can be modified by the user, and the homebrew IoT projects you mention are obviously created and modified by the user, so those should not be considered firmware, should they? And MicroPython seems to be written in C, so if you run MicroPython on a bare-metal STM32 your firmware is actually written in C, isn't it? I mean the whole purpose of MicroPython is to allow users to easily modify code, so the Python code itself would not be firmware in my opinion. I won't pretend to speak for "most people". \$\endgroup\$ Commented May 8, 2020 at 18:32
\$\begingroup\$
\$\endgroup\$
8
There are some basic requirements when it comes to languages that can compile to firmware. That is, the language dealing with direct low level register access.
For example:
- Pointers, you can't define register locations without them.
- Configurable operator widths. Not all parts of chip can do 8 bit r/w, some must do 8 bit r/w.
Python and Javascript lack both, and thus you won't find much firmware written in those.
Eg: you can't do a 8 bit write to address 0x0800051 in javascript.
-
2\$\begingroup\$ That's absolutely not true. There is already python running on bare metal. You only need low level subroutines written in lower level languages, not the entire firmware. "Firmware can not be written without low level language" is different from "Firmware can not be written with high level language". \$\endgroup\$ Commented May 8, 2020 at 9:04
-
3\$\begingroup\$ @user3528438 So you need something written in other languages to provide a HAL for python? The definition of firmware need to be rock solid to continue with this question then. \$\endgroup\$– Jeroen3Commented May 8, 2020 at 11:33
-
-
1\$\begingroup\$ @user3528438 But was the Python interpreter written in Python? I would be surprised if it was. I believe that micropython was written in C++, so in my interpretation the actual "firmware" was not written in Python even though it can execute Python code. \$\endgroup\$ Commented May 8, 2020 at 17:16
-
1\$\begingroup\$ @ElliotAlderson by that logic, then it's not possible to run "firmware" on a microprogrammed machine, since you're not targeting the actual hardware. \$\endgroup\$ Commented Oct 20, 2020 at 12:56
\$\begingroup\$
\$\endgroup\$
One case of firmware is the BIOS used for booting computers.
A while ago, Sun worstation and PowerPC Machintoshes BIOS were based on the OpenFirmware/OpenBoot standard which uses a FORTH interpreter, the goal was to allow peripherals to provide initialisation/setup code portable across different CPU architectures.
\$\begingroup\$
\$\endgroup\$
1
The processor reads instructions from memory, interprets them as machine code (for that particular type of processor), and executes them.
That's it. That's all it does.
As long as you can get a file with machine code for the processor to execute, you can create this file in any way you want.
You can use machine code.
Or you can use a language with a compiler that outputs machine code.
Or you can use a language with a compiler that outputs bytecode, and a bytecode interpreter written in machine code.
Or you can use a language with a compiler that outputs bytecode, and a bytecode interpreter written in a language with a compiler that outputs machine code.
Or you can use an interpreted language, and an interpreter written in machine code.
Or you can use an interpreted language, and an interpreter written in a language with a compiler that outputs machine code.
Or you can use an interpreted language, and an interpreter written in a language with a compiler that outputs bytecode, and a bytecode interpreter written machine code.
Or you can use an interpreted language, and an interpreter written in a language with a compiler that outputs bytecode, and a bytecode interpreter written in a language with a compiler that outputs machine code.
........
You see? You can do whatever you want, as long as there is machine code at the bottom of the stack. You can even mix-and-match for different parts of the firmware. You want to use Python code in your firmware? Sure, you can do that, if you put a Python interpreter (compiled to machine code) in your firmware as well, and you have enough memory for the interpreter.
-
\$\begingroup\$ How do you feel this really adds anything that wasn't already said months ago? Just enumerating a bunch of examples of what has already been explained doesn't do much. This page has basically degenerated into an argument about what the distinction between firmware and other software is, it seems unlikely that there's anything productive to be done other than simply closing the question which is ultimately a matter of opinion. \$\endgroup\$ Commented Oct 20, 2020 at 14:22
\$\begingroup\$
\$\endgroup\$
3
Firmware simply means software stored in hardware.
For example, a blank EPROM chip is hardware. The data to go in it is software. The resultant programmed part is termed firmware.
Because it can no longer be called hardware and it certainly isn't software. The term was coined to give a name to this combination of parts.
The part is no longer a blank EPROM and should no longer be called 'the EPROM' although people will and do. It should have a new name and, in professional engineering environments, a part number.
So, for an 'ABC' machine, its hardware ('27C512 EPROM') plus its software ('ABC programming file') makes its firmware ('ABC Firmware').
This is no different to a bracket not being called a 'bent metal strip'. It was a metal strip drawn from stores. A manufacturing operation was performed. Now it has a new part number and name: bracket.
As an aside, so often, I see in companies a board with on it: 'the FPGA' or 'the microcontroller', as all the documentation and engineers call it. Actually, the FPGA or microcontroller is the blank part only. Once programmed, it should have been given a new name that denotes its function. If and when someone adds a second FPGA to that board, confusion is created.
-
2\$\begingroup\$ The laptop I'm using has an SSD... so by your argument, every piece of code persistently stored on it is "firmware"? Nope, that's a 1980's definition which no longer works. \$\endgroup\$ Commented Oct 20, 2020 at 12:57
-
1\$\begingroup\$ @ChrisStratton, (it'll get nowhere but...) the noun 'firmware' applies to an entire memory. The SSD is not hardware for storing software. It first stores filing system data structures which holds files. It is a file data storage device. Amongst the many, many types of files are executable files. So an SSD with file system cannot be firmware. One could drum up a fine line to argue over but there isn't really one in general engineering use. Large amounts of spoken language and nouns would not withstand such scrutiny and misappropriation, yet people manage to use them a lot without confusion. \$\endgroup\$– TonyMCommented Oct 20, 2020 at 14:44
-
1\$\begingroup\$ In practice, it's often traditional to refer to entire flash images of products (which internally contain filesystem organization) as "firmware". Even when they sit on something like EMMC or even a more traditional SSD in what is basically a PC, for example the case of the chromebook system image. If I backup a small system to a disk image, and
ddthat to another drive, is it now "firmware"? Or does it only count if I become a "manufacturer" by deploying the same image to several hardware units? Does my openwrt system image with squashfs count, but an armbian one with ext4 not? \$\endgroup\$ Commented Oct 20, 2020 at 14:49