-
Notifications
You must be signed in to change notification settings - Fork 752
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
Imprecise PLL frequency calculation #3408
Comments
I think there might be 3 possible things here:
|
I'd try using u64 and check if code size increases too much or not. I think it shouldn't, if you use LTO then RCC code usually gets optimized very well because the input is all compile-time-known constants. I think in some cases we might want some error margin in the drivers anyway? even with u64 you can end up in situations where freq is something like 39999999Hz maybe? |
Yes, agree. Maybe I can try to implement it. Although it may cause the code to look slightly uglier. Maybe
Yes, agree |
|
Consider this example for STM32F407:
This first divides input frequency (25MHz) by 15, multipliy it by 192, then divide it by 2. This would result in an actual sysclk of
25000000/15*192/2=160000000
(160MHz), which is a nice-looking frequency.However, the PLL code in f4's rcc first divides the frequency, then multiplies. This would make sysclk =
Hertz(159999936)
, rather than 160MHz, due to rounding issue (because 25 is not divisible by 15).We cannot simply change the code to multiply first and then divide, because
25000000*192=4800000000
, which is out of bound for u32 (Hertz).The impact of this is somewhat huge. If you do something like this:
set_bitrate
will panic, because it considers APB1 to have39999984Hz
, thus cannot have 500000Hz baud rate.The text was updated successfully, but these errors were encountered: