search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.18k stars 19.21k forks source link

[Crowdsourcing] Request of CPU frequency for your STM32 board #21048

Closed X-Ryl669 closed 3 years ago

X-Ryl669 commented 3 years ago

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 commented 3 years ago

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 https://github.com/MarlinFirmware/Marlin/issues/21048, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEHQ2JA735YELV3P6M3LRPLS6O363ANCNFSM4XOURBSQ .

qwewer0 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

BTT_SKR_CR6 is 72Mhz as well (STM32F103RET6)

X-Ryl669 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

This kind of issue was already opened on stm32duino... https://github.com/stm32duino/Arduino_Core_STM32/issues/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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

rhapsodyv commented 3 years ago

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 commented 3 years ago

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

rhapsodyv commented 3 years ago

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 commented 3 years ago

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

rhapsodyv commented 3 years ago

So, try this:

In the file: buildroot/share/PlatformIO/scripts/common-dependencies-post.py

Add this line in the end of the file:

if projenv['BOARD_F_CPU']:
    projenv['CPPDEFINES'].append(('BOARD_F_CPU', projenv['BOARD_F_CPU']))

if BOARD_F_CPU (points to "boards"."f_cpu" on board.json) is filled, it will add a BOARD_F_CPU macro with its value.

X-Ryl669 commented 3 years ago

I had to modify a bit so it's also used for building dependencies (Adafruit NeoPixel), but it works. I'll submit a PR. Thanks!

X-Ryl669 commented 3 years ago

@sjasonsmith I don't see the BTT BX in the list above. What board is it ?

thisiskeithb commented 3 years ago

@sjasonsmith I don't see the BTT BX in the list above. What board is it ?

It’s a custom BigTreeTech board for the Biqu BX with an STM32H743IIT6 processor.

As far as I’m aware, it runs at the full 480 MHz, but I’m also still running an older beta board/firmware.

The BX printer, motherboard, TFT, and BigTreeTech TFT UI have not been ported to current Marlin, but you can find a working copy based on 2.0.6.1 in the BX repo.

And related to this conversation specifically, I noticed some issues with NeoPixels on my beta Biqu BX unit, but I was going to wait until I had final retail hardware & a current version of Marlin for testing.

Some NeoPixel issues include:

sjasonsmith commented 3 years ago

As far as I’m aware, it runs at the full 480 MHz

That may be true. I assumed they were underclocking it since their marketing material said 400 MHz.

thisiskeithb commented 3 years ago

That may be true. I assumed they were underclocking it since their marketing material said 400 MHz.

I just checked mine and the info screen in BTT's UI says 400 MHz. 🤔 Heat isn't an issue since there's a heatsink on the MCU and a fan blowing on it, so I'm not sure why it's not the full 480. 🤷‍♂️

It'll probably be a month or so before my final/retail BX parts arrive and BigTreeTech's engineers planned to submit a PR to Marlin to support the BX's motherboard & LCD/UI after they return from Chinese New Year.

X-Ryl669 commented 3 years ago

@thisiskeithb About the Neopixel issues, did you try with the new delay code? It should be much better for precise timing.

rhapsodyv commented 3 years ago

That may be true. I assumed they were underclocking it since their marketing material said 400 MHz.

I just checked mine and the info screen in BTT's UI says 400 MHz. 🤔 Heat isn't an issue since there's a heatsink on the MCU and a fan blowing on it, so I'm not sure why it's not the full 480. 🤷‍♂️

It'll probably be a month or so before my final/retail BX parts arrive and BigTreeTech's engineers planned to submit a PR to Marlin to support the BX's motherboard & LCD/UI after they return from Chinese New Year.

Well... we just need that the the right value in the board.json for it :-)

thisiskeithb commented 3 years ago

About the Neopixel issues, did you try with the new delay code? It should be much better for precise timing.

I wasn't going to put any more effort into it until I had the final retail hardware since there were some redesigns between early revs & what was shipped to backers.

Related: NeoPixels seem to work great on LPC. We just need to borrow that magic for all these crazy STM variants 😆

Well... we just need that the the right value in the board.json for it :-)

True, but perhaps there's a reason why they're not running it at full speed? Everyone in China is off on holiday, so I can't answer that, but the BX's 1024x600 "BTT UI" runs smoothly at 400 MHz, so no complaints there.

fighter777 commented 3 years ago

BTT_SKR_PRO_V1_1 STM32F407GZ = 168Mhz BTT_SKR_PRO_V1_2 STM32F407GZ = 168Mhz

BTT_GTR_V1_0 STM32F407IG = 168Mhz

BTT_BTT002_V1_0 STM32F407VG = 168Mhz

BTT_SKR_MINI_MZ_V1_0 STM32F207VCT6 = 120Mhz

BTT_SKR_E3_DIP STM32F207VCT6 = 72Mhz

X-Ryl669 commented 3 years ago

So to conclude, I'm going to close the issue since there's a solution by using the board.json file for each board. The only platform where the CPU is not running at its maximum speed is not yet included in Marlin, and when it'll be, its board.json will list the reduced frequency. The only remaining issue will happen when another board using the same CPU STM32H743 but at full frequency will be added, but that'll only require a #ifdef guard to be solved.

github-actions[bot] commented 3 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.