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!

[Peter Mather]

28-pin skinny DIP package for an F4 or L4 to compete with the PIC32MX170F256B

[Markus GIRDLAND]

I'm actually working with improving the documentation right now. Is there any specific area you think we missed to cover in the user guide? I could use some good suggestions on topics that needs to get covered.

Some of the issues you raise regarding clutter, auto-completion (ctrl + space, not entirely automatic but it's something) and features not always being easily visible etc. is because it's an Eclipse based application so we want to adhere to that standard and not deviate too far from what Eclipse users expect.

[JGerb]

I haven't discovered the user guide yet, but I did look at the help file once or twice in Atollic.

I first used Atollic when it was fairly new and cost €1000 a licence. I wasn't that impressed at the time and found it far too complex and clunky, and I realise much of my dislike was simply the fact that it was based on Eclipse, which it seems is more suited to large development of complex software in a team environment, whereas I was using it for embedded development, often working alone or in pairs.

I'm more familiar with Keil, IAR, and IDEs for other non-ST micros. For my purposes (and I might not be the majority here) I prefer something simple to use, with all the basic tasks easy to access and find. Something I don't have to invest time in learning, with standard keystrokes that are similar to the other IDEs. Tomorrow I might be using a different manufacturers micro for a different project, and need to learn yet another set of keystrokes and menus.

Basic things like how to comment a block of code in one keystroke, or program the code I've just built into a chip using ST-Link are not easy to find in the menus (I expected a single button at the top of the menus). I didn't know about the auto-completion with control-space, thank you. I also note that the error highlighting doesn't update until you compile in many cases, though this is minor. Other functions like indenting a block of code I only found by using google. And changing the default tab spacing, and some other things which should be one or two clicks, wind up being a real pain. Options are mostly hidden under a bewildering array of menus with confusing organisations and descriptions - at least to me, a hardware designer / embedded coder.

So I think the real problem is that it is Eclipse, and the question should be asked is whether Eclipse is suitable for the majority of embedded engineers, many of whom are not interested in abstract software concepts but need results, and fast.

The help file seems to explain a lot of concepts, but these are not of interest to someone who is trying to get a product out the door in record time, and would rather not have to learn anything new about yet another IDE. Perhaps a quick start guide might be an idea, or a guide to using Atollic with the Cube. Practical examples, rather than theoretical concepts. E.g. I've been using Atollic all week, and I have only now (thanks to google) figured out how to download the compiled binary into a micro (i.e download and run). without debugging. A single button, or at least an example somewhere, would help.

[Markus GIRDLAND]

I can definitely understand you. Eclipse is not for everyone and many things are, just as you mentioned, hidden behind layer upon layer of menus. However, some developers have learned this way and use Eclipse based tools to do many different things which is why we feel we must keep the standard.

If you're going to keep using TrueSTUDIO for development I would really recommend the user guide. You probably won't read through the whole thing but it's a great document to use for ctrl + f and find some information about what you're looking for:

http://gotland.atollic.com/resources/manuals/9.0.0/Atollic_TrueSTUDIO_for_STM32_User_Guide.pdf

Also, now it might be too late since you have used the tool for a while but we do have a quickstart guide:

http://www.emcu.eu/wp-content/uploads/2018/01/Quickstart-for-STM32.pdf

I've also tried to be more active on this forum so feel free to ask around the forum if there are specific questions or suggestions of improvement that you'd like to see.

[JGerb]

Thanks very much! Both of these look like useful documents that will answer many of my questions. I did not see them listed from the Help menu on Atollic though, perhaps this will change in future?

[John Doe1]

GRMII interface !

[PJorg]

Stop developing new features for your tools and focus on making them usable and reliable - You (and us) really need that !!!

The last releases of CubeMX, ToucgGFX and Atollic (all tools owned by ST) can't even build a working combined project - that's not good.

The ideas behind your whole toolchain is good, but its unhealthy for your business that they are so buggy.

Peter Breinholm

[Dave Nadler]

Better SPI module! This thing is lame!

• Native support for arbitrary transfer lengths (like our 20-bit ADC and DAC)
• proper CS support like any other microcontroller
• control of multiple CS pins so an SPI bus can be used, ya know, as a bus!

Don't make us do handstands like this:

https://community.st.com/s/question/0D50X00009q4MRTSA2/stmf4-external-interrupt-dma-20bit-spi-xfer-completion-interrupt-to-isr

[Dave Nadler]

Prompt support for Atollic! Crazy to have incredibly slow response and bugs not addressed for eons, like:

https://community.st.com/s/question/0D50X00009sVPVlSAO/atollic-bugs-convert-to-c-add-c-nature-fails-to-add-c-language-to-symbols-tab?t=1541780227376

[Uwe Bonnes]

As alternative to Clives proposal of chip level stlink MCU, distributing the stlink bootloader image would also do. Even now, bootloader or full stlink images float around, see the China Stlink clones. And I doubt that selling the Stlinks is a cash cow, keeping the financal effect of distributing the bootloader low.