Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rtic-monotonic on stm32 TIM20 or TIM17 #939

Closed
govert-overgaauw-ampel opened this issue May 23, 2024 · 3 comments
Closed

rtic-monotonic on stm32 TIM20 or TIM17 #939

govert-overgaauw-ampel opened this issue May 23, 2024 · 3 comments

Comments

@govert-overgaauw-ampel
Copy link

Hi,

I am currently working on a micro-controller project running RTIC on STM32G4. We are using 21 timer channel outputs for PWM. So I i have not a lot of options for using RTIC monotonic except for TIM17 or TIM20. Systick is not an option I require some small delays, so the tick rate needs to be faster.

I tried implementing TIM20 based on the existing implementations, however TIM20 has seperate IRQs for TIM_UP and TIM_CC. This leads to a race condition that triggers the panic "monotonic must have missed an interrupt!". I am not well versed in all the nuances required to implement the monotonic timers. Is it possible with two hardware IRQs instead of one hardware timer IRQ? The abstraction layers only has a single on_interrupt call so both IRQs trigger the same function and check the flags.

TIM17 is another option, however this timer only has a single capture compare, and the current implementations use two capture compares. One for the half period interrupt, and one is set by rtic-monotonics set_compare, enable/disable calls but I am not sure about the functionality and if this is required?

@great-houk
Copy link

AFAIK this was fixed by #960, so it can be closed I think?

@govert-overgaauw-ampel
Copy link
Author

The issue with my implementation is that there are separate interrupts on the STM32G4 for TIM20 for TIM_UP and TIM_CC. So I was wondering if i can still use this implementation on that timer.

@govert-overgaauw-ampel
Copy link
Author

I worked around this potential issue by using a third capture compare as period interrupt on TIM20. This way I don't have to worry about potential race conditions between the two IRQs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants