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!

[Nikita91]

My strongest wish would be to be assured of the durability of the software provided by ST.

I started with the defunct SPL, and now there are HAL and LL drivers. But the HAL is not based on LL!

We rather use the LL which allows to develop drivers and libraries better adapted to specific needs. LL drivers are not yet available for the H7 series. Will it be available someday?

My second wish would be to have better-designed peripherals. It's probably too late, but a software developer should be part of the team developing the peripheral devices.

From a hardware point of view the peripherals are sometimes very rustic: no FIFO in the UART which implies a very high interruption rate (there is FIFOs in the 8250 dating from 1984!). I know there is a FIFO in the UART series H7, but it's late and only for high end CPU... The i2C is very complicated to manage (Compare with ATMEL AVR series!), and different in several families.

From a software point of view it is not normal that the I2C requires an interruption of the highest priority. The same thing for the HAL timer.

Third wish, more precise information on device compatibility between different families. I know there are documents that address this topic, but what does "partial compatibility" mean without more information? I dream of a document for each peripheral that clearly indicates what the differences are and in which families they are available.

Apart from that I find the ST policy on NUCLEO and DISCO cards very useful. And the integrated ST-LINK programming probe is really a plus.

[LMI2]

Pinout report from CubeMx is misleading or wrong. In the report there seems to be dot in one corner and chip and datasheet shows something else. See the included pdf file.

[Rob.Riggs]

I really like the way STM32 parts mix analog and digital capabilities. So, keep doing that. I think STM do that better than any of the other big names in the MCU space.

More hobbyist-friendly QFN parts, and even larger QFN variants would be welcome. (QFN-64, anyone?)

A lot of the embedded world is headed towards FPGAs (and RISC-V soft cores) -- and that's where I seem to be heading as well. Some offerings from STM that mixes the same analog capabilities with an FPGA platform would be welcome.

What are STM's plans in the FPGA space?

Support for light-weight open-source DFU tools and libraries that can be embedded into your customers' firmware update tools. Actually -- any sort of involvement by STM staff in open source projects that support STM32 development.

More stuff here: https://github.com/STMicroelectronics

16 projects is rather small for a company of STM's size.

And, of course, my #1 request every year: maintain the HAL libraries on Github!

[raptorhal2]

A dedicated 16 bit register for each ADC channel instead of DMA. This would substantially simplify the firmware.

Cheers, Hal

[S.Ma]

Yep, I'm sharing my hobby code in a separate post, with ring buffer to make FIFO or LIFO between 2 threads which can be ISR of different levels.

Interrupt on no longer empty / becomes empty / now full / overflow with callback or flag (when callback function pointer is NULL), plus statistic on keeping track of the max size used in the app since reset to tune the buffer size).

[Singh.Harjit]

1) ​Make all timers 32 bits.

2) SPI single wire RX keeps running as long as SPI peripheral is enabled. Add a register that says how many RX receives to do?

3) Have more pin multiplexing. I frequently cannot use all the peripherals I want because of conflicts. On STM32H743, I cannot use many of the fast analog channels because of this.

4) On the UART / DMA have a timeout i.e. if no character was received in so many milliseconds ago, generate an event so that we can process the bytes that have come in. Currently, the bytes just sit there / you have to use a separate timer and keep delaying it if you do get a DMA interrupt which is another layer of complexity.

5) Enable better (more and simpler) trigger options between timers, ADCs, GPIOs and DMAs. It is a royal pain to essentially "play Tetris" to find timers, ADCs and DMA channels that work together.

6) Make all the timers the same. Then, there is just one thing for ST to design and verify, customers to learn, write code for, etc.

7) Add more comparators and Op-Amps, please. It makes using the part for Brushless motor control possible.

😎 Increase the ITCM RAM to 128kiB on the STM32H7 series

9) Have a way to drive the chip selects to support multiple SPI devices on the same bus. Imagine I want to have four SPI devices on the same bus. When the timer fires, I want to read from SPI device 1. Next timer fire, read from SPI device 2, etc. Currently, on the STM32H743, I have no way to manipulate the chip selects for each SPI device. What I can do is setup the timer to trigger a DMA to start a SPI transfer but only to one device since only one chip select can be controlled by the SPI block. Off the top of my head, you could build a list of SPI transfers which capture the transfer parameters - number of bits, direction, speed, chip select to be used, etc.. Then, you can build a list of these and point the SPI peripheral to it and off you go!

I realize you are making features VS die size decisions but reducing development burden (for you and the customer) could be helpful.

The parts you make are actually, quite nice.

[JGerb]

Atollic needs more attention - either better documentation and/or improved user experience. Currently debugging is tedious and crashes out a lot, and many features we came to expect from keil etc. are not present/easily visible, such as programming devices from within IDE with a single click, full automatic syntax highlighting and auto-completion of variable names. Default IDE window during debugging is cluttered, needs tuning by user before it is usable.

[After Forever]

A temporary solution for the cookie problem:

Block the cdn.cookielaw.org domain by using a browser extension or short-circuiting it to 127.0.0.1 in your "hosts" file.

https://support.managed.com/kb/a683/how-to-modify-your-hosts-file-so-you-can-work-on-a-site-that-is-not-yet-live.aspx

[Amel NASRI]

adding @Markus GIRDLAND​ 

[Brian Kling]

@S.Ma​ 

1. The banner should go away after the initial acceptance of cookies is done. You might need to clear cookies for "st.com" and then re-establish. There was an old cookie that can sometimes block it.
2. UI issue for remembering you prior location is something I am talking to Salesforce about
3. Bell notifications should update properly, contact me if you still have the issue