What is the best IDE / tool chain for an STM32 rookie?

[SHobb.1]

My background is in hardware, but I have extensive experience writing "bare metal" code (C) for 8-bit MCUs, mostly for AVRs. In the past, I have used AVR Studio (now Microchip Studio), starting with version 4.18 down to present versions. Tool chain was avr-gcc, followed by whatever Atmel eventually wrote and integrated into their later IDEs. I am starting a few new projects built around STM32G071 chips. While waiting for hardware, I am trying to come up to speed with software creation using a NUCLEO-F103RB. My end application (for now) requires interfacing to another MCU and controlling a BLDC motor.

This is my first foray into 32 bit MCUs and ARM. What is the best IDE/tool chain for me to use? My head is currently spinning with options. I have looked at STM32CubeIDE, but have read horror stories online about deleted code, etc. I have also read about Keil and IAR. I am reasonably familiar with makefiles, but would like to avoid a pure command line/script/text editor approach, and would prefer a more integrated solution (something similar to Atmel Studio with editably makefiles). Due to my hardware background, my coding style is to be as close to the hardware as possible (configuring peripherals by manually setting registers, etc.). Does this impact my choice? Should I use CMSIS or HAL (not sure how...)?

Any advice would be greatly appreciated.

[TSosi.1]

We use IAR 9.20. Our hardware engineer is ok with it too. The CubeMx, from ST, output compiles without any problem. Make sure you check out CubeMx. The code generated is used for board setup and clock configuration.

[Tesla DeLorean]

From a just works perspective perhaps Keil. IAR seems to be a moving target.

Cube can be an issue if you keep using the auto-gen tools, and then modify/add code, or changing versions and the .IOC format changes, evolves, or fixes bugs in ways that aren't tolerant or backward compatible..

CMSIS directs how things are done in a consistent manner across platforms. HAL honestly is a bit bloated and awkward. You can use things interchangeably, so you can uses register level code, or replace HAL implementations you don't care for. To get things working quickly use the libraries, once you have the mechanics down, refactor things that bog down the CPU.

ARM architectures tend to favour structures for peripherals as they tend to have duplicative instances, and these live sparsely within the normal addressable memory space of the processor. If you're comfortable with register level code, and willing to put the time in on the reference manuals, go for it.

A lot of register level code people post here tends to be very inefficient, the compiler will NOT fold repeated RMW interactions on volatile memory. Speed and efficiency is achieved by writing the code properly, and code size by using subroutines and loops to do repetitive tasks.

Using GNU/GCC and Make is certainly possible.

[Nikita91]

Few years ago I was a STM32 rookie... Here is my opinion:

STM32CubeIDE is a reliable tool and works well. What is less reliable is CubeMX.

You don't have to use CubeMX. You can create a native Eclipse project with CubeIDE. What I appreciate is that there is never any need to worry about makefile (I know, some would say it's bad...)

STM32CubeIDE is generic, and does not require the use of CMSIS, HAL or anything else. What I often do is start from a CubeMX project (mainly to get the clock configuration code), then never regenerate it. Once a CubeMX project works, it is not guaranteed that rebuilding with 1 or 2 versions of Cube Mx later will not introduce bugs. That's certainly what you're referring to.

If you're comfortable using registers, that's best. Create your own library adapted to your specific needs. But the STM32 is much more complicated than an AVR, expect to read the reference manual and the datasheet several times! And reading the LL or HAL code in informative.

A note about using F103 while waiting for a G071. The F103 is very old (it's the 1st STM32!), while the G071 is recent. Most peripherals are different, so you won't be able to recover much at the registry level.

[Pavel A.]

@SHobb.1​ If you are used to the modern Microchip Studio (based on Microsoft Visual Studio), consider Visual GDB.

If you are familiar with Eclipse-based IDEs, then CubeIDE can be good for you.

Remember that debugger is the most important part of the IDE. There are a lot of editors, but a good debugger makes your day (and bad debugger ruins the day).

Keil's debugger is a good one, the rest of it is so-so.

[SHobb.1]

Thanks for the responses. A few follow-ups:

1. What is the distinction between STM32CubeIDE and CubeMX?
2. Why is clock configuration / reset code tricky to write (i.e., why generate it with an extra tool)?
3. Will Visual GDB run with Visual Studio Community (Free)?

[Tesla DeLorean]

Micro-Xplorer was the original pin fitter and initialization code tool

CubeMX is/was the auto-gen code generator across platforms.

CubeIDE is ST's vision on an IDE where the generation has been more tightly integrated with the compiler, debugger, editor, etc.

At least that's my understanding of it.

If you're comfortable with registers, you're probably not in the "monkey flips the switch" crowd.

[Nikita91]

CubeMx ais aconfiguration tool. You select interactively the components to configure and CubeMX will generate a project and the code configuring the components.

CubeMX comes in 2 flavour: a standalone tool or integrated to CubeIDE.

A word about clock configuration. The STM32 can have a very complex clock schema:

• Many system clock source: HSI, HSE, PLL...
• many PLL,
• many internal buses with individual divider to configure their speed,
• Some peripheral have more than one clock source
• More than one memory region, some need a configured clock

CubeMX has a tab that allows you to configure almost everything. This allows you to be consistent and not forget anything. Then you can adapt this code at will.

[Piranha]

Writing clock/bus/flash configuration is very easy and takes approximately 10-20 lines of code, which are compiled up to approximately 200 B. Using HAL/Cube code you get more lines in application code and it pulls in up to 3 KB of additional code, which is not only bloated, but often also broken. In my opinion the choice is pretty obvious...

[Piranha]

Here is a good overview of IDEs:

https://community.st.com/s/question/0D53W00000U7PcHSAV/keil-vs-stm-ide