Most recent activity
-
There's another problem in Snow Leopard, it's not only the appleUSBCDC driver, it's that Chrome is never calling the callback passed to chrome.serial.send() and that stalls everythhing in your chrome app. Chrome 49.xxx.112 is the culprit. Grrr.
-
Great! Now I have to learn the sequence of clock source swapping that works to change that, it seems I can't just poke the new multiplier value there, right?
-
Testing, yes, trying to find where the limits of this little cute chip are. Speaking of which... can I overclock it by setting the PLL multiplier to more than 9x?
-
Yesss, that's cut it almost in half, now it's only 139 ns. Are there still wait states for other reasons?
Thanks!
//STM32F103RCT6.pdf -> https://www.st.com/resource/en/reference_manual/cd00171190.pdf //7.3.2 Clock configuration register (RCC_CFGR) //Read RCC_CFGR (see section 7.3.2) var a=peek32(0x40021004).toString(2); while (a.length<32) a="0"+ a; a 00000000000111010010110000001010 00000 000 0 0 0111 0 1 00 101 100 0000 10 10 RESERVED: 00000 MCO: 000 -> no clock (Microcontroller clock output) RESERVED: 0 USBPRE: 0 -> PLL clock is divided by 1.5 (USB prescaler) PLLMUL: 0111 -> clk*9 (PLL multiplication factor) PLLXTPRE: 0 -> HSE clock not divided (HSE divider for PLL entry) PLLSRC: 1 -> Clock from PREDIV1 selected as PLL input clock ADCPRE: 00 -> PCLK2 divided by 2 (ADC prescaler) PPRE2: 101 -> HCLK divided by 4 (APB high-speed prescaler(APB2)) PPRE1: 100 -> HCLK divided by 2 (APB Low-speed prescaler(APB1)) HPRE: 0000 -> SYSCLK not divided (AHB prescaler) SWS: 10 -> PLL used as system clock SW: 10 -> PLL selected as system clock */ //Put 000 into PPRE2 poke32(0x40021004,peek32(0x40021004)&~(7<<11)); -
Sweet :-)
Thanks!
The connector that's a smidge misaligned is the one that carries GND and power iirc?