The decision to select an IDE can take place at many different levels of an organization. A single engineer may be using the IDE for just one project. In this case, they're likely to simply select whatever they're familiar with or whatever happens to ship with the microcontroller unit (MCU) for that project. At the other end of the spectrum, an entire department could be integrating the IDE into their development workflow. In this case, the decision could affect dozens of engineers and address multiple target platforms for years down the road.

Some engineers prefer no IDE at all—instead, they'll pull together their favourite text editor and a command-line compiler or linker (such as GCC or Clang), handcraft some makefiles, and set off with coding. This is a perfectly valid approach, too—it will result in a great amount of flexibility and less dependence on proprietary tools and should certainly be considered.

The list of IDEs in the following sections is not meant to be exhaustive. The list is presented in order to provide examples of the wide variety of IDEs available and the different focal points of each. Here are some quick points to consider:

• Language support: Not everything on an embedded MCU is written in C99 (or assembly) anymore; there are many language options out there.
• Debugging support: Unless you plan on context-switching to a different tool each time, debugging is necessary. Your IDE should have some debugging capability. Many IDEs will rely on the GNU Debugger (GDB) for the underlying debug protocol, which means they should be compatible with any debug hardware that supports a GDB interface.
• Thread-aware debugging: Ideally, the IDE will have thread-aware debug capability. Remember, each task has its own stack. By default, most debug capabilities will only show the stack associated with the current program counter, which becomes problematic when attempting to analyze any task that isn't currently running.
• Device support: Pick an IDE that can be made aware of hardware registers in your device (unless you won't be debugging with it).
• The platform OS: That is, Windows, Linux, or macOS—you can always run a virtual machine, but it is generally more convenient to run the IDE natively on your preferred OS.

• Cost: The initial cost of a tool should take into account both the monetary price and the amount of time it would take to integrate the tool into your team's workflow. This initial cost is tightly coupled with the current state of an organization/individual. For example, the cost (in time) of getting a familiar IDE up and running is generally very low, but this cost is dependent on what is familiar to the team. A high total cost of ownership can be caused by a number of different factors. Some IDEs are freely available but have volatile availability (vendor-supplied IDEs often fall into this category). If an IDE has many bugs, the cost of ownership may be high because of lost productivity. Finally, paid proprietary solutions often require annual maintenance agreements for support, updates for the latest hardware, and new versions. 
• Integration with other tools: There are many components that make up developing an embedded system. Having an IDE that integrates as much as possible is helpful, but some of the items to consider are the target hardware, test fixtures, debugging hardware, RTOS firmware, user firmware, target middleware, ancillary host software to help configure hardware (that is, STM32Cube), software to help you analyze and debug code (that is, static analysis tools), and testing frameworks.
• Usability: Ideally, an IDE will provide a pleasant environment to code in and boost productivity by making code creation easier through automating cross-references (such as IntelliSense).
• Availability: In a perfect world, the original IDE would be available, fully supported, and provide updates to make the most of new hardware targets throughout the entire lifetime of a product or project. For long-term projects, it is a good idea to check the history (and licensing model) of the IDE you are planning to use. If the IDE is only available via subscription (with no perpetual licensing option), there could come a day when it is simply no longer available. Ensuring a perpetual license is always on hand enables you to run the IDE indefinitely and gives you the assurance that you'll always be able to reproduce binaries from source code.
• The eco-system: Most IDEs come with more than just the IDE itself. They'll have plugins, middleware, forums, and sometimes entire communities of developers with them. 

In the next sections, we'll cover a few different conceptual groups of IDEs. Grouping IDEs in this way isn't especially rigid, but it does help to frame expectations of what their motivations and use cases are. Sometimes, an IDE can be placed into more than one group, which is also perfectly acceptable. The groups we'll use to categorize the IDEs are as follows:

• Free MCU vendor IDEs and hardware-centric IDEs
• Platform-abstracted IDEs
• Open source/free IDEs
• Proprietary IDEs