Is STM32 worth it?

[Francisco-Colli]

Hi! My name is Francisco, and I am 17 years old, I have intermediate Arduino skills, i also worked with LoRa and Nodemcu, but recently I saw this STM32F407VET6 MCU under €9. You can program it using Arduino IDE, stm32 cube IDE and assembler.

Some specs.

"STM32F407xx family is based on the high-performance ARM®Cortex®-M4 32-bit RISC core operating at a frequency of up to 168 MHz."

Some Specs

Cube IDE

I added the datasheet and the official site link.

Official page

STM32F407VE - STMicroelectronics

My question is, is it worth it to waste time learning this platform? Or its way smarter go for an Arduino Due

[westfw]

My question is, is it worth it to waste time learning this platform? Or its way smarter go for an Arduino Due

The STM32F Cortex ARM chips seem to be more popular than the Atmel SAM3X chips.
So yeah, probably more worth using than a Due. Some things will be common (they're both ARM chips), but if you're going to be programming outside the Arduino framework, all the peripherals are different.

(the bad side is that there is less "Arduino Community" support for the ST chips. So fewer libraries to support all those "different" peripherals, less help on the forums, etc.)

[MartinL]

Looks like Adafruit are currently in the process of designing a STM32F405 based feather board: UPDATED! Feather STM32F405 – How did we do? @st_world #STM32F405 #STM32 #STM @adafruit « Adafruit Industries – Makers, hackers, artists, designers and engineers!.

So perhaps there might be more Arduino Community support for STM32 microcontrollers in the future.

[srnet]

Be aware that in some circumstances the faster microcontrollers (compared to 8Mhz ATmegas) can reduce LoRa sensitivity.

Its something to check for and I have noticed it on the DUE for instance.

[septillion]

Think STM32 is a very interesting platform. Both STM32 and ESP are in my opinion more worth the effort than a Due.

If you want to start cheaper (although granted, also a little less powerful but I think that's a good thing ) is a STM32F103 "blue pill". They are like €1,60.

[TFTLCDCyg]

Since library support depends on users, its presence for STM32 in the arduino IDE is reduced. The question that fits is: what hardware do you want to connect?

For MCU of the family F407XX, the best option is the generic danieleff core

STM2F103R8

STM32F103VE

F429I-DISCO

Core7XXI

STM32F103ZET6

Nucleo F767ZI

[Budvar10]

There used to be STM32duino forum by Roger Clark. He is also member here.
However, it looks like it is not active anymore.

[westfw]

the best option is the generic danieleff core

Why? Without having paid attention in the intervening years, the diaspora of STM32F cores (and vendor libraries) is ... confusing (and troubling.)

• Leaf Labs develops Maple, based on STM32F103, using the ST vendor library of the day ("SPL"?)
• displeased with performance, LL rewrites the core in bare metal code. (REALLY bare-metal!)
• LL loses interest, moves on to other stuff.
• ... time passes... Cheap STM32F103 boards from China show up, including "Maple Mini" clones.
  ST releases new Cortex chips and apparently makes it a policy to sell cheap development boards ("Nucleo", "Discovery", etc) in each family. Hobbyist interest increases.
• Roger Clark expands support, improves documentation, establishes stm32duino code repository and associated wiki and forum sites.
• ST keeps releasing chips and boards. Their vendor libraries mutate ("Cube", "HAL", "LL", "CMSIS") Out of necessity, the STM32 code makes more use of the libraries, or at least the vendor-provided structure and constant definitions.
• Roger loses interest. ST gains interest in the Arduino community, assigns some people. STM32duino · GitHub (ST Supported!) is born. (exact ordering and motivations "unclear.") Increasing dependence on vendor libraries.
• Danieleff core also appears. Motivation and differences "unclear."
• ... ? ...

(The above is meant to be non-judgemental and non-political. "loses interest" in particular is not meant to be derogatory. 's just a fact of life; supporting some piece of OSSW for 5+ years without it making you rich and/or famous is a tough job. Perceived or real licensing issues may have played a part in some decisions. Exact parentage of various versions has not been tracked down. Etc...)

[MrMark]

Budvar10:
There used to be STM32duino forum by Roger Clark. He is also member here.
However, it looks like it is not active anymore.

I haven't followed it enough to comment on its value, but there exists an Arduino forum under the broader STM board: https://community.st.com/s/topic/0TO0X000000BWWSWA4/arduino

As noted by "westfw" the backstory for Arduino on STM32 is convoluted and confusing to someone just getting on board and for that matter, those of us who have been at it for awhile. At this point in time and going forward the recommendation is to use the official STM Core.

It's important to be aware that a lot of "how-tos" one finds on the internet were created prior to this point in the Arduino on STM32 evolution and might not be quite right anymore.

[TFTLCDCyg]

Roger started with the blue pill plates and did an excellent job, he brought the F1 and F4 series to our hands. But his initial work must have been overwhelmed by the daily life we all have.

He created the forum with the idea of sharing his work and for the community to contribute more ideas and why not, variants and libraries. With the passage of time, those of STM32 struggled to make their official core, integrated into the arduino environment.

In both cases, adding a variant, involves immersing yourself in the paths that led you to see a "blink" and is not a simple task.

Other approaches emerged, which simplified the addition of variants, we know them as "generic cores": danieleff, ChrisMicro or huaweiwx. Unfortunately their jobs were stopped around the F7 plates. But they managed to add a lot of variants.

The core whose procedure to add new variants turns out to be the most reliable is that of danieleff.

You can handle the F407 series very well as the VE mentioned by Francisco-Colli at the beginning of the post.

It has a good amount of 100% functional fundamental libraries for STM32: SDIO, an optimized SdFat version, SPI, Wire, can handle EEPROm through the AT24Cxx library.

It can handle the DotStar library, DotStarMatrix, GFX_AS, DHT and sensor.

Best of all, it has allowed me to handle screens of the FT80x, FT81x and recently BT81x! series, modifying the gameduino library 23X, harnessing the power of the SdFat library that is included in the danieleff core.

Given the first comment "about ease of learning", my recommendation is that you familiarize yourself with the danieleff core, which will give you the basis to advance to the official STM32 core, and, looking beyond that border: get acquainted with the STM32 HAL.

[Francisco-Colli]

Great! Thanks to all of you! i will buy the stm32

[freetoair]

And finally the real arduino stm32 was born " Portenta H7" !!!

[mrguen]

I tried to familiarize myself with the STM32 boards for a couple of months. Of course these chips are very well equipped for the price. For example I was much interested by the onboard USB to gain footprint and simplicity. Unfortunately, I find that I really can't progress in making products based on STM32. Here is why

• It is a product line made of a very large quantity of board with many variants. Be careful to really choose the good one. They have at least 3 levels entry, intermediate, high performance. With this they provide global datasheet and specialized datasheet for each boards or a couple of boards, plus cook books etc. Each board has its own set of peripherals. In consequences: a nightmare to find information, risk to not have what you expected, and difficulty to source.

• When you try to use an STM32 core for Arduino, because of this multiplicity of configurations that its is also a nightmare to configure using any available core. One has built-in DFU, the other uses a DFU bootloader, HID, upload methods needing to install the STM32cube etc. There are 3, 4, 5, 6 methods to upload to the board but you will be glad when 2 of them work reliably and you don't have to press reset, in time, or not press it or close the serial monitor, fix the windows USB enumeration. It simply a work in progress with most capabilities not working, half implemented, etc. Plus or minus impossible to fix by yourself because there are 3, 4, 5 and more calls from libraries to libraries that are unreadable. You will have to install more then 800 Mb !

• So you will try to focus on one specific product and define a configuration that works. Unfortunately the history of STM32 for Arduino shows its impossible. Maple tried and failed. Roger Clark Melbourne did a great work but could not bring it to a finished product either. Now STM32 is making tons of board definition but nothing is stable and well documented. The nice forum that existed is now presented as read only: very difficult to find information. The new forum is quite empty.

• From a performance perspective, these boards do a lot of things... badly. You will find that there is a huge gap between the theoretical power and the real power of these boards. They lack precision and I suppose this is due to the high integration level. The electric signals inside the chip are not good. Probably because they are so complicated, with multiple clocks buses, a lot of interrupts so they take forever to run etc...

After saying all this, I am personally trying to use some STM32 boards, because of their only real advantage: their capabilities for the cost and size. If these chips are supposed to do 10x more things at a price that is much lower than other microcontrolers it is simply because they are not robust, not precise, and difficult to use.

To conclude I would say: use only a well known STM32 board (blue pill etc) when you design an application that does many things, need many pins, many communication protocols, in a small form factor at low cost but without a need of high precision or performance in any field.

[westfw]

I really can't progress in making products based on STM32. Here is why...

Many of your complaints would apply equally to the Atmel product line, if you were working directly from their chip and/or "vendor development board" catalog. Paradoxically, the far fewer choices you get from Arduino (the company) lead to a better product. I mean, I doubt that anyone thinks that the ATmega328 is the be-all and end-all of powerful microcontrollers, and yet there it is as "most popular" and "good enough for most purposes."
(I wonder if there is some sales/marketing engineer at Atmel/Microchip that has been whispering in their ear: "we have a bunch of new chips, and you might want to focus on ... THIS one.")

there is a huge gap between the theoretical power and the real power of [the STM boards]

Also true of most of the Arduino boards. The number of unused features on an Arduino Due is staggering.
ST wants to show off more chip features (I assume) and does an inadequate job of implementing core requirements. (part of the problem is that the the Arduino Core is pretty tiny, feature-wise.)

They lack precision and I suppose this is due to the high integration level. The electric signals inside the chip are not good.

I do not understand what "lack precision" means in this context, nor do I understand how you come to the conclusion the the internal electrical signals are "not good."

[mrguen]

Well, to summarize you explain why Arduino focus on just a few microcontrolers and why I advise to do the same with STM32: those MCUs that are proved to work well (up till now mostly 8 bits MCUs) and that many people use over many years and the software/learning resources are in production state, enough and maintained.

[DrAzzy]

As far as I can tell, it seems like the STM32 Arduino integration is not really up to par. That's not really a reflection on STM32, or Arduino even, but just the fact that there are several projects being run by various teams, and one of them hasn't "won".

My impression of the STM32 parts was that in terms of peripheral capability, they were pretty baller - obviously, they completely buried any 8-bit MCU, and they seem both more widely used, and more coherently designed, than the Atmel SAM-series of boards. Great hardware specs, in general, IIRC - they seemed like a spectacular series of parts.

As for the Arduino support for them, though... what I hear... isn't so great. It would be nice if one of the groups apparently competing to make these cores would convincingly win the war and be the obvious one to pick.

The size of the product line - coupled with more complex differences between parts (compared to something 8-bit), the fact that different people are pulling for their own favorite hardware, and the fragmented stm32-on-arduino architecture, it's no surprise that the result is uninspiring (what I most remember about STM32 was that they refuse to put everything you need to know about the chip into one file - they had several documents you had to sit there and cross reference, I despised it - I prefer the atmel/microchip approach of ginormous datasheets that have everything you need to know about a chip)

People want the support for the STM32's to be universal - like how nowadays, there's support for almost every half-decent classic AVR or fancy new AVR you might want to use on Arduino. But that's because the peripherals on the classic AVRs - they basically vary only in how many of them each chip has.

And the same is true of the new ones - tinyAVR 0-series, tinyAVR 1-series, and megaAVR 0-series, their peripherals are identical, just varies in how many of them each part has (and the tinyAVR 1-series got a few goodies that the megaAVR 0-series didn't). Note, however, that Microchip is not continuing the Atmel tradition of keeping the peripherals available mostly identical for over a decade - their DA-series ones, released very recently, kick things up a notch, and there are some notable differences...) but the variety among all all the huge number of STM32 families is just on another level.

I'd heard that STM themselves were getting involved in this. Did that ever pan out? That's the scale of resources and organization that could drive a project like that into something good.... or did they just make things worse?

In any event, I never wanted to dive into them. I found the way that the AVR's gave you the the prospect of true mastery within a non-prohibitive amount of time and thought to make them irresistible....

[MrMark]

DrAzzy:
I'd heard that STM themselves were getting involved in this. Did that ever pan out? That's the scale of resources and organization that could drive a project like that into something good.... or did they just make things worse?

The official STM corporate Arduino core in here: GitHub - stm32duino/Arduino_Core_STM32: STM32 core support for Arduino

Unless one has a good reason to be using something else, that should be first choice. It uses one of the STM libraries to implement functionality so it provides basic Arduino capabilities pretty much across the product line. A downside is that their libraries are necessarily pretty heavy.

One unfortunate consequence of STM official support is that the hobbyist community that did much of the Maple-based port has moved on to other things, so there isn't much in the way of community support as there is here. It also annoys me that using the STM official stuff requires registration to get the STLink programmer support and which I've found to be far less finicky than the DPU or Maple bootloader approach.

Also, as "westfw" points out above, the core Arduino paradigm on such a feature rich processor is pretty limiting, so advanced users that can provide community support tend to move on to STM's "real" development tools.

• From a performance perspective, these boards do a lot of things... badly. You will find that there is a huge gap between the theoretical power and the real power of these boards. They lack precision and I suppose this is due to the high integration level. The electric signals inside the chip are not good. Probably because they are so complicated, with multiple clocks buses, a lot of interrupts so they take forever to run etc...

I'm not clear what the poster is getting at here, but presuming "electrical signal inside the chip" is referring to ADC performance, it can be significantly affected by circuit board layout, not intrinsic in the chip and the "blue pill" is designed to cost, not designed for analog performance. I don't know if this is still the case, but the "blue pill" was widely sold with an incorrect value for one of the USB circuit resistors making the USB interface flaky or non-functional on some PCs. Again, that's an issue with the board, not inherent to the chip family.

[LMI1]

I have made a couple of STM32F407, STM32F746 and STM32H750 boards, and some Mega2560 boards too.
STM32 series is a challenge, you are on your own, there is no such support as in Arduino. So I am happy to see some Arduino libraries in an STM32 CPU.

For a paid job I'll take an Arduino, perhaps a STM32 too if somebody else is doing the SW.

But, for instance STM32F746 has 200MHZ clock speed, USB; Ethernet everything more than there are pins on the IC package. For hobby and that challenge, I take 746 and H750, and fight the problems myself alone.

[MartinL]

The STM32 family of microcontrollers on the face of it offer outstanding hardware performance with impressive hardware specs. However, I feel the Arduino compatible support is somewhat deficient.

The STM32 in-built DFU bootloader lacks auto upload and reset features that are available with Arduino and Adafruit's UF2 bootloaders. Having to pull the microcontroller's boot pin high and reset the board every upload just feels clunky in corparison with slicker modern alternatives.

Also, as far as I can tell, it's necessary to register with STM and download their huge STM32CubeProgrammer appication, just to get upload and native serial port communications on the Arduino IDE. Preferring something lighter, I currently resort to using the dfu-util programmer command line and debug over the microcontroller's serial port with a FTDI Serial-To-USB converter board. It's works, but is somewhat more inconvenient.

The other issue I have with STM32duino, is that it's built on the STM32 HAL (Hardware Abstraction Layer). In effect it's an Arduino hardware abstraction layer built on an STM32 hardware abstraction layer. Essentially this means going down two rabbit holes when trying to read the STM32duino core code. Arduino by contrast implement their core code on Atmel's AVR and SAM and SAMD microcontrollers using direct register manipulation, making their code much clearer and easier to read, (at least in my opinion).

Taking of register manipulation, the Atmel's/Microchip's CMSIS register definition files are also much more comprehensive and easier to use/read than STM's attempt.

My final gripe is STM32duino's inclusion of the "HardwareTimer" class. STM32duino automatically creates (instantiates) this class, which essentially hogs all the timer interrupt service routines (ISRs), whether it's using them or not. This means it's necessary to hack the STM32duino code just to call on the timer ISRs directly. Not an problem if you're happy to use the HardwareTimer class, but not so great if you prefer the flexibility of register manipulation. Fortunately, other (non-STM32) Arduino compatible boards have never implemented this class.

[LMI1]

What about Mbed? I don't know it well, but they seem to support wide range of peripheral chips, a bit like Arduino does. You can get Mbed for STM32 CPUs.