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!

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

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

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

[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

[Vincent Onde]

​Hello,

Did you had  a look to the  STM32G4x4 , announced recently? It does not include Ethernet, but most of your expectations are included.

Vincent