Things you like and do not like about stm32

Anything not related to STM32
Post Reply
User avatar
CraigKissell
Posts: 1
Joined: Sun Jul 17, 2022 2:51 pm

Things you like and do not like about stm32

Post by CraigKissell »

Hello folks. If you have been a user of stm32, can you tell what you like and what you don’t like about it? I think this thread will help developers gain some motivation and maybe improvement for their project. Hope this topic might interest some of you.
dannyf
Posts: 219
Joined: Sat Jul 04, 2020 7:46 pm

Re: Things you like and do not like about stm32

Post by dannyf »

one thing that I think is challenging is that the peripherals are slightly different from chip to chip, family to family.

ST could have standardized those modules so to minimize needed investment in software.
ag123
Posts: 1425
Joined: Thu Dec 19, 2019 5:30 am
Answers: 19

Re: Things you like and do not like about stm32

Post by ag123 »

it is one of the major mcus that has a diverse range for you to choose, with different feature sets and it is ARM based.
the stm32f4xx has that ART accelerator and FPU, which makes it one of the fastest mcus around for floating point ops (think DSPs) that has wide availability.
The same compiler tool chain can be used to build apps for both Raspberry Pico and STM32s and possibly many other ARM based (cortex-M) mcus.

This is one 'feature' that even today, its utility has not yet been fully explored. Imagine writing an 'app' that run on different ARM mcus (nordic semi? and some other ARM mcu NXP?). Single code tree, compile for different mcu with different feature sets. Not many mcus is even this close.
I think one area where this feature is used is in 3d printer boards, 1 code base - marlin firmware, many different ARM mcu platform.
dannyf
Posts: 219
Joined: Sat Jul 04, 2020 7:46 pm

Re: Things you like and do not like about stm32

Post by dannyf »

It can be done fairly easily with middleware, a layer of software that covers common tasks over a large range of chips. I have a set of routines that basically cover most 8 or 16 or 32 chips. The user application accesses the hardware only through this middle layer. Thus immensely portable from one chip to another - you simply swap in the middle layer of the target chip and you are done.

Arduino in essence is such a thing.
ag123
Posts: 1425
Joined: Thu Dec 19, 2019 5:30 am
Answers: 19

Re: Things you like and do not like about stm32

Post by ag123 »

just 2 c, on mcus 'middleware' more commonly occupies resources and aggravates the problems of small memory (many mcus e.g. stm32f103c{8,b} has 20k sram) and a small amount of flash.
however, that 'middleware' is actually rather common despite the limitations of this approach.

but that as the same compiler can build for the various different ARM mcus, it is quite feasible to write a 'mono repository' code that can compile across the board to the different arm 'platforms' (mcus).

imagine 1 code base it can build and run on stm32, nxp, TI, nordic, pico, etc and all the way to RPi, android (all the phones) et.al. this is feasible, possible. Just that at the moment i'm not sure what projects is using such an approach. perhaps some RTOS may use such features.
i'm not sure just how 'standard' is CMSIS say to build 'cross mcu' apps, it is likely it at least varies between platforms so that all the 'if defs' are after all necessary.
dannyf
Posts: 219
Joined: Sat Jul 04, 2020 7:46 pm

Re: Things you like and do not like about stm32

Post by dannyf »

on mcus 'middleware' more commonly occupies resources and aggravates the problems of small memory (many mcus e.g. stm32f103c{8,b} has 20k sram) and a small amount of flash.
it doesn't have to be. think about flipping a pin, on most chips:

Code: Select all

#define IO_FLP(port, pins)      port |= (pins)
your application would just call that macro / routine (on some chips). Ythe application doesn't need to know how it is implemented on a given chip.

timer routines are another example: most of your timer actions execute around setting a period and then do something once that period elapses.

Code: Select all

  tmr0_init(); //initialize timer0
  tmr0_setPR(period1); //set tmr0 period
  tmr0_act(tmr0_isr);    //activate tmr0 ISR
by swapping in the right middleware (tmr0_init(), tmr0_setPR() and tmr0_act()), that piece of user code can run on different chips unmodified.

the only reason we write code is so we don't have to write code -> a little bit exaggerated but ...
Post Reply

Return to “Off topic”