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

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.

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.

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.

@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.

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)?

Here is a good overview of IDEs:

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

@SHobb.1​ ,

using the prechewed material and clicking is a rapid path to a few selected applications. Learning proper programming takes somewhat more effort and time, which more than pays off in the long term, if you mean programming seriously.

There are many which stuck halfway through, giving up to the calling of the easy way initially, and then unable to get rid of it after they found out it's a trap.

Unfortunately, ST refuses to make proper examples, so that's one half-valid reason for going the "libraries" and clicky way.

I despise also the IDEs because IMO the added complexity does not return enough value, and they work hard to lock you in. OTOH, getting a debugger (by which I mean a tool which allows to to stop, single-step and observe internal registers and memories) working makes all the difference; question is, whether the extra fluff with comes with this in IDEs is worth it. I personally struggle with any other than my personally preferred editor, so I went the extra mile (honestly, it was more like extra 30 yards) to learn to use naked gdb.

YMMV.

But start with reading the RM - RM0008 even has a guideline which chapters are the necessary ones, generally up to interrupts - and ask here if you got stuck. As mentioned, 'F103 are ancient and the GPIO there is very different from other families' and honestly it's a PITA, so try to spend as little attention to it as possible. Then write your first program, a loopdelay blinky, again ask here if stuck. Then try to proceed towards more complex stuff.

@Nikita91​ ,

> I don't think a beginner can configure an STM32 from scratch thinking about all the subtleties:

> FLASH latency, setting Range Boost Mode

None of this is a prerequisite for a beginner to start programming a blinky. There are other things, though, e.g. that clock has to be enabled for almost each module, but those he needs to learn anyway (unless he desires to remain in the clicking domain forever).

> intermediate system frequency when the target frequency is over 80 MHz, etc.

Where is that one needed? (This is a honestly curious question - I am constantly seeking material for my gotchas.) If so, isn't it described clearly enough in RM? Isn't reading RM the BASIC prerequisite for anything but the clicking?

> None of this is intuitive.

Depending on the definition of "intuitive", nothing, absolutely nothing of mcu programming is intuitive.

JW

@Community member​ 

The sysclock switching with transition state is explained in G4 RM0440 in the chapter "7.2.7 System clock (SYSCLK) selection"

What intrigues me in this explanation is that ST says "it is recommended to use a transition state". If it's not mandatory why mention it?

When in doubt I do...

I agree reading RM is the basic prerequisite even for a "clicker". But in my opinion it is still common to forget to write a detail, even for someone experienced.

> But in my opinion it is still common to forget to write a detail, even for someone experienced.

Yes it is. This is why appnotes and examples are important. There are no decent examples from ST and appnotes are very scarce and not very good. ST believes in selling "solutions" rather than decent chips with decent support, and that will be their demise in the long term.

That is still no excuse for using the clicky and "libraries", though. You always can read the "libraries" and use it as inspiration (positively or negatively). In particular, the clock setup routine was a disaster throughout the SPL era and quite a few years of Cube/HAL, too. It still does nonsense like rewriting the RC oscillators' trims, and we've complained here a lot.

It's your leg. It hurts the same whether the shooter was you or somebody else; but the latter is IMO psychologically more devastating.

JW

Thank you for all the advice/comments. I think I will start with Visual Studio with Visual GDB, and try to go the straight register route. Coming from an FPGA background, I hope my familiarity with setting up clock domains, plls, etc. will translate somewhat to enable me to do the register approach. I really would like to avoid the "clicky solutions". Look for future posts from me as I try to work through some Hello World and blinky LED projects.

Also: thanks for the heads up on the age of the MCU on the Nucleo I have. I found some NUCLEO-G071RB in stock at Mouser, and ordered one for developing on. No need to make things harder than they need to be...