-
Notifications
You must be signed in to change notification settings - Fork 3
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
SOFT 298: delay_us implemented without soft timer #364
base: master
Are you sure you want to change the base?
Conversation
…to soft_298_delay_us_deadlock
…to soft_298_delay_us_deadlock
…to soft_298_delay_us_deadlock
I could change x86 implementation to be more similar to STM32, if that is desired? |
Now, do I know why
delay is preventing fault from being cleared? |
…critical section (interrupts disabled), jank fix, but delay really shouldn't be used in critical section anyway
…mware_xiv into soft_298_delay_us_deadlock
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No full review yet (I was trying to get it to work on the hardware I have and it's decided not to work) but one question: is there a reason we still need the soft timer solution when not in an interrupt if your other solution works?
Also I'm pretty sure that time.h etc should work on stm32 (unless you got a compile error in which case never mind) - the stm32 standard library we use is called newlib (source downloadable/searchable at that link) and I think all the libraries are implemented. @ShiCheng-Lu |
What on earth? :< We've got quite a few problems here. at least on x86, the time with clock_gettime() is ever so slightly faster than times in soft_timer which uses timers that rely in interrupt. so a lot of delays become just short enough to break most tests that use soft_timer to do some action. although it might be accurate on stm32 as rightnow it is using the same time TIM2 that soft_timer uses. But that build did fail with bts7040 test in ms-drivers. Do not know why. I would probably suggest leaving delay_us implemented with soft timers, and forbid the use of delay_us() in callbacks. Implement another delay function with system clock that is slightly less accurate to the rest of the program if delay is ever needed in a callback. |
No description provided.