[Crowdsourcing] Request of CPU frequency for your STM32 board

[X-Ryl669]

What is this ?

I'm starting this issue for collecting all CPU frequency for STM32 board.
In the upcoming deprecation of libmaple (understand: old Arduino port for STM32) in favor of STSTM32 arduino port, there are some change in the framework that prevents to reach very small delays (those lower than ~300ns).
This proves problematic for some specific features of Marlin, like driving Neopixels, small step time, software serial bitbanging and so on.

This is due to the CPU frequency not being known at compile time, but computed at runtime in STSTM32's framework. In the previous framework, the fact that the CPU frequency was known at compile-time allowed to compute delay with a resolution close to a single CPU's cycle. It's not possible with a runtime value.

So, to reach a better resolution, I'd like to build a database of the CPU frequency of all STM32 boards that Marlin is working on.
I've listed all the board below, and if you are using a board where the CPU frequency is not known, please reply to this issue with your board and the CPU frequency. Thanks!

CPU Frequency database

Board	Known CPU frequency
ARMED	168MHz
RUMBA32_V1_0, RUMBA32_V1_1	Unknown please comment
RUMBA32_MKS	Unknown please comment
BLACK_STM32F407VE	Unknown please comment
STEVAL_3DP001V1	Unknown please comment
BTT_SKR_PRO_V1_1	Unknown please comment
BTT_SKR_PRO_V1_2	Unknown please comment
BTT_GTR_V1_0	Unknown please comment
BTT_BTT002_V1_0	Unknown please comment
LERDGE_K	Unknown please comment
LERDGE_S	Unknown please comment
LERDGE_X	Unknown please comment
VAKE403D	Unknown please comment
FYSETC_S6	Unknown please comment
FYSETC_S6_V2_0	Unknown please comment
FLYF407ZG	Unknown please comment
MKS_ROBIN2	Unknown please comment
MKS_ROBIN_PRO_V2	Unknown please comment
MKS_ROBIN_NANO_V3	Unknown please comment
ANET_ET4	Unknown please comment
ANET_ET4P	Unknown please comment
FYSETC_CHEETAH_V20	Unknown please comment
MALYAN_M200_V2	Unknown please comment
MALYAN_M300	Unknown please comment
STM32F103RE	Unknown please comment
MALYAN_M200	Unknown please comment
STM3R_MINI	Unknown please comment
GTM32_PRO_VB	Unknown please comment
GTM32_MINI	Unknown please comment
GTM32_MINI_A30	Unknown please comment
GTM32_REV_B	Unknown please comment
MORPHEUS	Unknown please comment
CHITU3D	Unknown please comment
MKS_ROBIN	Unknown please comment
MKS_ROBIN_MINI	Unknown please comment
MKS_ROBIN_NANO	72MHz
MKS_ROBIN_NANO_V2	72MHz
MKS_ROBIN_LITE	Unknown please comment
MKS_ROBIN_LITE3	Unknown please comment
MKS_ROBIN_PRO	Unknown please comment
MKS_ROBIN_E3	Unknown please comment
MKS_ROBIN_E3_V1_1	Unknown please comment
MKS_ROBIN_E3D	Unknown please comment
MKS_ROBIN_E3D_V1_1	Unknown please comment
MKS_ROBIN_E3P	Unknown please comment
BTT_SKR_MINI_V1_1	Unknown please comment
BTT_SKR_MINI_E3_V1_0	72MHz
BTT_SKR_MINI_E3_V1_2	72MHz
BTT_SKR_MINI_E3_V2_0	72MHz
BTT_SKR_MINI_MZ_V1_0	Unknown please comment
BTT_SKR_E3_DIP	Unknown please comment
BTT_SKR_CR6	72MHz
JGAURORA_A5S_A1	Unknown please comment
FYSETC_AIO_II	Unknown please comment
FYSETC_CHEETAH	Unknown please comment
FYSETC_CHEETAH_V12	Unknown please comment
LONGER3D_LK	Unknown please comment
CCROBOT_MEEB_3DP	Unknown please comment
CHITU3D_V5	Unknown please comment
CHITU3D_V6	Unknown please comment
CREALITY_V4	Unknown please comment
CREALITY_V4210	Unknown please comment
CREALITY_V427	Unknown please comment
CREALITY_V431	Unknown please comment
CREALITY_V452	Unknown please comment
CREALITY_V453	Unknown please comment
TRIGORILLA_PRO	Unknown please comment
FLY_MINI	Unknown please comment
FLSUN_HISPEED	Unknown please comment
BEAST	Unknown please comment
MINGDA_MPX_ARM_MINI	Unknown please comment

