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!
I do motor control.
My ideal MCU would have the peripherals of STM32F303 (many comparators, amplifiers, ADC, etc.) with the Cortex M7 CPU with a frequency of 200/300 MHz at least. There is the STM32H7 series but it has few analog comparators and amplifier, with many other unnecessary peripherals for motor control (HDMI, etc.).
Many requests written by the other members are among those that I also consider necessary.
I would also add:
- Increase connection flexibility on I/O pins: currently we can select for each pin a single signal that can be "source" or "destination", ie input or output from the pin, this creates limitations. The greater flexibility if the "GPIO alternate function" are used ONLY to select source signals when the pin works as an output, because it is impossible to have more than one source to send to the digital output. The input signals (ie destinations to the various peripherals) should ALWAYS remain active whatever the use of the pin (Input or Output), because this does not create conflicts. Subsequently, in the various peripherals where these signals arrive, it will be possible to select which input to use for a function. In this way I can send the signal present on an input pin to several peripherals at the same time (Timer, SPI, etc.), I could command an output with a PWM and simultaneously verify that it is working properly by means of a timer that picks up its status logical. All this is what some competitors do (for example the Infineon XMC series), as you can see the "alternate" are only signal sources to send to the output transistor, while the logic state of the pin is unique and goes to some peripherals, which can also be used simultaneously. Look at this:
- The "Peripheral interconnect matrix" is too RIGID. The number of connections between the various devices must be increased. It is not permissible that between two timers there is only one connection (TRGO) that unites them. Suppose I have to combine two timers to count over 16 bits and I must also share the start commands and direction (in addition to the counting clock obviously), how can I do?
- We need a block that can connect the peripheral to each other to link the various signals from peripheral. Now I am forced to use external pins and combine them with copper tracks to send signals that can not be sent internally because the connections are missing. For curiosity, take a look at the XBAR peripheral found in the NXP KV5 series MCUs.
Other suggestions have already been written and I do not want to repeat.
Andrea
