What are some embedded C libraries and frameworks that you use or recommend?

I think this line is kind of blurry since really there is no division between embedded C and standard C in language itself. Access to registers using keyword such such as volatile and register or supporting bit manipulation is supposed in C in general and not just "embedded C"

A lot has been said already, but here's something that hurts my eyes: "For example, embedded C allows you to access hardware registers and memory-mapped peripherals directly, using keywords like volatile and register." The keyword "register" suggests to the compiler to put variables in a CPU register instead of RAM. This keyword has nothing to do with memory-mapped peripherals. The keyword "volatile" instructs the compiler not to optimize any subsequent reads or writes of variables, which is particularly useful when the content of a memory location is not changed by the program, but by the hardware itself. Yet again, has nothing to do with "accessing hardware registers and memory-mapped peripherals directly".

I think this is VERY misleading. In firmware (embedded C) you can use dynamic memory, you can use floating-point operations. The skill of the embedded programmer is to understand if the execution time is acceptable, if the memory allows that, if the requirements allows this, and if is really needed in the first place. The difference between embedded and not embedded, is the need to know your system, requirements, toolchain, hardware, CPU architecture, memory mapping and maybe even the economics of the project as well.

I have a little different view here, Embedded C isn't merely a subset of Standard C with restrictions; it's about optimization and control. It grants direct hardware access and bit manipulation crucial for microcontrollers. Limitations like no dynamic memory allocation, recursion, and floating-point ops prioritize speed, predictability, and resource management. Embedded C isn't lacking, it's specialized for embedded systems' challenges in my opinion.

This is not accurate. C does not limit floating point operations. At least not in a way that would be meaningful vs C++, Python or assembler. Floating point performance is very much hardware dependant. C does not limit recursion, as anyone who has hand-coded a Cooley-Tukey FFT should know. And dynamic memory allocation is absolutely possible. However, it is a poor design choice for any language with minimal MPU and MMU support in hardware.

If it is bare metal programming, then the challenge is not entirely the resource constraints but the direct access to the hardware means that care should be taken about its configurations (when some wrong config can actually damage the hardware). Poor memory management can lead to system crashes and traps that are not very obvious and easy to debug. So Embedded C requires more than just the usual programming knowledge. You need to know the capabilities and limitations of the hardware and how to make best use of these in efficient and safe way.

On rare occasion, this paragraph is entirely correct. Embedded C requires more of the programmer, as there is very little in the way if a safety net for poor decision making.

Programmer avec la documentation technique à proximité pour y jeter un oeil en cas de problème au niveau matériel. Rendre son code compatible à minima sur plusieurs références de microcontrôleurs en cas de rupture d'approvisionnement. Faire attention à la synchronisation des accès aux variables et aux dépassements de mémoire tampon !

Security and software architecture are also burgeoning challenges in embedded IoT projects, exacerbated by the limitations of the C programming language, embedded programming in general, and coding standards in the embedded field. The short deadlines that would produce merely poor or badly-structured code in more robust higher-level stacks can result in actively dangerous products in the IoT sector. Whereas higher-level enterprise stacks allow for a great deal of abstraction and automated security, terse and 'safety-guaranteed' C doesn't exist; keeping code clear so as to reduce human error, well-structured so as to be scalable, and fully-secured to stymie malicious behaviour, is becoming a big challenge for developers.

Using inline functions and macros instead of function calls does not always improve code density or execution as these can be within the capabilities of compiler's optimizer (not all compilers are equally good), but these optimizations can make the code harder to follow for the next person to use it. The optimization level causing differences in execution time is an annoyance and can cause previously undiscovered race conditions to be encountered.

This paragraph did well until the last sentence. There is always a tradeoff between performance optimization and resource optimization. There is a reason that they have different gcc compiler directives. One consideration that many overlook, is that flash access is ALWAYS slower to fetch and execute than RAM access. They even run on different clocks beyond the M0, let alone wait state counts. So understanding your application requirements translates to planning your resource allocation. Just as well, irresponsible allocation of dynamic variables to flash can wear down the flash and cause a chip failure. Sometimes in a matter of seconds. The "static" qualifier is NOT to be used without thought or caution.

I did some analysis between GCC, IAR and Keil recently and they all perform pretty comparably with Keil lagging behind GCC and IAR in terms of raw speed and size, but GCC has the best size optimized output. IAR has some cool features like linker compression and has pretty tight implementations of math intrinsics on low power processors like CM0, but you're usually limited more on SRAM than flash in real scenarios. Anyway, I see no reason to use anything except GCC for embedded development at this point unless your org is married to the IDE/JTAG solutions the other compilers provide.

this is a fine line to walk. If adopting a framework allows you to effectively manage scope/feature creep as your design ages and matures, great. If your library lets you increase the knowledge transfer rate to junior/maintenance staff given margins for whatever performance or memory tradeoffs, great. But as soon as you apply dogmatic usage of every framework under the sun I'll start questioning whether or not the solution is optimal given the design constraints.

Frameworks can be helpful. But they can become their own special kind of trap for beginners. Especially for those who lack the initiative or interest to read a datasheet. Thankfully, these trash-mob types seem to have the longevity of a paper moth in this industry.

Learn command line vi and gcc first. They will always be there, even if you don't have a network connection. Beware of manufacturer libraries -- they are often buggy and bloated and updating to the latest is typically not feasible due to all the regression testing involved. I think of IDE's as convenience functions with a nice debugger interface. :)

Is your architecture supported by LLVM? Then consider Rust. For embedded-compatible libraries, search crates.io for categories: embedded, hardware-support, no-std, no-std::no-alloc. In addition to the library ecosystem, you will like cargo tooling and cargo extensions (category development-tools::cargo-plugins on crates.io).

The line between this and previous section is kind of blurry as to what this article considers a framework and what a library.

This is a question with as many different answers as there are embedded processor chips -- Personally have worked with 8080, 8085, 8086, 8088, 8051, 68349, ARM7, MIPS, AVR, TMS320C030 , TMS320C54, TMS320C55, TMS320C6713, ADI-SHARC, TMS2808, TMS2869, TMS28332, TMS470, TMS570, M68000, M68332, MPC555, MPC7447, TMS24xx, MicroBLAZE, and BitSlice Everyone is an adventure in learning!!!!!! The compilers for all of these might support some common subset of features, but oh the issues one can find!

We have the good fortune of living in a time where the accessability of embedded dev kits and tools is incredibly cheap. Not inexpensive. Cheap. If you want to wow your interviewers, bring them a real project built on a real device. A RP2040 kit costs $4. And it requires no additional accessories to program aside from a computer. One can even turn such a kit into a sidecar CMSIS-DAP debugger for the whopping barrier of another $4.

I think Jamie Mascola's idea is best. Beyond that, know about HAL, IPC, the essential protocols (I2C, SPI, CAN, etc), data structures, big O, and bit manipulation. Every interview I conduct also includes at least one question involving hex to decimal translation.