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!

[S.Ma]

And how many times did you scroll this web page from the top to reach here?

[Singh.Harjit]

​This thread started with such a nice message:

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

And there was some great input.

But suddenly, the last few items haven't been in this spirit. I hope we resume the constructive environment.

[MikeDB]

Speaking personally, I do try to be constructive helping other people on here. But STM really are pushing me towards respinning a very expensive set of prototypes over to NXP because of their poor documentation and decent software support. I would expect to be able to code setting up the clock and peripheral registers on an MCU purely from the manuals. But on my latest project this has proven to be impossible as there appear to be undocumented programming sequences required. So instead I tried using CubeIDE to generate a working setup I could then reduce down to register level. But all it can produce is an absurdly huge setup using obscure HAL code which is far too complicated to follow and reduce down manually. I have neither the memory space and more importantly reboot time available on my current project to leave it in this format, as I would imagine do many other people.

[Nikita91]

One way to make it practical for generating the SystemClock_Config () function for configuring clocks is to use Cube IDE but by generating LL code.

The LL code is practically only low level access to registers, which in practice we all expect.

There is very little work to do to adapt the generated function. But beware: sometimes the code generated is false.

see: https://community.st.com/s/question/0D50X0000C3CDPQSQ4/stm32cubemx-generate-buggy-systemclockconfig-

[Singh.Harjit]

​I hear you. I don't know the best path to escalate. I'm sure the ST folks here are advocating on our behalf. They do make some amazing parts but without the support, they will not succeed.

[anotherandrew]

I'd like CubeMX to get a BIG overhaul -- I just updated from 4.x to 5.x and memory consumption is now enormous, it's slower and uses a lot more screen real estate. Stop trying to "web 2.0" everything and give us tools that are functional first, and pretty second.

That goes double for this forum. Stop trying to take over my mouse buttons; I *want* to open in a new window. I want 30 topics open without some JS trying to "improve" my experience. Give us proper quoting and notifications via email. An RSS feed that goes back 6 months would also be very helpful. Ideally, abandon this forum altogether and license what StackExchange sells. They've got things figured out very well. It's easy to search, easy to navigate, easy to converse about highly technical subjects. This current forum software is none of those. It is pretty, though.

Changelogs for the updates would be a huge benefit as well, but only if they're *real* changelogs with *details*. Don't tell us "updates and improvements". Better yet, create a github repo and put them there. Use git tags to mark specific point releases, and have your internal developers actually use and commit to the repo so we can see the diffs as they occur. Not big blobs of updates where entire files are rearranged/changed. Make your code easy for us to work with.

[Andrei Chichak]

I'd like a version of the ST-link where I can preload it with my code and, without the support of a PC, just give it power, push a button and have it program my processor.

Exactly the way the PICkit devices work over at Microchip.

That way I can give an ST-Link to my CM and click-click the processor is programmed. No scripts, no PCs, no windows madness.

[jerry2]

My wishlist:

• Better documentation with actual code examples that drill down to bare metal register level, not just call library functions.
• Have native English speakers proofread and correct your documentation to remove all the awkward and misleading phrasing. A hardware reference manual should not be ambiguous in any way--it should be precise and leave no room for interpretation.
• As others have repeatedly said: make all timers 32-bit and make them all the same. No more Advanced Control/General Purpose/Basic timer nonsense!
• More flexible pin mapping. I realize a completely flexible scheme (the ability to assign any function to any pin) is hard to achieve in practice, but please give us something, anything, that's better than what we have now.
• Either fix Atollic or scrap it! The folks who built Atollic fell victim to what every vendor using Eclipse does: they take the basic Eclipse (which isn't slow) and add every plug-in and extension known to man, slowing it down to a sluggish, quivering, overweight monstrosity. I think ST should just write it off as a bad investment and license CrossWorks from Rowley (like Segger did). Now that's a fast, efficient IDE/debugger!
• Improved support for motor control. This includes better support for encoders (Hall, quadrature, sine/cosine, resolvers, etc.) and more flexible linking between peripherals. Take a look at the Infineon XMC4000 series--this is support for motor control done right.
• More flexible peripherals! Case in point: what's up with the SPI peripheral on the 32F7? Why limit transfer sizes to 4-16 bits? Why not make it more flexible, like Infineon does on the XMC4000 (1-63 bits), and what demented mind thought up restricting data rates to a few fixed values? Face-palm... Would it be too much to ask (in 2019!) for an SPI CS that actually works? And what's up with lack of FIFOs on UARTs? Come on, guys, the serial ports on my IBM PC back in the 1980s had FIFOs...

[anotherandrew]

> And what's up with lack of FIFOs on UARTs? Come on, guys, the serial ports on my IBM PC back in the 1980s had FIFOs...

To be fair, the 1980s PCs did not have a nice easy way to DMA data in and out of the old 8250. With these micros it's trivial to implement as large a FIFO as you want with zero CPU intervention...

[waclawek.jan]

> With [DMA in] these micros it's trivial to implement as large a FIFO as you want with zero CPU intervention...

... except that there's no reliable watermark.

https://community.st.com/s/question/0D50X00009XkXnPSAV/usart-rx-with-dma-fifo-and-ndtr

JW

[PNare]

• DCMI module without the limitation of 2048x2048 resolution. This is a great feature in iMX.RT chips
• As Clive mentioned, examples of DDR, especially SDR104 mode with SDMMC of H7 series. Also a low cost dev board implementation that can support this.

[Gudgel.boB]

I use IAR EWARM and older version 6.x

The newer MXcube does NOT support version 6.x anymore so I cannot use newer CubeMX updates without spending many thousands of dollars.

Would be nice to be able to use the newer MXcube software. I am presently using the STM32F446 parts.

Also, I believe that when I started this project (going very well) that came from CubeMX that it did Not actually enable pins from the timers and so I had to add that manually. There seemed to be a bunch of little missing things like that but it still helped me to get things running in the beginning.

In looking at the more recent CubeMX features regarding DMA, there appears to be quite a bit of possibilities missing from the setup through CubeMX.

That's OK though since I was able to use normal register settings AND help from people here on the ST forums to get that going and could not spend too much time playing with the newer CubeMX because of the non-communicability with my older IAR software.

Not sure where I would be now without being able to ask this fine community for help so I really appreciate it !

boB

Everett, WA

[Nikita91]

I would like to know the version of each peripheral present in each MCU.

Each peripheral (I2C, ADC, DMA, ...) can be different in each series of MCU, and even sometimes in the same series.

There are some documents that explain how to migrate from one series to another, but it is not complete, and it is difficult to find out if 2 MCUs have the same version of a particular peripheral (Each bit of each register must be analyzed in detail).

I would like to have a document that indicates for each MCU the version of each embedded peripheral. And also the inverse table: in which MCUs a specific version of peripheral is used.

The ultimate would have been to have a registry in each peripheral that indicated its version. But it's a little too late: hundreds of versions are in circulation.

The usefulness of these versions is to be able to induce which MCUs can be used with each software libraries, or to choose more easily which MCU to choose for a port or a migration.

[waclawek.jan]

> I would like to know the version of each peripheral present in each MCU.

+1

JW

[raptorhal2]

An STLINKV3 Set and Mini that work with Linux.

Cheers, Hal

[rnone]

... And working without 200MBytes of JAVA crapware !!