[ktand]

ARMED 168MHz Den tors 11 feb. 2021 kl 12:15 skrev X-Ryl669 <notifications@github.com>:

…

What is this ? I'm starting this issue for collecting all CPU frequency for STM32 board. In the upcoming deprecation of libmaple (understand: old Arduino port for STM32) in favor of STSTM32 arduino port, there are some change in the framework that prevents to reach very small delays (those lower than ~300ns). This proves problematic for some specific features of Marlin, like driving Neopixels, small step time, software serial bitbanging and so on. This is due to the CPU frequency not being known at compile time, but computed at runtime in STSTM32's framework. In the previous framework, the fact that the CPU frequency was known at compile-time allowed to compute delay with a resolution close to a single CPU's cycle. It's not possible with a runtime value. So, to reach a better resolution, I'd like to build a database of the CPU frequency of all STM32 boards that Marlin is working on. I've listed all the board below, and if you are using a board where the CPU frequency is not known, please reply to this issue with your board and the CPU frequency. Thanks! CPU Frequency database Board Known CPU frequency ARMED Unknown please comment RUMBA32_V1_0, RUMBA32_V1_1 Unknown please comment RUMBA32_MKS Unknown please comment BLACK_STM32F407VE Unknown please comment STEVAL_3DP001V1 Unknown please comment BTT_SKR_PRO_V1_1 Unknown please comment BTT_SKR_PRO_V1_2 Unknown please comment BTT_GTR_V1_0 Unknown please comment BTT_BTT002_V1_0 Unknown please comment LERDGE_K Unknown please comment LERDGE_S Unknown please comment LERDGE_X Unknown please comment VAKE403D Unknown please comment FYSETC_S6 Unknown please comment FYSETC_S6_V2_0 Unknown please comment FLYF407ZG Unknown please comment MKS_ROBIN2 Unknown please comment MKS_ROBIN_PRO_V2 Unknown please comment MKS_ROBIN_NANO_V3 Unknown please comment ANET_ET4 Unknown please comment ANET_ET4P Unknown please comment FYSETC_CHEETAH_V20 Unknown please comment MALYAN_M200_V2 Unknown please comment MALYAN_M300 Unknown please comment STM32F103RE Unknown please comment MALYAN_M200 Unknown please comment STM3R_MINI Unknown please comment GTM32_PRO_VB Unknown please comment GTM32_MINI Unknown please comment GTM32_MINI_A30 Unknown please comment GTM32_REV_B Unknown please comment MORPHEUS Unknown please comment CHITU3D Unknown please comment MKS_ROBIN Unknown please comment MKS_ROBIN_MINI Unknown please comment MKS_ROBIN_NANO 72MHz MKS_ROBIN_NANO_V2 Unknown please comment MKS_ROBIN_LITE Unknown please comment MKS_ROBIN_LITE3 Unknown please comment MKS_ROBIN_PRO Unknown please comment MKS_ROBIN_E3 Unknown please comment MKS_ROBIN_E3_V1_1 Unknown please comment MKS_ROBIN_E3D Unknown please comment MKS_ROBIN_E3D_V1_1 Unknown please comment MKS_ROBIN_E3P Unknown please comment BTT_SKR_MINI_V1_1 Unknown please comment BTT_SKR_MINI_E3_V1_0 Unknown please comment BTT_SKR_MINI_E3_V1_2 Unknown please comment BTT_SKR_MINI_E3_V2_0 Unknown please comment BTT_SKR_MINI_MZ_V1_0 Unknown please comment BTT_SKR_E3_DIP Unknown please comment BTT_SKR_CR6 Unknown please comment JGAURORA_A5S_A1 Unknown please comment FYSETC_AIO_II Unknown please comment FYSETC_CHEETAH Unknown please comment FYSETC_CHEETAH_V12 Unknown please comment LONGER3D_LK Unknown please comment CCROBOT_MEEB_3DP Unknown please comment CHITU3D_V5 Unknown please comment CHITU3D_V6 Unknown please comment CREALITY_V4 Unknown please comment CREALITY_V4210 Unknown please comment CREALITY_V427 Unknown please comment CREALITY_V431 Unknown please comment CREALITY_V452 Unknown please comment CREALITY_V453 Unknown please comment TRIGORILLA_PRO Unknown please comment FLY_MINI Unknown please comment FLSUN_HISPEED Unknown please comment BEAST Unknown please comment MINGDA_MPX_ARM_MINI Unknown please comment — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21048>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEHQ2JA735YELV3P6M3LRPLS6O363ANCNFSM4XOURBSQ> .

