Setting Up A Development Environment

Part I in “Building REXIS, a Cortex-M microcontroller Real Time OS”

As we stopped development of the ImageCraft embedded tools in 2020, when I decided to rewrite my message passing kernel REXIS (Real-time EXecutive for Intelligent Systems) in modern C++ and planning to eventually evolve it into a full operating system, I needed to set up a new development environment. In this post, I described the tools I ended up using, and why I made the decisions that I did.

To do basic C++ embedded development with the Cortex-M microcontrollers, at the minimum, you need:

  • A C/C++ compiler
  • An IDE, or an editor with separate build system
  • A hardware development board
  • Hardware debug pod
  • Software debugger

My Selections

My desktop runs Windows 10. Here’s what I ended up with:

  • Compiler: GNU embedded ARM C++ compiler 
  • Editor: Microsoft’s VSCode 
  • Build system: make 
  • Source control: git
  • Visual debugger: Segger’s Ozone
  • Hardware board and debug pod: ST-Nucleo with STMF411RE M4 microcontroller
  • MSYS2 for Linux tools

The total cost is less than $15 for the ST-Nucleo. Everything else is free or free for noncommercial use. MSYS2 is only needed for my convenience. None of the tools requires it.

The choice for the compiler is obvious as the GNU embedded compiler is the standard. It’s free, generates excellent code, and is well supported by the silicon vendors and others.

VSCode (“Visual Studio Code”) is a highly extendable editor that works fast and well. It comes from Microsoft, but is not related to their traditional Visual Studio IDE. It’s built on top of the Electron platform, meaning that it actually uses the same Javascript NodeJS engine that powers web applications. Even though it is built on web technologies, it is as fast as other editors I have used, with great support for C++ (and other languages) using extensions. In particular, the Intellisense C++ support makes it easy to navigate C++ source files.

As a long time Unix / Linux user, using make is second nature to me and is a no-brainer for a generic build system. When the project gets more complex, I will switch to using a more capable build system such as CMake or Ninja.

Although I can debug using the command line gdb GNU debugger, it is much nicer to have a GUI debugger. Toward that goal, Segger’s Ozone is a natural choice. You can use the built-in file browser to set breakpoints, and it has the usual set of tools such as stack trace, step-over and step-into, code disassembly etc. The best feature is the seamless integration of assembly and C++ instruction-aware stepping

Finally, for hardware prototyping, the ST-Nucleo lines of development boards are true bargains. For an average sale price of around $15, there are versions with different STM microcontrollers, from the low power L0 series, to the powerful F7 and H7 series. They come with a built-in debug pod on board, and for the best experience with Segger’s tools, you can program the debug pod to act as a Segger JLINK pod. You can even reverse the change if you wish.


There are many alternatives. You can use the silicon vendors’ supplied (usually free) IDE and graphical tools. They usually (always?) include the GNU C/C++ compilers. For example, ST’s CubeIDE is competent. It’s slow since it is based on Eclipse and the code generated by the graphical tools are the bloated “LL” low level or “HL” high level ST API code, but it does work well. It can be a daunting experience to program using the ST IO registers directly, so this is a good compromise.

Other silicon vendors offer similar software and hardware development solutions. The cost is usually free or low since they want you to buy millions of their chips, and providing no / low cost development tools is one way for them to grab developers’ attention.

I generally prefer to roll-my-own, and eschew the bloatware, but for people just starting, these can be good choices.

What’s Next

In the next part, I will describe how to set up the GNU environment.

Scroll to Top