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!

[AVI-crak]

Add DMA ring buffer mode. I want him to check the new data counter (head), and automatically work with the data, while increasing the processed data counter (tail). DMA operation in this mode will be very simple for the user, with minimal overhead. Ring buffers are used very often, and they are always software. You will have lots of examples to follow.

DDR SDRAM memory on a chip, possibly the second floor, but always in monolithic execution.

You have a very good start with the STM32G0 series. If you manage to keep the direction in the development of this series - it will be perfect. Prompt how to do well probably does not make sense. There is a suggestion:

Organize in your company a few new jobs, with the post of designer of final products on your products. No matter how popular these products are, and sales plans are not important either. It is important to fix the difficulties that your developers will face. All these problems, big and not so much - all of them will arise for your users. Your personal developer will always be able to reasonably show the weaknesses of the product, without using a broken phone as an external forum. This is feedback with minimal latency.

[Rob.Riggs]

What's wrong with the current DMA circular buffer implementation? Have you used it? How do you see a ring buffer being different from what is already available?

[AVI-crak]

DMA in the present version of the ring - works without stopping, or requires flag maintenance. After stopping, requires a full setup on the balance of data transfer. It has only one parameter - the amount of data in the ring. There are no markers of the tail and head - like real ring buffers.

My suggestion in the hardware implementation of the ring buffer. To do this, you need to add two counters - the head and tail. The tail counter will be controlled by the DMA, and it cannot skip the position of the head counter. That is, DMA should be able to stop and start independently with new data, without external maintenance. The user must record the new data above the head counter, without catching the tail, and update the head counter. After which the DMA must transfer the data itself.

   

Ring mode and ring buffer are different ways of managing information.

Read about the work of ring buffers, and find the differences.

The closest hardware implementation of the ring buffer is the FIFO. Device with input / output at one address. If it is supplemented with a counter of free data cells, then it will turn out even better than the ring buffer. ST has already applied FIFO in its products, in the shadow mode, without the possibility of user intervention.

Here you need all the same, only with an external indicator of free memory cells.

[Tesla DeLorean]

STM32 Cube Programmer GUI to be able to WRITE .BIN or .HEX files, ie read content of part and save to disk.

[matic]

DLL for ST-Link to use them in mass production... Loading user data to flash after chip is programmed should be fast...

[andy2399]

Make STM32CubeMX open source.

Andy

[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

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

8) 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.

[Uwe Bonnes]

Regarding 4): What is wrong with the uart idle interrupt?

[waclawek.jan]

For example it can't be set to an arbitrary time. There are applications where intracharacter delay may be longer than a character's time, and packets are separated by a defined much longer time. There was such requirement on this forum already.

This (and perhaps some other UART- and SPI-related requests, e.g. smart framing signal) could be better and cheaper handled by an inter-module link to timer. Similar link in the other direction could handle baudrates. This all requires thinking and real-world experience from the designers, and better documentation skills, though.

JW

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

[Amel NASRI]

adding @Markus GIRDLAND​