4 ms·
There are a couple exceptions here, like Infineon/Cypress’s PSoC chips, but it sort of seems like 99% of vendors have moved to Eclipse based IDEs with full supp
by jmole 4y ago
There are a couple exceptions here, like Infineon/Cypress’s PSoC chips, but it sort of seems like 99% of vendors have moved to Eclipse based IDEs with full support for whatever compilers work in that ecosystem.
There’s only a handful of things that matter when it comes to generating embedded code for a specific microcontroller and most of it comes down to the format required for the final linked executable, which usually boils down to an ld script.
In general any kind of ARM chip is going to work perfectly fine with the latest C++.
Or to rephrase your comment, the real reason to use C is because all the support tooling, header files, peripheral drivers, RTOS, etc. are written in C, and there’s not a huge benefit to moving user code to C++.
- pclmulqdq 4y agoThat is really important to note: the spread of the Cortex-M0 has been amazing for embedded software. Before, compilers were vendor-managed for their proprietary core, and now they are basically mainline GCC because of the uniform use of the ARM instruction set. I remember using a vendor fork of GCC 2 (released in 1999) to compile for a specific microcontroller in 2015, but since that vendor now releases Cortex-M0's, the vendor-blessed compiler uses a near-mainline GCC.
- svorakang 4y agoAutomotive embedded C developer here. Most of the code in this industry is implemented in a subset of ANSI C90. The reason is not header files, libraries or linker scripts. The reason is as the grandparent post points out: compiler availability. For rare targets, there's just no money in making a compiler work for more than this small subset of C. My favorite example is the compiler for a really strange architecture where everything is 24 bits. Char is short is long is a pointer. Bigger controllers tend to be ARM-based, so it's getting better. Also Tricore has a big share, but their compiler support is getting better. There was even a rust compiler being announced recently, though I doubt it's using LLVM backend, so it's likely to be behind in terms of features.
- l33t233372 4y ago> Char is short is long is a pointer. I thought char was required by the C standard to be 8 bits. If everything is 24 bits, how do you cover 24 bit address space with 8 bit pointers?
- detaro 4y ago> I thought char was required by the C standard to be 8 bits It's not. (EDIT: it is required to be at least 8 bits though)
- pclmulqdq 4y agoWelcome to C! The guns are free, but you can only point them at your foot. The C standard specifies so much less than everyone thinks.
- userbinator 4y agoIt specifies so much less, precisely to allow it to be usable on such weird architectures.
- detaro 4y agoI wouldn't really qualify this as a foot gun, but rather appropriate flexibility. 98% of people never encounter it, and the 2% that do are happy that it is that way, and I don't think alternative approaches like having the compiler hide it are appropriate for C.
- kjs3 4y agoI thought char was required by the C standard to be 8 bits Common misconception. to be at least 8 bits though At least 8 bits for the latter-day compilers for which the 'standard' was the guide. I have seen C compilers where char was 6-bit or 7-bits matching the underlying hardware. However, those probably never implemented more than K&R or some pre-standardization perversion of it. Also...as noted a char can be more than 8 bits, pre- and post-standardization. I've heard tell of (at least) 9-, 16-, 24- and 32-bit chars on more or less weird platforms. At some point I'm sure the standards bodies will do some variation of depreciating 8-ish-bit char's for 32-bit Unicode as the standard representation for text.