Prototype STM32 Auto Timer Selection

[sjasonsmith]

Description

This is experimental. Not yet tested AT ALL.
I am posting it to see how the CI run goes. If that is successful and my own tests go well I will invite others to try it.

STM32 timer conflicts are an ongoing issue. This is worsened as we move STM32F1 boards into the STM32 HAL, since the default timers used were not always the same between the two HALs. There is significant variety in timer selection in the STM32F1 variants, making selection of defaults difficult.

This change seeks to automatically select timers at build time. This considers enabled features, variant.h definitions, and pin-file overrides. Combining these with lists of preferred timers for each MCU family allows unused timers to be selected.

If no available timers can be located in the MCU-specific preferred list, it falls back to a default preferred list. These are ordered loosely based on the likelihood of them being already used.

Benefits

Reduce the occurrence of timer conflicts when features are enabled for new boards. Can likely eliminate existing overrides as well, but this will have to be done with care.

Current drawbacks

Selection is all being done using the timer's base address as the unique identifier. This makes it hard when debugging to know which timer numbers they correlate to. I would like to see if I can rework this to make it easier to see the actual timer number, rather than a base address.

As with previous solutions, this does not factor in PWM outputs, such as fans, RGB LEDs, and lasers.

Configurations

I posted some updated customer configs as a comment in #20387. These produced timer conflicts prior to this change, and now compile.

Related Issues

This has come up multiple times, but this is the issue I am working with directly.
#20387
#20527

[sjasonsmith]

I removed all the timer overrides that were using this HAL. I will need to go back and carefully review them to be sure they are likely to work with automatic selection.

[sjasonsmith]

I will using this comment to evaluate the boards that previously had overrides, along with some other common boards.
If I am changing the timers used I would like to be sure the new selections seem valid.

Board	Old Step/Temp	New Step/Temp (default)	New Step/Temp (w/ Serial, Tone, Servo)	Timers used by fans/PWM	Free of PWM conflicts?	Comments
SKR Pro (F4)	6/14	7/6	6/14	3 4 5 8 9	✔
MKS Robin Nano35	4/2	6/7	6/5	1 2 3	✔
MKS Robin				3 8
Rumba 32 (F4)	10/14	7/6	14/13	1 3 5 8 12	✔
Malyan M300 (F0)	6/7	7/6	N/A	1 15	✔
FYSETC S6	10/14	7/6	14/13	2 3 4 8 12	✔
Lerdge S	4/2	7/6	14/13	2 3 8	✔	Already had conflicts...maybe only uses soft PWM?
Lerdge X	4/2	7/6	14/13	2	✔	Already had conflicts...maybe only uses soft PWM?
Nucleo F767ZI	4/14	7/6	14/13	2 3	✔
RemRam V1	6/2	7/6	14/13	2 3 5	✔

[sjasonsmith]

I am still reworking the mechanism to make the code (and its results) more human-friendly. Hopefully we won't see people hitting the static_assert checking for conflicts any more. If you do hit it I am able to obtain something like this when hovering over the array of in-use timers.

[sjasonsmith]

I have decided to discard this change for now. It was educational for me and I think I have it working well. The problem is that until we can determine the timers being used by fans and other PWM pins, we cannot safely auto-select timers at build time.

I will probably keep some of these changes, to improve the debugging experience when users have timer conflicts, but remove the auto-selection portion of the code. I will then add new timer overrides to pins files where they are needed.

[ftoz1]

can y tell what files or lines need to fix it, I have same problem on lerdge K on older version.