Czy kod lub dane oprogramowania układowego?

Kiedy ktoś mówi, że „sflashował” oprogramowanie na urządzenie, jestem ciekawy, co to właściwie oznacza.

1. Czy oprogramowanie układowe to tylko natywny plik binarny przechowywany w pamięci, który może być interpretowany przez procesor urządzenia (jak każdy inny plik EXE na komputerze)? A może oprogramowanie układowe to tylko dane, które działają jak dane wejściowe do niezmiennego programu, który jest już na stałe zakodowany / podłączony do urządzenia?
2. Jeśli ten drugi przykład nie jest oprogramowaniem układowym, jak byś go nazwał? Na przykład, powiedzmy, że urządzenie ma jakiś plik binarny ( someapp.exe) i nie można go usunąć ani zmodyfikować. Uruchomiony plik binarny pobiera dane z układu pamięci. Możesz „flashować” dane do tego układu, a tym samym wpływać na wejście / konfigurację someapp.exe, która wpłynie na następne uruchomienie. Jeśli nie oprogramowanie wewnętrzne, jak by to się nazywało?

Jak to często bywa z takimi definicjami, w większości przypadków zgadzamy się, ale nie ma tak naprawdę ścisłej granicy między tym, co jest oprogramowaniem wewnętrznym, a tym, co nie jest. Firmware jest

• przechowywane na stałe (z wyjątkiem osoby posiadającej wiedzę, która może to zmienić ...)
• nieprzeznaczone do zmiany (oprócz ...)
• działa na procesorze bez pomocy innego oprogramowania (z wyjątkiem ... rozumiesz?)

Jeśli chodzi o dane interpretowane przez interpretera (oprogramowania układowego): nie jest to często wykonywane w warunkach profesjonalnych, ponieważ powoduje to, że produkt jest droższy: potrzeba więcej pamięci, mocy procesora itp., Aby osiągnąć ten sam cel końcowy. To jest jednak czasem wykorzystywane w otoczeniu hobbystów, często z tłumacza podstawowe flash oraz (tokenized) Podstawowe zastosowanie przechowywane w pamięci EEPROM (lub we Flashu zbyt). Sprawdź na przykład PICAXE i różne stemple podstawowe.

IMO w takim ustawieniu zarówno tłumacza podstawowego, jak i aplikacji podstawowej należy nazwać oprogramowaniem układowym.

Ciekawym zastosowaniem interpretera oprogramowania układowego, który interpretuje przechowywany kod (który IMO należy również uznać za oprogramowanie układowe), jest uruchomienie XBOX 360. To doskonała rozmowa opisuje ją bardziej szczegółowo.

Poniżej MSalters zastanawia się, czy kod / dane FPGA należy uznać za oprogramowanie wewnętrzne.

W aspektach, które mają największe znaczenie (są to informacje, które można zmieniać na późniejszym etapie procesu produkcyjnego, ale nie mają one być zmieniane przez użytkownika końcowego) bity FPGA zachowują się jak oprogramowanie układowe. To nasuwa pytanie, czy jest to oprogramowanie układowe zgodnie z jakąkolwiek definicją. Ważne jest to, że można (i należy) pisać, obsługiwać i zarządzać jak oprogramowanie układowe. (Jeśli chodzi i kwacze jak kaczka, czy to kaczka?)

Nie zawracaj sobie głowy definicjami, gdy nie są przydatne. Czy oprogramowanie układowe mikrokodu? Czy reprezentacja ma znaczenie? Czy kontekst ma znaczenie? Czy są bity ROM dla oprogramowania układowego IWM?

Komentarz Vaxquis do pytania OP skłonił mnie do przeczytania artykułu wiki, do którego prowadzi. IMO podana tam definicja oprogramowania układowego (trwała pamięć i kod programu oraz przechowywane w nim dane) jest kłopotliwa. IMO mapy przechowywane w systemie nawigacji samochodowej to dane, a nie oprogramowanie wewnętrzne, bez względu na to, jak są przechowywane (zgodnie z wiki powinny to być oprogramowanie wewnętrzne). A aplikacje w telefonie iPhone lub telefonie z Androidem to aplikacje, a nie oprogramowanie wewnętrzne (zgodnie z wiki, powinny one również być oprogramowaniem układowym).

Firmware to kod programu przechowywany w nieulotnej pamięci, takiej jak pamięć flash. Termin ten jest najczęściej używany w połączeniu z systemami wbudowanymi. Może być na tym samym układzie co procesor lub na oddzielnym urządzeniu.

