I'm unsure which I'm using. I look it up and some answers say that it's the the host machine that determines if c is embedded c or not, so like, pc -> c, mcu -> embedded c.

edit: I use arm-none-eabi-xxx

CodePudding user response：

There are many versions of arm gcc toolchains. The established naming convention for cross compilers is,

• arm-linux-xxx - this is a 'Regular C', where the library is supported by the Linux OS. The 'xxx' is an ABI format.
• arm-none-xxx - this is the 'embedded C'. The 'xxx' again indicates an ABI. It is generally 'newlib' based. Newlib can be hosted by an RTOS and then it will be almost 'Regular C'. If it is 'baremetal' and the newlib features are defaulted to error this is most likely termed 'embedded C'.

Embedded 'C ' was a term that was common sometime ago, but has generally been abandoned as a technology. As stated, the compiler itself is independant. However, the library/OS is typically what defines the 'spirit' of what you asked.

The ABI can be something like 'gnueabhf' for hard floating point, etc. It is a calling convention between routines and often depends on whether there is an FPU on the system or not. It may also depend on ISA, PIC, etc.

CodePudding user response：

arm-none-eabi-gcc is a cross-compiler for bare-metal ARM. ARM is the target, the host is the machine you run the compiler on - the development host.

In most cases you would use such a compiler for developing for bare-metal (i.e. no fully featured OS) embedded systems, but equally you could be using it to develop bootstrap code for a desktop system, or developing an operating system (though less likely).

In any event, it is not the compiler that determines if the system is embedded. An embedded system is simply a system running software that is not a general-purpose computer. For example many network routers run on embedded Linux such as OpenWRT and in that case you might use arm-linux-eabi-gcc. What distinguishes it is that it is still a cross-compiler; the host on which you build the code, is not the same machine architecture or OS as that which will run it.

Neither does being a cross-compiler make it "embedded" - it is entirely possible to cross compile Linux executables on Windows or vice versa with neither target being embedded.

The point is, there is no "Embedded C" language, it is all "Regular C". What makes it embedded is the intended target. So don't get hung-up on classification of the toolchain. If you are using it to generate code for embedded systems it is embedded, simple as that. Many years ago I worked on a project that used Microsoft C V6 (normally for MS-DOS) in an embedded system with code on ROM and running VRTX RTOS. Microsoft C was by no definition an embedded systems compiler; the "magic" was done by replacing Microsoft's linker to "retarget" it to produce ROM images rather than a .exe.

There are of course some targets that are invariably "embedded", such as 8051, and a cross-compiler for such a target could be said to be exclusively "embedded" I guess, but it is a distinction that serves little purpose.