How to build dependable bare-metal ARM firmware with UNIX tools

For software developers, the world of hardware and firmware can be an exciting change. Firmware catapults your logic into the physical world. Rather than moving text between forms and a database, you can move motors. Rather than listening for an API call, you can listen for SONAR or GPS signals.

This is the guide I wish I had when first starting embedded development. It cultivates professional embedded programming habits from the start. We'll skip the beginner ecosystem like Arduino, and get the most out of hardware with bare metal programming.

The low-level approach allows you to:

• Choose from a variety of chips to match project requirements.
• Use a real-time OS, if desired, instead of a "superloop," for more natural multitasking.
• Make the most of hardware resources. No Arduino, and no embedded Linux. Projects have nearly instant boot times.
• Avoid bugs in intermediate libraries by using a smaller software stack.
• Do full remote debugging with the ability to breakpoint and inspect variables and registers.
• Achieve MISRA conformance if necessary, for safety critical systems.

In particular, we target the ARM architecture, due to popularity. While the examples use STMicroelectronics hardware, we avoid their vendor IDE and hardware abstraction layer (HAL). The principles in this guide work with chips from any ARM vendor. Rather than proprietary IDEs and libraries, we'll use entirely open source tools in a Unix environment (like BSD, Linux, or macOS). Here's why:

• Your project won't "bit rot." Once it builds, it will continue to build for years to come.
• Leverage a mature toolset, like POSIX Make, C99, GCC/LLVM, and GDB/LLDB. They're either already on your system, or easy to install with the OS package manager.
• Use the ubiquitous CMSIS hardware interface. ARM contractually obligates its hardware vendors to supply CMSIS implementations for their products.
• Let official manuals rather than 3rd party libraries be the source of truth. The register names in CMSIS match terminology in the hardware reference manuals.

Using a strong foundation of toolchain and libraries, we'll build the same simple "blinky" project in four different ways. We'll see the boot-up sequence of CMSIS vs the standard library crt0 system. We'll try writing the program with and without an RTOS, and try dynamic vs static memory allocation. We'll also see an example of a fault handler, and how to do remote debugging.

By the end of the guide, you can venture confidently into building, flashing, and debugging more complex projects. The guide constructs examples based on product datasheets and first principles, it's not a copy of existing demos or code snippets.