2020-08-27 02:52 AM
Dera Sir/Madam,
I chose STM32H750VBT6(LQFP-100 package-Revision Y-Max core clock=400MHz) for my project,based on my requirements .
Everything was fine,until I perceived that: this magnificent MCU is not capable of toggling a GPIO pin faster than 30 ns(roughly estimation).I should emphasize that to reach this speed I had to ignore using HAL_GPIO_WritePin&HAL_GPIO_TogglePin and use GPIOx->BSRR directly in my program in a very very simple loop .
If I can decrease this time to 15 ns(or less),I will reach my goal .
I searched on the Internet and found a very useful discussion in this link:
https://community.st.com/s/question/0D50X00009cdgGjSAI/stm32h7xx-fast-gpio-toggle
It seems that the H7 series has a limit to do so ,intrinsically.
Here are my questions:
1-If I use assembly language directly,can I reach this speed (15 ns)?
2-If I use Revision V of this chip(LQFP-100 package),will it solve my problem(Considering internal HW differences with Revision Y,maybe)?
3-Necessary settings were done in my program(Enabling Cell compensation and...),but none of them were useful.Since this chip is still new to me,maybe I don't know about the right settings or the sequence of the right settings. Can anybody help me about this ?
Your consideration is highly appreciated.
Solved! Go to Solution.
2020-12-19 06:21 AM
I went back to testing the STM32H7 after changing the oscilloscope probe.
But to my sadness it really only comes out at 20MHz on the PA0 pin clocked at 480MHz, and at 72MHz clocked out only 3MHz.
It is unfortunate that a cannon (STM32H7) cannot win a bazooka (STM32F4).
I bought the H7 to have better pin frequency performance, but now I saw that it was a terrible purchase, lost money.
2020-12-19 06:33 AM
2020-12-19 07:44 AM
Because it is the most generic form of testing. Many people use software to perform GPIO manipulation, and this low speed will directly impact expected performance. Few people develop software at a low level.
What would be your suggestion for a better way to test the maximum frequency of a GPIO pin (General Purpose Input / Output)?
2020-12-19 07:54 AM
In 2019 I made some comparisons with the Arduino platform:
Mega 2560.... (16Mhz):......1'326'856 us
UNO.......... (16MHz):........861'460 us
Arduino DUE.. (84MHz):........445'766 us
STM32F103C... (72MHz):........153'107 us
ESP8266..... (160MHz):........103'134 us
STM32F407V.. (168MHz):.........34'576 us
ESP32....... (240MHz):.........27'347 us
https://forum.arduino.cc/index.php?topic=615022.0
People commented on how the pins should be accessed directly. But if the STM32H7 hardware was already built with arrays on the GPIO pins then it seems to me that there really will be no high performance. So it seems to me that the STM32F4 made less time to access the GPIO.
After this Arduino core adds this STM32H743VIT6 variant, I'll add the result to that forum, but I already predict that it might not be such an exciting result.
2020-12-19 08:05 AM
2020-12-19 09:14 AM
2020-12-19 12:20 PM
On the F723, bitbanging for SWD can get into the > 20 MHz rate during the transfer. Not just toggling, but doing something usefull. Look at the StlinkV3.
2020-12-19 03:39 PM
https://community.st.com/s/question/0D53W00000RRSs5SAH/internal-ram-serving-like-eprom-emulator
STM32F417 more fast to pin manipulation than STM32H750. Disappointed
2020-12-20 01:17 AM
The M0+ has optionally a special IOPORT für direct access to GPIOs. On the G0xx, toggling up to 32 MHz (at 64 MHz clock) is possible due to this special feature. A really nice combination would be a dual core M4/M0+ or M7/M0+ with this feature. Unfortunately neither WL nor WB include that in their M0+ cores ...
2021-03-30 04:55 AM
There is a dirty secret: memory to memory DMA works with peripheral addresses and no autoincrement as destination. It's fasted way to bit bang something like a SPI master. I would try to use the D2 domain SRAM and double buffer between two SRAM banks. If your protocol is close to SPI (e.g. SWD) have a look at the SPI peripherals maybe you can reuse them. The H7 SPI supports variable data sizes from 4 to 32 Bit and hardware (un)packing.