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]

When debugging, the GPIO port is shown as hexa address, same for the pin position.

While there might be misra or other coding constrain, a #define DEBUG compile mode where the pin name and peripheral locations are replaced from (random value, don't want to spend time browsing the specs)

#define GPIOA 0x2000204

replaced by

typedef enum {

GPIOA = 0x2000204; // in debug watch window, I will see the human readable "GPIOA" and not the hex value...

This could also extend to define a single pin which could be simply named like:

typdef enum {

PA0, PA1, PA2.... } which could even handle unsupported or not present pin by package type. (PK3 = -1?). a port + pin can info can be retrieved from a 8 or 16 bit index value.

[vml]

WE NEED OPEN FOR USERS ISSUE TRACKER!

Currently there is no differentiation among issues and questions in communication with ST. So lot of ISSUES are kept in big heap of QUESTIONS from users. The industry in many areas is using open for users issue trackers and bug trackers. Why not to use the same for ST?

Currently it seems the ST has inside issue tracker but users are not able to access it and add something to issues OR see the current state of issue (ST thinks it was fixed OR issue is in progress of fixing OR ST decided to leave everything as it is and do not fix it).

For example please see this issue about high DPI problem in GUI of CubeMX4

https://community.st.com/s/question/0D50X00009XkfPjSAJ/stm32cubemx-on-uhd-4k-display-clock-configuration-diagram-too-small-to-see

St's employeу answered "I will report your issue to our CubeMx teamfor checking and will come back to you as soon as possible" in 2016 ... and nobody sees any ST employeу in this issue for 2+ years since then.

In two years CubeMX5 was introduced ... where this problem is EVEN LARGER! New ussue was created by community

https://community.st.com/s/question/0D50X0000A1lWHASQ2/cubemx5-seems-totally-useless-for-developers-with-high-dpi-monitors-

And again the same person is saying "I raised your issue internally to CubeMx team for check and we will come back to you soon"

Answer me ... what is current state of the problem. ST thinks it was fixed, is fixing (plan to fix in version 5.) or what? Or ST decided not to fix the problem (the same way as it was for CubeMX4)?

Or more global quesiton ... what issues are most valueable for user and need to be fixed first right now?

User's feedback is almost impossible to manage efficiently without open for users issue tracker.

So I would like to see ST have open for users issue tracker.

May be such system have more help for software compared with hardware (because it is much easier to change software compared to ICs). OK. Let's use it for SOFTWARE PRODUCTS ONLY.

May be ST does not want to show problems of payed software because of people payed for it and will see that product has many issues. OK. Let's have it only for software which is given free of charge. So nobody could blame ST in issues because you get at least someting FOR FREE

May be ST is actively developing only some software product. OK. Let's have issue tracker only for most active software product of ST.

May be ST have no resources to create issue tracker at this site. OK. ST have github account https://github.com/STMicroelectronics and can create new repository ABSOLUTELY FREE just to manage User's feedback (without sharing the code or something like that). Let's first open repository for just CubeMX as the flagship of ST's software or any other big software product ST selects.

Management of ST's user's issues is a nightmare right now! Really!

No software product can be as effective for users as with help of open issue tracking system (because software developers have their vision of user's life and this vision can miss many aspect of real user's life)

[andy2399]

Prior to the acquisition of Atollic and Draupner I don't think ST had a very competent software team. If I were ST I would get the TouchGFX or Atollic team to create a new STM32CubeMX application as the current software is a complete disaster. As I suggested in a previous post, I would open source the MCU support packages to allow the community to fix bugs as they are found.

Andy

[wan512]

 How about a solution for Biometric Smartcard: [STM32WB + ST31/ST33] + FP_Sensor

 STM32WB and ST31/ST33 comes as a SiP, and exports several peripherials e.g. 

 SPI[FP_Sensor, EPD], I2C/GPIOs[LEDs/Buzzer].

 ST31 should be best than ST33, for ST31 has RF interface.

[Joerg Wagner]

Increase the Timer Input Filter. fDTS=32*8*4 is not enough as a maximum value.

Noisy signals from low speed sensors in industrial environment cannot be filtered

properly with a Timer which is connected to >100MHz bus.

I don't want to slow down the bus because other interfaces, i.e. SPI would be influenced as well.

Or establish a new bus lane where some timers are linked to, like APB4 in H743.

Or no new bus lane and extend LPTIMx with ETR inputs.

This lack of the bundle TIMx and other interfaces on the same bus forces me to use a 2nd MCU,

like 32F413 to handle the sensor signals .

[raptorhal2]

Until your wish comes true, a very effective filter is a comparator circuit with hysteresis. With a search you can find application notes by comparator manufacturers. Investigate if an MCU comparator can be configured with external components for hysteresis.

Cheers. Hal

[Julien FAUCHER]

Add an interconnection matrix which would allows the user to map *any* function to *any* pin. (With maybe an exception for some pins such as cristal inputs and programmation pins )

[antonio.portaluri]

A bug-report dedicated platform. An official page where anyone can find all known bugs for a selected MCU/Board/Driver, a possible workaround and the status (under investigation, fixed in the next release, ...).

It is a waste of time to serch into the forum and read threads that have similar title but differs for MCU/Drivers or do not present the same issue.

Obviously also a way to report a bug from an user (with all info that are useful for your team to reporoduce it).

This is mandatory in my opinion.

[kurta999]

YES! This should be done years ago.

[James Murray]

My request isn't simple, but would certainly help.

1. Make the HAL / LL code less of a tangle

2. honour your claims of MISRA compliance.

3. Provide some easily accessible global error code structure, currently most of the code blindly ignores any error code.

The three problems combined can make debugging a new peripheral a nightmare. With no global error code, the only option is to singlestep. The code is very deep with up to maybe ten levels of function call jumping from file to file. Function return codes are often ignored, or pass back a value that is always set to "OK" at the deepest level.

On point 2, anyone making the claim that your HAL Libraries are MISRA compliant is simply lying. Send me an email and I can talk you through many glaring examples of non-compliance.

James

[S.Ma]

Any example of microcontroller library(ies) (URL) to give a more concrete reference to look at?

[James Murray]

Not sure I understand your question. I'm referring to problems with the STM32Cube libraries.

James

[kurta999]

Add option for CubeMX to skip generating init functions for peripherials. EG:

• skip RTC init function because I need my own,
• skip other init functions too like UART, SystemClock, etc.

Consider implementing every low level function like enabling UART idle line, FPU interrupts and ARM related functions to CubeMX. Everything. Of course user could decide that he wants to enable usart idle, tx interrupt, DMA half transfer or transfer complete interrupt.

Made CubeMX faster because it's INCREDIBLE SLOW. I'm not going to wait seconds to swich from one page to another with high end pc in 2019.

Improve TrueStudio, because I'm already thinking to switch to VisualGDB which nowadays gets lot of attention. In TS, fixing bug reports took months, no new features + slow as hell, Visual Studio a lot faster.

[Rob.Riggs]

STM32CubeProgrammer for Android. Would love to be able to program devices in the field with OTG cable from my phone.

[Marcelo Barros]

• How about a new peripheral supporting step motors ?
• Make stm32wb line more widely available.
• A new wireless (wifi) microcontroller as a good replacement for esp32 ?
• Add NuttX as supported RTOS in CubeMX
• Solve CubeMX problems in Linux. Sometimes it starts to use 100% of CPU and it is quite difficult to close it.
• Add support for stm32duino in CubeMX.
• Put systick callback call inside systick interrupt again.
• Please, more microcontrollers with 16 bits ADCs !
• Please, more microcontroller with 32 bits timers !
• Create an Issue tracker, urgently.