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.

[Tesla DeLorean]

Confuses me why the tool doesn't generate a pin table and process that efficiently rather than configuring 100's of pins individually, with two dozen MSP functions.

Also why their GNU startup.s doesn't use tables. The Arduino crew fixed there's.

#ScalesPoorly

[Nikita91]

>Writing clock/bus/flash configuration is very easy and takes approximately 10-20 lines of code

I agree for a skilled developper. And the code generated with LL is not that big (336 bytes for a G431).

@SHobb.1​ required information for a "STM32 rookie". I don't think a beginner can configure an STM32 from scratch thinking about all the subtleties: FLASH latency, setting Range Boost Mode, intermediate system frequency when the target frequency is over 80 MHz, etc. None of this is intuitive.

CubeMX allows to experiment with the configurations, to study the generated code, and then it is possible to optimize it. So I think it's a good learning tool.

[Piranha]

@Community member​, totally agreed and that's exactly what I've done in my driver library. I've also given some examples of pin configuration arrays in this topic:

https://community.st.com/s/question/0D53W00000pRw6xSAC/stm32cubemx-incorrect-code-generation-for-exti-on-stm32h7-with-ll-driver

The startup code also must be fixed:

https://community.st.com/s/question/0D53W00000dS8FcSAK/review-of-st-startup-code

As is the case with almost everything...

@Nikita91​, a clear example is a much better learning tool than all of that bloatware. It requires a much more effort to understand the HAL code, than to read a few pages in reference manual and write a few lines of code, which modify few registers. And, while LL is close to registers, it still requires more effort, because one has to translate the register names to LL names and back. And setting every bit with a separate set of RMW instructions is also very inefficient. So ultimately it's useless for both - beginners and experienced developers.

[waclawek.jan]

@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

[Nikita91]

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

[waclawek.jan]

> 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

[waclawek.jan]

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

Thanks.

Jan

[SHobb.1]

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

[waclawek.jan]

Just to round all possible answers up, this is ST's official answer to your question.

JW

[SHobb.1]

Digging in now. Not sure if I should post a new page(s) for each question, or append here. If I want to take a stab at doing register level programming, it would still be useful if there was/were a header(s) file that contains register names and bit fields as specified in the RM of a device. For example, if I want to manually configure the RCC_xx registers to set up a clock, I would like to be able to use something like

RSS_ON |= (PLL_ON | HSION);

or

RSS_ON |= (1 << PLL_ON) | (1 << HSION);

Basically, I'm looking for something similar to the old device specific header files included in avr-gcc (Example: iom169p.h). Does anything like that exist, or would I need to either create my own or start pulling something from one of the libraries (HAL?)?