I think both options are sort of correct, just looking at the microprocessor at different levels of abstraction. What you're referring to as your immutable binary would be the hardware itself, which is fairly limited in what it can do. Fetch instruction address 0x0000, decode instruction, fetch supplied address/register, execute, increment instruction counter. That's the microprocessor pipeline, and you can't change it. You control what the microcontroller does by storing instructions in memory, which are then sequentially read out. So basically, yes, firmware is just input data for an immutable program, at a low level of abstraction. Usually, though, it's easier to imagine the firmware as a special program that controls the microprocessor because conceptually it's easier that way.

It is actually both.

One example of firmware is the PC BIOS, one section of the BIOS is executable but other parts of the BIOS itself is actually data, specifically in tables for display to enumerate different functions of a BIOS ROM, regardless of the type of technology it is based on. Often times the data is stored in either, another flash memory, battery or capacitor backed RAM either CMOS SRAM or another compatible memory chip technology.

Firmware, is a generic term used for unchanging / non volatile memory, it's there and accessible as per the power cycle for as long as there is nothing electrically wrong with the circuit or in the case of a programming cycle stuck on, for EEPROMs or Flash ROMs.

Firmware by definition, is the lowest level of access, that initializes, tests hardware you have installed in your system or embedded components and gives low level routines (sometimes seen as BIOS function calls) that your operating system needs to be able to use the components in your system. In the old days, the BIOS or Basic Input Output System also included a programming language called "BASIC", such as the Commodore 64 and other personal computers of the 1970s, of course there were older computers that had BASIC built into them for the use by professional computer scientists as well. If you ever hear of a character or symbol ROM that's a form of pure data for the executive or program ROM to get the system to go to that character ROM and look up characters in a sequence or dump the entire chip into RAM to work with it there.

The default PROM, EPROM, EEPROM, Flash programmers burn firmware on a chip as with the suffix of .hex or .bin, which are similar formats, it depends on your application you're using to send to the chip, the firmware.

Also, there are firmware blob files, these are executables in the form of libraries and routines that are loaded at run-time, a good example of that is wireless hardware drivers, they contain enough code to run all the hardware in those cards via your computer system. The only difference is the card and USB based firmware isn't actually store on them but on your hard disc and loaded into memory. It works as a translation service layer and filter, essentially. It is both data and code too.

My basis of this is that I actually write BIOSes for other computers and embedded systems (for example, wireless firmware, which is actually loaded when your operating system starts, then begins to load the low level hardware drivers, that also include run-time firmware). It's called firmware because it doesn't ever change it's routines unless you get an update from the manufacturer and then the update overwrites the old. Acts as the new firmware in this case until new stuff is found to be updated, if not, then that's the firmware you use when your operating system loads.

I agree, it shouldn't be called firmware because it's not technically on the chip as a permanent solutions and needs a special tool and application to up the firmware (in the case of the old BIOSes vs. that of flash memories).

Got any more questions, I'd be glad to answer them for you.

Firmware is code that has been made in some sort of development environment, just like software code, but then it gets boiled down to machine-code so that the cpu can understand it. If you dump the memory of a microcontroller or some other chip, you'll notice that it looks nothing like C code or what we program it in.

So you don't program a .EXE to it, since that is a compiled program to be run in some sort of OS environment. You'll be programming usually a .hex, or maybe a .elf, it really depends on the device you are programming, but it doesn't matter because you aren't concerned with the file-types since your compiler will instead compile the code down into machine code and place it in the chips on-chip flash or into whatever storage scheme it has.

Firmware is generally immutable in that environmental conditionals have to be programmed in. You cannot change firmware code and leave it be, you have to make the change, compile it, and re-flash the device.

• Generally software code is code that is to be run on top of an operating system.
• Firmware code is the information that is run on the bare metal of the chip. Firmware can either be the actual application program or it can be a simple operating system, that you can then load software onto through means of removable storage or flashing RAM in the embedded world. This level can go down all the way to binary code, because that is still code.
• Once you start working directly with voltage, you have reached the hardware level.

Firmware is a generic term that generally is used to specify something that lives halfway between the software world and the hardware world.

Hardware is difficult to change. Software is easy to change. Firmware isn't as hard to change as hardware, but is harder to change than software.

It could be used to discuss executable code, data, or configuration information (as in FPGA/PLD/etc) which can be changed.

To explain more of what firmware is from the inside sense.

