Improve STM32 timer conflict messages

[sjasonsmith]

Description

The STM32 HAL does build-time timer conflict detection for the 5 non-PWM uses of the timer in Marlin: STEP, TEMP, SERVO, TONE, and SERIAL.

This change updates constexpr mechanisms to improve the debugging process when an error occurs.

The implementation is entirely constexpr. I verified that there is no change to either RAM or Flash usage caused by this change.

I derived this from my prototype that automatically selects timers at compile time. I decided not to pursue that at this time, but it will likely reappear after some consolidation of our variant practices for this platform.
#20514

Benefits

With these changes, Visual Studio code is able to resolve a very readable list of timers in use. Conflicts can then be easily spotted.

Old popup:

New popup, key differences:

• Displays timer numbers instead of base addresses
• Displays the usage of each timer, so it is easy to tell which functions are conflicting
  (The purposes are prefixed with TP_ to avoid name collisions with existing macros/constants)

Configurations

N/A

Related Issues

N/A

[DrumClock]

Hi, @sjasonsmith
I updated and an error occurred during compilation

Compiling .pio\build\BIGTREE_GTR_V1_0\src\src\core\serial.cpp.o
Marlin\src\HAL\STM32\timers.cpp:102:31: error: 'NUM_HARDWARE_TIMERS' was not declared in this scope
  102 | HardwareTimer *timer_instance[NUM_HARDWARE_TIMERS] = { nullptr };
      |                               ^~~~~~~~~~~~~~~~~~~
*** [.pio\build\BIGTREE_GTR_V1_0\src\src\HAL\STM32\timers.cpp.o] Error 1
====================================================================== [FAILED] Took 10.37 seconds =

[sjasonsmith]

@DrumClock I think that means you broke something in a merge somewhere. It is right there in timers.h, and I have built this for nearly every STM32 board in Marlin and our automatics checks build many STM32 boards, including the GTR.

[DrumClock]

Hi @sjasonsmith
I just updated (in the morning it was OK) now I tried a clean installation of bugfix 2.0.x and these files:

Configuration.zip

There are more mistakes than before ... I don't know what happened.

[thisiskeithb]

There are more mistakes than before ... I don't know what happened.

You're recycling old files like Conditionals_LCD.h and defines have changed.

This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:

• MarlinFW.org Marlin Documentation
• RepRap.org Marlin Forum
• Tom's 3D Forums
• Facebook Group "Marlin Firmware"
• Facebook Group "Marlin Firmware for 3D Printers"
• Marlin Configuration on YouTube
• Marlin Discord server. Join link: https://discord.gg/n5NJ59y

[DrumClock]

@DrumClock I think that means you broke something in a merge somewhere. It is right there in timers.h, and I have built this for nearly every STM32 board in Marlin and our automatics checks build many STM32 boards, including the GTR.

Hi @sjasonsmith
I added line 30 as follows: and the compilation was OK

[sjasonsmith]

@DrumClock try including timers.h instead. That is normally indirectly included, I'm not sure why you aren't seeing items included from it.

[DrumClock]

@DrumClock try including timers.h instead. That is normally indirectly included, I'm not sure why you aren't seeing items included from it.

I don't understand .... how should I do it (please printscreen)

[sjasonsmith]

@DrumClock I just looked at your branch, and all its differences from upstream/bugfix-2.0.x. This is what I looked at:
https://github.com/DrumClock/Marlin/tree/GTR-4EX2

You have MANY merge errors. You are missing MANY upstream changes.

You need to start with a clean version of bugfix-2.0.x and re-apply your configuration to it.

Here is a patch file of all your changes from the upstream branch. If you search you will see that your branch deletes NUM_HARDWARE_TIMERS from timers.h!
DrumClock_changes.zip