stm32f0/g0: use systick timer for timer interrupts

[leptun]

Instead of relying on a TIMx channel for generating interrupts for the scheduler, use the SYSTICK timer countdown just like on the other stm32 families. The TIMx is still the timebase source, but only for the tick counter since the DWT counter is not available on the Cortex M0/M0+. As a result of this PR, the TIMx compare channels are free and could be used for other purposes such as very accurately timed events in hardware (no ISR latency) that are tied to the system clock. Related thread: https://klipper.discourse.group/t/stm32g0x0-system-timer-questions/4455?u=leptun

Signed-off-by: Alex Voinea [email protected]

[KevinOConnor]

Thanks. Can you provide some additional background on this change. Does this change enable users to perform a real-world task they couldn't otherwise do? Is there an impact on the benchmarks with this change?

FWIW, at first glance, this change does seem to increase the overall code size and perhaps complexity.

Cheers, -Kevin

[leptun]

Can you provide some additional background on this change

This change is part of some larger changes that I needed for a feature I am working on. I am trying to eliminate the jitter in the step signal by utilizing the hardware more effectively. In this case, I am planning on using the TIM2 for generating the step signals for 4 stepper drivers. Each step signal needs one hardware channel of a timer that is synchronized to the system clock. I chose to use TIM2 since it's a 32bit timer (simpler code) and it also happens to be the timebase source for the system on the stm32f0/g0 (instead of the DWT). The problem with using TIM2 on these microcontrollers is that the scheduler interrupt is also generated using a hardware TIM channel. In order to free up TIM2_CH1 to be used for a stepper, I moved the scheduler ISR to be on the SYSTICK, while still keeping the timebase source on the TIM2_CNT. Here is the jitter that I am talking about that I'm trying to remove:

Does this change enable users to perform a real-world task they couldn't otherwise do?

No, not really. This change alone should leave the stm32f0/g0 pretty much identical in terms of functionality and performance. The only thing this PR provides is the possibility of implementing things using all TIM2 channels on the stm32f0/g0. Another thing this PR does is making the stm32f0/g0 timebase implementation more similar to the other stm32 families by utilizing the SYSTICK. So all the changes in this PR are simply me taking armcm_timer.c and replacing anything DWT related with the TIM2/3 counter instead of using timer_irq.c.

Is there an impact on the benchmarks with this change?

No, I have not done that yet. I think it should be mostly the same, but I'll see what numbers I can come up with when I have some time to test this again.

[konasimakopoulos]

Does this change enable users to perform a real-world task they couldn't otherwise do?

To add to this, I am currently using the EBB CAN platform which happens to connect a MOSFET for a fan to PA0. If I want to use hardware PWM there my only choice is TIM2 which is currently in use.

So yes, this PR would help immensely. Is there any way I can help with the benchmarks?

[github-actions[bot]]

It looks like this GitHub Pull Request has become inactive. If there are any further updates, you can add a comment here or open a new ticket.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.