Firmware, is code that executes on very specific hardware, meaning it's op codes are specific to the hardware it's written for, it can be a family of chips or interfaces or meant for just one item.

Essentially what firmware does is this;

1. Has hardwired instructions for a given processor to undertake and execute, this is called a "bootstrap". Which the most bootable computers have this in their BIOS.

2. Initialize said hardware via the instruction in the firmware.

3. Load in / up the jump table.

4. Make the access to registers on a given device accessible.

5. Hand off control to the exiting routine once the BIOS has been used after a cold (powered off state) or warm start (normal reboot or reset pin has been used).

6. Most BIOSes (firmware) are designed for a specific chipset in mind and root out all the functions of those and flesh out any data that something could be attached to a given busline in a computer or embedded device.

7. Hard discs are a good example of a storage solution that in and of itself is an embedded device, that too has a BIOS on it and has a form of firmware on a chip.

Essentially, all firmware is, is a bunch of instructions that another processor does to get functionality out of a said device. It's software that is loaded into a physical device, upon losing power, it will be there when the device regains power.

Technically, you can use any programming or scripting language to create binary files. You just have to know how the processor you are going to be targeting works, the actual op codes, the internal register (let alone what they're for), to learn binary and hexadecimal number systems and how to create an assembler that can save your code in assembly language. After that is complete then you can task another program to convert it into binary, then save it as a .bin or .hex file.

If you want to know how Ada, C, C++, D and other programming languages convert their "tokens" which is their native code that is chopped up into pseudo op-codes into machine language. There are several books that I recommend you read, some are quite elementary and are centered around very specific processors but it's good to learn on. I will give you one book for the time being, because I don't want to drown you or anyone else that reading this in information.

1. Crafting A Compiler with 'C' by Charles N. Fischer & Richard J. LeBlanc, Jr.
2. Do visit this site, it's based on the x86 chipset found in the IBM PC; http://www.laynetworks.com/assembly%20tutorials.htm

That is the introduction to assembly language programming on PCs at the very beginning. It talks about handling interrupts (hardware and software interrupts) and many other topics, it explains more in depth what a BIOS actually does and how to work with it.

Unlike assembly language and machine language, you can get away with a lot more in Ada, C, C++, D, if you don't know your hardware specifics. In assembly and machine language, if you don't know what you're doing, either something bad will happen or the code won't work. I prefer the latter case, not working vs. something bad.

Note: About the answer above, about flash RAM, there is no such thing, there are flash ROMs but not flash RAMs. Flash ROMs have the firmware in them, the RAMs that are battery or capacitor backed, or have another flash ROM that contains parameters for the BIOS's options you've set.

There is code in firmware on how to store or clear the data memory (versus the program memory / firmware itself), if it's a flash ROM or a RAM chip. On PCs if you BIOS password gets garbled or you don't remember it (or someone is messing with you), you can open the case and find the two pins called, "CMOS CLR / CMOS CLEAR / BIOS RESET / BIOS RST", shorting those two pins together also clears the memory, all you would need to do after that is to hit the reset button, when the two pins are still shorted. That clears the password and allows you full access to your PC BIOS (assuming you have a newer computer from 1990s on).

On new PCs, you have flash memory for the firmware and you have battery backed SRAM (doesn't constantly need to be refreshed like DRAM chips, it's based on an older technology).

In terms of Embedded Systems, Flashing Firmware means you have erased the ROM of a Micro-controller using a flashing device and re-written it with new code. This Firmware to be flashed is in HEX Form.

In terms of OS related Terminology, it is also flashed in the ROM but this time it is the responsibility of an OS to flash it when an update comes.

I believe that using the "historical" perspective, might give a more basic understanding of what firmware is.
It first starts with "hard-ware." To provide/create a given function, one could use tubes, relays, transistors, & ICs. You would use a number of these components and you would create a device that performed the required function. This was considered "hard-ware" because if you wanted (or needed) to change the function, you would need to unsolder wires, sockets, etc. and this was "hard" to do. Thus, this method of implementing a function became know as using hardware. Using a CPU, RAM, and code, became another method of creating a function, and became known as "soft-ware" because it was very "easy" to make design changes." However, there was also a need (mostly from manufacturers), to complete as much of a design as early as possible, but be capable of making "last minute" design changes as easy and cost-effective as possible. The use of ROMs allowed this flexibility up to the point of "first ship." EEPROMS allow changes even after "first ship" (in the field). The code needed/used for the ROMs and PROMs was give the name of "firmware."