[qwewer0]

If I'm not wrong:
BTT_SKR_MINI_E3_V1_0 - 72MHz
BTT_SKR_MINI_E3_V1_2 - 72MHz
BTT_SKR_MINI_E3_V2_0 - 72MHz

Source:

1. SKR MINI E3 manual.pdf
2. BTT SKR MINI E3 V1.2manual.pdf
3. BTT SKR MINI E3 V2.0 Instruction Manual.pdf

[rhapsodyv]

I think you can get this information from the board file on PIO. Most of them are pretty standard, related to the core.

And, it's seems weird that we need such a big define table manually... 🤔

What is the issue? The DWT didn't work for small delays?

[Sebazzz]

BTT_SKR_CR6 is 72Mhz as well (STM32F103RET6)

[X-Ryl669]

@rhapsodyv Code like this #define DELAY_NS(x) DELAY_CYCLES((x) * ((F_CPU) / 1000000UL) / 1000UL) when converted from DELAY_NS(700) get compiled to 2 division + multiplication since F_CPU is not a compile time constant but #define F_CPU SystemCoreClock and SystemCoreClock is a uint32_t that's adjusted at init time. This only happens for non-libmaple arduino code. libmaple has the right F_CPU define.

This completely break reaching small delays, since the 2 divisions costs a lot of CPU cycles. Thus, in turn, all DELAY_NS(constant) in the code can't be compile-time converted to a number of cycles.

Since the number of platform is small, I think it's possible to undef the F_CPU macro and instead define it back to a compile time constant. But I need a database of such values per platform.

I haven't found the information in Marlin code base, but if you know were to find it, it will save a lot of time. Thanks!

[X-Ryl669]

I've found this. It lists the maximum frequency per-cpu, but since the CPU frequency is hardware dependent (external oscillator, PLL configuration, etc...), it does not help much to ensure the value match the actual boards, does it ?
If it's fixed, I don't understand the logic in STSTM32 to compute the SystemCoreClock (hence F_CPU) at init time (in system/STM32F1xx/system_stm32f1xx.c for example).

[rhapsodyv]

This kind of issue was already opened on stm32duino... stm32duino/Arduino_Core_STM32#612 ...

It's seems the best approach is try our best to make it work using that runtime value.

You can detect if SystemCoreClock is a runtime value or a complete time constant and "discount" the overhead. I don't know if the overhead is greater than the delay, but did you already try it?

[sjasonsmith]

Every board I’ve seen runs at the maximum clock, except the BTT BX board might run a bit slower than maximum on the HX chip it uses.

There seems to be a frequency in each board JSON file already. That is most likely correct for everything.

[X-Ryl669]

@rhapsodyv The issue is with very small delay (see #20982) like for NeoPixel/FastLED. We are talking about a delay of 7 cycles, but anything below 35 cycle will not work, since just computing the number of cycles to wait takes more than the resulting value (measured ~30 cycles for computing the divide + multiply). This means delay under 500ns are not possible.

So unless we can have a compile time constant, it's not possible to reach such small delay.
Thanks for the link, it's exactly in purpose.

[X-Ryl669]

@sjasonsmith Ok, I'll update the first post with that and use that.

[rhapsodyv]

So, we can try get the frequency from board file using our python script and add it as a macro to the build.

[X-Ryl669]

@rhapsodyv Sweeet... Is it possible to do that in platformio.ini ?

[rhapsodyv]

And if we cache the result of ((F_CPU) / 1000000UL) / 1000UL at the boot time, and the just do a multiplication on the delay?

Delay(x) x * our_cpu_ns_global - our_cpu_multiply_cost

I don’t know the cost of a multiplication, but maybe it works. Did already try it?

[X-Ryl669]

@rhapsodyv No, it's not possible to know everytime. Multiplication can be 1 cycle up to 32 cycles depending on the presence of a hardware multiplier (depends on the type of ARM CPU being run, see here for a table). So if we end up having to make a database of board-> CPU feature, it'll be easier to just set the F_CPU define to a compile time value. Also, the cpu_ns_global is a float (not an int). If rounded, it'll be off by a large amount for large delay. Typically on 72MHz CPU, it's 13.888888ns so ~14% off if rounded.