2026-05-20 6:16 AM - last edited on 2026-05-20 7:57 AM by mƎALLEm
Dear STM Engineer,
thank You very much for Your great effort for the new STM32V8.
My comments on the features after looking into stm32v8-presentation.pdf:
- STM32V8 will have a ETH-Gb-MAC with PTP, that is great news for applications in the field of scientific instrumentation.
-- I am missing PTP-Timestamp-capture-peripherals to generate PTP-precise timestamp input-pulse captures on external events. So triggered by one GPIO input-pulse-edges (or better several logic-combined GPIOs, at least two to have one "gating), a timestamp (64 Bit or more?) should be stored, including in its timestamp-word at least two (better four or more) GPIO Input-states: state high/low AND edge falling/rising. We would need as many as possible of these PTP-Timestamp-capture-peripherals as possible, e.x. 16 or more of them per MC. Would You consider to include such PTP-Timestamp-capture-peripherals into STM32V8?
- - I am missing PTP-output-pulse-peripherals to generate PTP-precise output-pulses on per software previously selectable PTP-times. We would need several of these PTP-output-peripherals, e.x. 2..8 of them per MC. Would You consider to include such PTP-output-pulse-peripherals into STM32V8?
- I am considering to design an universal actor-sensor-xox with STM32V8 with
-- 16 slots for adapter-Cards for the hardware-flexibility and
-- Zephyr for the software-flexibility.
For this, it would be highly welcome to have a much more flexible routing of internal hardware-peripheral-IOs to GPIOs of the MC-pins. We would not need all peripherals to be routeable, e.x. SPI, I2C, I3C, UART, Timer-IOs, CAN, SAI, SPDIFRX, MDF, ADF, ADC, DAC would be sufficient. And we do not need all permutations, just the same sequence of IOs to be placed on other groups of pin-sets ("blockwise"). Would You consider to include such IO-pin-routing into STM32V8?
Up to now, we are using FPGAs. Replacing some of them by a (more) capable, flexible MC would save us development effort.
I would be delighted to receive an answer from You.
Thank You, Peter
Solved! Go to Solution.
2026-05-20 7:43 AM
Hello @peterka ,
Thank you for your suggestion.
I'll forward your points internally for study and to consider for next STM32V8 products (if will be available). The current STM32V8 design is already fixed.
Thank you again for your contribution.
2026-05-20 7:43 AM
Hello @peterka ,
Thank you for your suggestion.
I'll forward your points internally for study and to consider for next STM32V8 products (if will be available). The current STM32V8 design is already fixed.
Thank you again for your contribution.
2026-05-20 7:57 AM
@peterka wrote:My comments on the features after looking into stm32v8-presentation.pdf:
You mean this: https://www.st.com/resource/en/product_presentation/stm32v8-presentation.pdf ?
2026-05-21 12:28 AM
Dear mƎALLEm ,
thank You for Your answer.
After finishing the introduction of the currently fixed design STM32V8 family, You might consider to add one additional family member with a 273-pin TFBGA and those features.
Best regards, Peter
2026-05-21 5:37 AM
PTP is something nobody at ST ever took really care of - so it seems to me. Which is confirmed by missing HAL support (except for some really basic functions such as "get timestamp").
The PTP / MAC hardware is working well, but the documentation, support and / or knowledge on the ST side is not that great.
Some additional hardware features would have been nice also for the H7 series.
I tried for weeks to make the hardware offload PTP in a H723 work, even got some support ticket and info from ST, but they did not know / find out more than I did. The result was that it worked well without any LAN traffic, BUT as soon as the traffic in the LAN got up, sync got really bad, so I went back to some heavily modified PTPd version.
We’re moving the ST Community to a new platform to give you a better and more reliable community experience.