Allow STM32 pins to specify timers

[xC0000005]

Description

Set timer overrides for the M200 V1 and V2.

Benefits

Prevents people from having to do this manually.

Related Issues

[randellhodges]

Isn't that already set in the boards pin file?

https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/src/pins/stm32f1/pins_MALYAN_M200.h#L47-L48

[xC0000005]

Indeed it is. But, put a #error after the #ifndef and you'll find it's not effective for some reason. The STM32F1 hal has similar overrides. I'm working on code to autoselect timers, as this isn't something people should maintain, but for now making it at least work without changes is better than nothing.

[sjasonsmith]

The timer header is included very early, long before the pins file, so declaring timers in the pins file isn’t used. They should probably be removed from any pins files that have them, since it gives the false impression that it is handled.

@xC0000005, I’m curious to see what you come up with for auto assignment. STM32 timer conflicts are a pain.

[xC0000005]

PLEASE don’t consider this final code, it’s more me proving it out. The whole goal of this is just to say “can we identify timers in use and ones that are free?” and then evolve it into something useful. https://github.com/xC0000005/Marlin/tree/AutoSelectTimers <https://github.com/xC0000005/Marlin/tree/AutoSelectTimers> See the select_timers function.

…

On Apr 29, 2020, at 8:25 PM, Jason Smith ***@***.***> wrote: The timer header is included very early, long before the pins file, so declaring timers in the pins file isn’t used. They should probably be removed from any pins files that have them, since it gives the false impression that it is handled. @xC0000005 <https://github.com/xC0000005>, I’m curious to see what you come up with for auto assignment. STM32 timer conflicts are a pain. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#17805 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVGS4OI5UYRL6X2G4D4H6TRPDVRPANCNFSM4MVDLFXQ>.

[randellhodges]

Interesting, yeah, that #define did give me a false impression. Assuming auto select doesn't work out well, would the better place for this be in one of the variant files, or is putting it in the timers.h the only real option.

Not trying to hijack the PR, just trying to get a good understand of the how and why :)

[sjasonsmith]

@xC0000005 your approach seems promising. A couple things I noticed are that I believe heaters always use software PWM. There can also be some timers used in the frameworks by SoftwareSerial, Servo, and Tone(?).

I’ve noticed that the STM32F1 framework disabled any timers attached to SPI pins. I’m not sure if they actually interfere, or if they are being by overly-cautious.

[xC0000005]

Understanding is a perfectly good goal - “Don’t be like me, spending hours looking at why the code behaves as if your #define isn’t set” is another, equally good goal.

…

On Apr 29, 2020, at 8:38 PM, randellhodges ***@***.***> wrote: Interesting, yeah, that #define did give me a false impression. Assuming auto select doesn't work out well, would the better place for this be in one of the variant files, or is putting it in the timers.h the only real option. Not trying to hijack the PR, just trying to get a good understand of the how and why :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#17805 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVGS4KHBURGZHVMWZVW2OLRPDXDZANCNFSM4MVDLFXQ>.

[xC0000005]

This is by no means perfect, it’s simply a start. When it works for these pins, I can add in support for other pins. On the ST core, any pwm write will use a timer associated (or silently fail). Long term, I’d love to see a PWM class that could do soft PWM for timer-poor platforms.

…

On Apr 29, 2020, at 8:43 PM, Jason Smith ***@***.***> wrote: @xC0000005 <https://github.com/xC0000005> your approach seems promising. A couple things I noticed are that I believe heaters always use software PWM. There can also be some timers used in the frameworks by SoftwareSerial, Servo, and Tone(?). I’ve noticed that the STM32F1 framework disabled any timers attached to SPI pins. I’m not sure if they actually interfere, or if they are being by overly-cautious. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#17805 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVGS4IUETIZA5LL7BW4O5LRPDXVZANCNFSM4MVDLFXQ>.

[thinkyhead]

We have control over the order of defines. As long as a timers.h file includes inc/MarlinConfig.h or pins/pins.h at the top, the pins file will be able override the defines that follow. So we do not have to use the MB macro inside of the HAL.

[sjasonsmith]

We have control over the order of defines. As long as a timers.h file includes inc/MarlinConfig.h or pins/pins.h at the top, the pins file will be able override the defines that follow. So we do not have to use the MB macro inside of the HAL.

I believe you currently end up with circular includes, due to timer.h being needed inside the HAL's main function. I'm not saying it isn't solvable, but there is work to be done to make it happy. If the timer numbers were moved into timer.cpp it would be trivial to override them with values from the pins file.

[thinkyhead]

Ok, I've fixed up the code so pins files can override the timers. Did you want both M200 and M300 to use those pins, or are the overrides in the pins files already correct?

[thinkyhead]

I believe you currently end up with circular includes

Fortunately, with #pragma once or #ifdef barriers, includes behave sensibly and "circular" includes are bypassed in favor of "include whatever can be included at this spot." Each file ends up being included just once. The include order ends up being the same as if you took the full includes hierarchy in its nested order, left-justified it, and stripped out the duplicates.

[GhostlyCrowd]

This merge breaks compiling for TMC 2209's on the STM32F4 platform and I'm assuming anything else that uses SW serial? reverting this commit solves this issue

Marlin\src\HAL\STM32\HAL.cpp: In function 'void HAL_init()': Marlin\src\HAL\STM32\HAL.cpp:86:42: error: 'SWSERIAL_TIMER_IRQ_PRIO' was not declared in this scope SoftwareSerial::setInterruptPriority(SWSERIAL_TIMER_IRQ_PRIO, 0); ^~~~~~~~~~~~~~~~~~~~~~~ Marlin\src\HAL\STM32\HAL.cpp:86:42: note: suggested alternative: 'EXTI_IRQ_PRIO' SoftwareSerial::setInterruptPriority(SWSERIAL_TIMER_IRQ_PRIO, 0); ^~~~~~~~~~~~~~~~~~~~~~~ EXTI_IRQ_PRIO *** [.pio\build\BIGTREE_SKR_PRO\src\src\HAL\STM32\HAL.cpp.o] Error 1