2019 STM32 Wish List

[Amel NASRI]

Dear Community Members & STM32 fans,

Let’s end 2018 thanking you for your involvement in our Community and wishing you all the best for 2019!

As already done in 2017 (https://community.st.com/s/feed/0D50X00009bLPmvSAG) and in 2018 (https://community.st.com/s/feed/0D50X00009bLSAKSA4), we open this space to hear from you.

This is an opportunity for us to evaluate what we deliver as offer and to know your expectations.

If we come back to the STM32 portfolio end of last year, it was like this:

Now the image is getting larger with new products as well as ecosystem components:

Compared to the wishes you shared previous years, we weren’t able to answer all proposals for sure, but may be some of our solutions met what you looked for. Like for example: delivering .ioc file in the STM32Cube package which we started with STM32G0...

Either you are a follower of the STM32 history as well as the Community updates, or a new member in this space, would you mind share with us your feedback answering the following 3 questions:

• What shouldn’t be done (don’t say migration to new Community platform or new CubeMX interface (because both of them will be improved)?
• What you appreciate the most as STM32 related offer?
• What do you expect/suggest related to the STM32 and its ecosystem?

All together, keep UP our STM32 Community!

[JoniS]

Better write such time critical code yourself just for the task you need it. Hal libraries as those are intended will be never be without overhead.

[MikeDB]

I do.

But as Jan said, it really would be better if ST provided basic clear and concise C to perform common actions such as setting up clock trees (which Cube gets wrong on the H750 !), I2C, I2S and SAI ports, etc, to which the core DSP I would prefer to focus on developing is connected.

[Vincent Onde]

Hi Jan,

There are appnotes  for these features (on top of product level app notes, such as HW getting started, and generic app notes updated for the G4: bootloader, etc.):

• AN5346: STM32G4 ADC use tips and recommendations
• AN5306: Operational Amplifier (OPAMP) usage in STM32G4 Series
• AN4232: Getting started with analog comparators for STM32F3 Series and STM32G4 Series devices
• AN4539: HRTIM Cookbook (updated for the G4 and HRTIMV2, also includes some C snippets)
• AN5325: Getting started with the CORDIC accelerator using STM32CubeG4 MCU Package
• AN5305: Digital filter implementation with the FMAC using STM32CubeG4 MCU Package
• AN4767: On-the-fly firmware update for dual bank STM32 microcontrollers (the “on-the-fly�? feature is new and was developed for the G4)

But indeed not dozens of appnotes… Could you suggest some topics you’d like to be treated, or improvements to above listed appnotes (besides your remark on clear and concise C examples)?

Thanks and best regards,

Vincent

[MikeDB]

Vincent

I took one of these at random - AN5325.

In it the initialisation code makes a multiparameter call and you say "the code uses the LL driver which has less overhead than the HAL driver"

But then you say "the initialisation must be repeated if one of the parameters changes"

In many applications some of those parameters will be changing all the time, so even going through LL is FAR too much overhead.

By all means list the LL and even HAL calls, but why can't you also list the actual register writes those calls produce for those of us who need as fast as possible code, so that we can just change the relevant register(s) without working our way through the complete datasheet, especially as this isn't always obvious anyway.

[MikeDB]

Add full bare-metal support for the STM32MP1. Some of us need far more raw processing power than the H7 series offers, especially for DSP work, but don't need anything that Linux gives us as that sort of stuff is handled on another processor. All we need is a SPI port, an external memory port and 2, 4 or even more GHz A series cores running in 64 bit mode. I know you can use things like isolcpu but that still leaves one core being crippled by unnecessary overhead.

[Mikas Longbardi]

Completely re do the entire forum back to being usable which means current forum software as it just piece of crap! What utter piece of bull crap this forum format/software have become! Nothing works compared to the original forum back in 2007 who was splendid!

Other then that better support for STLink and H7 in tiny low pincount packages abandonment of internal flash for QSPI and larger internal SRAM

and more then 256MB in memory mapped mode, support for QSPI RAM and SDRAM.

[waclawek.jan]

Hi @Vincent Onde​  ,

I'll try to get to answer it during the weekend, in a separate thread. Meantime, https://community.st.com/s/question/0D50X0000BTdUE0SQN/get-a-copy-of-stm32g4-mixedsignal-mcu-handson-workshop-series-presentations .

JW

[bassetteporn11]

STM32H7 should be pin compatible version of STM32F777 and STM32F479 with BGA216.

Or there should be an H4 running @ 400 Mhz.

[MikeDB]

An STM equivalent to this

https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i.mx-rt-series/i.mx-rt1010-crossover-mcu-with-arm-cortex-m7-core:i.MX-RT1010

M7 core with the current audio interfaces including SPDIF and the PLLs which are far better than the NXP ones, but in a lower cost smaller package like this one. Doesn't really need to be a $1, $2 would be fine but key for me is a smaller package.

[Nikita91]

No 2020 wish list ?

Last year's one is too long to be practical ...