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!

[andrewg]

i'm waiting for STM32WB nucleo availability to become more widely available hopefully i'd be able to try it out. and oh yes, after ST has outdone what is feasible with Bluetooth LE (it is a mere 2mbps max) and STM32WB is more powerful than that.

ST may want to try its hands at WIFI. after all, ESP8266 and ESP32

has run ahead in that game

https://en.wikipedia.org/wiki/ESP8266

https://en.wikipedia.org/wiki/ESP32

the thing is the dual core WIFI solution is still something that the industry doesn't have and much less with stm32 in the 'application' core

WIFI could possibly be targeted at the F7 and i think it matters to 'smart' robotics

trouble is various cortex-A is competing in that arena as well

[clonephone82]

It would be great if STM move CubeMX and all the libs to a online hoster like: Github, Gitlab, Bitbucket or whatever. If there is an error anywhere the fixes will be much faster because the community is so big. And almost everyone from the community is a programmer ;-).

So come on ST... stay one step ahead the others.

[waclawek.jan]

Online mcu selector.

https://community.st.com/s/question/0D50X0000AVTfFCSQ1/cheapest-inproduction-with-1x-usb-and-2x-can-preferrably-48pin-package

[WBott]

Hello, this is my first post in the community.

I would very much like to see a software demo using STM32 Cube MX and Keil uVision 5 showing how to integrate an Arduino expansion board, Arrow Development's Slash1000a, with the STM32G071 Nucleo-64. It has lots of interesting peripherals.

[Asantos]

I found on the Net some "spoilers" on the new STM32G4. Everything indicates that ST will meet my wish for a high-end version of STM32F334. Does anyone have more information about this new family to share?

[MikeDB]

There's been rumours for several years but I've never seen anything indicating they would be low pin count devices. I'd certainly be happy if ST do add a higher power low pincount device.

[Asantos]

You can find STM32G431CBT6 and STM32G474CET6 in the Avnet part list. No stock or price yet. 48 pin TQFP for sure.

[Jim1]

I'm a veteran 8-bit embedded developer (Z8, PIC, M432, HC11, and others) and I've found it especially challenging to break into STM32 development. All of the concepts are familiar to me, but the tools feel less intuitive and less accessible by comparison.

We have enough paid software packages blocking developer access to the platform. I'd like to see fewer emphasis for code-limited and insanely expensive development environments, and more focus on free tools. AC6 SWSTM32 seems to be good, but it's extremely complex and their website is severely underpowered and underused. It desperately needs more coherent documentation both for the IDE and the code libraries. Any platform that locks out device memory or functionality in the "free version" is no more useful than a simulator. I hope that ST's focus is on making chips, not making a fortune on the tools needed to use those chips. If there are more free or affordable options that do not limit capability, I think we should work harder to get the word out about them.

If developers of high-performance applications have a specific need for more costly optimized compilers, they have that freedom to branch out. It shouldn't be a barrier to simply using the platform.

I'm very grateful for the existence of ST-LINK in all its various forms. I've got thousands of dollars worth of obsolete programming adapters littering my office. The $500 ones work exactly as well as, and perform the same functions as, the $30 ones. As with software, the programming adapters should not be the profit leader in an embedded platform. They burn out. They get upgraded. They need to be shared among groups. Making them super pricey impairs development.

I'd also like to see more hands-on presentations, because I've found access to sales and design engineers to be extremely helpful on other platforms. A video on YouTube is great, but videos tend not to get updated when the products do, and often the example in the video looks nothing like what's on the user's screen or bench. I noticed that these workshops are commonly held in places like Boston and Long Island. NYC is not far from me, but it can take an additional half a day to get to Farmingville from Manhattan if you're unlucky. Maybe we could have a workshop on the mainland side of the big cities once in a while.

Thanks for reading! I'm new to this scene and I don't know how much of my feedback is relevant/useful but that's my impression so far.

[AVI-crak]

Good time in 2019.

There is an old saying: if it is impossible to overcome chaos, you need to lead it.

If you look at the availability of debuggers, then Chinese products win. They do not even use your chips - they invented their own counterpart.

Dear debuggers have software support: their own debugger - their own software. This is the company segger - the price of their products is compensated by the frantic speed of work in debug mode. By the way, their debuggers do not use stm under the plastic box.

Your programmer has an average cost: above a nearly free Chinese product, and cheaper than debugging from a segger. But at the same time it has minimal support for third-party software. Not fish, not meat.

I propose to lead this mess, and fully open the source code of their debuggers. Yes, the price of your ready-made programmers may fall to cost. But at the same time, sales of the chips themselves will grow: both for the manufacture of the programmer and for home / commercial projects.

You can produce do-it-yourself kits - at cost. This will be a direct sale of your chips. It is better today to sell a hundred pieces at a bucks - than one chip next year.

As experiments, I used the open project https://github.com/texane/stlink. And I even got something working - I managed to add recording functions for external flash memory. One type of memory, one specific project, with a unique connection. How to make a universal type of support - I do not know. And by the way the company segger did it, but they do not want to share.

[Piranha]

By the way, take a look at J-Link EDU Mini for a 20 USD:

https://www.segger.com/products/debug-probes/j-link/models/j-link-edu-mini/