http://forums.leaflabs.com/topic.php?id=31 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:16:16 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=31#post-5919 Fri, 05 Aug 2011 20:17:00 +0000 mbolivar 5919@http://forums.leaflabs.com/ <p>That code is very old. rcc.h has been heavily reworked since then, so you'll have to port the old libmaple style of register access, individual register addresses #defined as numbers (e.g. RCC_CR) and manipulated with macros that cast them to pointers (__read(), __write()) to the new style, which is explained here:</p> <p><a href="http://leaflabs.com/docs/libmaple/overview.html" rel="nofollow">http://leaflabs.com/docs/libmaple/overview.html</a></p> <p>Given that I have no idea about the practical consequences of overclocking the board, I'll just say that if you attempt this, good luck, have fun, I hope your Maple doesn't break. </p> http://forums.leaflabs.com/topic.php?id=31#post-5914 Fri, 05 Aug 2011 19:01:42 +0000 house91320 5914@http://forums.leaflabs.com/ <p>can i use this in the maple ide </p> http://forums.leaflabs.com/topic.php?id=31#post-114 Wed, 19 May 2010 22:22:50 +0000 bnewbold 114@http://forums.leaflabs.com/ <p>To preface all of this, overclocking is a HACK not a FEATURE; running your Maple above the design frequency could damage it irreparably and we won't replace your board for free if you break it this way. That being said it's pretty fun...</p> <p>As described (discovered?) by Thomas Jespersen (<a href="http://elec.tkjweb.dk/blog/2010/02/stm32-overclocking/" rel="nofollow">http://elec.tkjweb.dk/blog/2010/02/stm32-overclocking/</a> ), the regular 72MHz system clock on certain stm32 chips can be upped by simply changing the PLL multiplier. I wrote a junky usercode implementation with libmaple; see <a href="http://gist.github.com/407140" rel="nofollow">http://gist.github.com/407140</a>. This demonstrates resetting the clock multiplier on-the-fly by dropping to the internal (HSI) clock while reconfiguring the PLL to multiply the external 8MHz crystal (HSE) by 16x instead of 9x. I confirmed with a scope; an inefficient, high-level GPIO read/write usually takes about 945ns. After calling overclock() this was reduced to 532ns, the ratio of ~1.77 indicating a SYSCLK speed around 128MHz. I'm not sure if the GPIO peripheral bus can keep up with that SYSCLK, but the uC gears are definitely spinning faster.</p> <p>Bumping the clock speed will break a lot of things, some of which could be configured around and some probably not. Notably USB stops working and you'll have to reprogram by resetting and uploading during the DFU wait period. Most of the peripheral clocks could probably be reconfigured to work, but the internal FLASH memory almost certainly will probably not work at these speeds. </p> <p>Right now this overclock() function takes about 50us to switch speeds, but this could optimized.</p> <p>PS: I think there's a #define typo in rcc.h that is taken advantage of here; can you find it? </p>