Hi,
On 18/10/2014 3:45 AM, Tomasz Gregorek wrote:
Hi Chris
- pll_q = ( (long) ( src_clk * pll_n + src_clk * pll_n / 2 ) ) / pll_m
/ 48; + pll_q = ( (long) ( src_clk * pll_n ) ) / pll_m / 48;
Your fix for the PLL_Q calculation is correct.
It supposed to be rounding from <=X.5 to X and from >X.5 to (X+1) but
first I messed up the equation second this clock should not exceed
48MHz so rounding up is not necessarily the best idea.
A check for clock <= 48MHz would be good. Even better if we can check if
USB is used and warn if it is not exactly 48MHz..
-#define FLASH_ACR_LATENCY( val ) BSP_FLD32( val, 0, 3 ) -#define
FLASH_ACR_LATENCY_MSK BSP_MSK32( 0, 3 )
+#define STM32F4_FLASH_ACR_LATENCY(val) BSP_FLD32(val, 0, 2) // Flash
access latency +#define STM32F4_FLASH_ACR_LATENCY_GET(reg)
BSP_FLD32GET(reg, 0, 2) +#define STM32F4_FLASH_ACR_LATENCY_SET(reg,
val) BSP_FLD32SET(reg, val, 0, 2)
I would argue about the STM32F4_FLASH_ACR_LATENCY where you use 3LSB
of ACR (up to 7 wait states) which is correct for the STM32F405xx/07xx
and STM32F415xx/17xx while for the STM32F42xxx and STM32F43xxx there
are 4LSBs in use (up to 15 wait states).
I am not sure how to deal with it. Do we need to distinguish for which
chip we are compiling?
I think it should be safe to use 3 bits as it was. It's a pretty low
risk that someone will accidentally set a flash latency > 7 and it is
pretty likely a write to that bit would be ignored in the hardware anyway.
Ideally yes when we support STM42xxx etc. as well we should add a build
option, but there may be more we need to add, like the operating chip
voltage. Honesty my priority so far is first adding register maps and
example projects to make RTEMS more useful out of the box for standard
boards like STM32F4Discovery.
Thanks and regards
Tomasz
2014-10-18 11:06 GMT+02:00 Chris Nott <chr...@vl.com.au
<mailto:chr...@vl.com.au>>:
Hi,
I sent these header file changes previously, they didn't get
picked up.
I re-merged with the head, cleaned up formatting and fixed a bug
with PLL_Q setting not generating the right auxiliary clock
frequency for USB peripheral - Tomasz this was your change, could
you please review my fix.
Regards,
Chris.
_______________________________________________
devel mailing list
devel@rtems.org <mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
