@ ransomhall
See replay 122
http://www.tinyclr.com/forum/15/6141/#/9/msg59637
Or am i missing something?
@ Architect
Cool! Now how did I miss that? If I saw that then I would have place the board into bootloader mode just for fun, as I can’t do anything else with it.
So? Alpha firmware? ;D
You still can put some native code on it. Blink a led or something.
Or you can get the full source codes … hitting submit… 3, 2, 1 … 
Gus to the rescue!
:dance:
Gus/Joe, the Cerb40 developer wiki page lists the AB38T crystal as “compatible” with the Cerb40. I assume that the ECS-3x8 available from SparkFun (http://www.sparkfun.com/products/540) is also compatible? The load capacitance is the same (12.5 pF), and the series resistance is close (30K vs 35K).
Is this correct?
I hope they are compatible… I’ve got a few showing up in a SF order today.
If it turns out that they are, someone ought to update the Cerb40 wiki page with a link to them. SparkFun is an expensive, but easy source for these sorts of parts.
When you try them, please add them to the list on the wiki. They should work fine.
Would it be possible to “Overclock” this chip and still have reasonable stability. Do you think that a programmable oscillator (http://www.sparkfun.com/products/9089) would work with this chip?
“Between GHI, Sparkfun and Ponoko, you can manufacture just about anything. - Kurtnelle”
You could certainly try, but I’d be surprised if it worked very well. If the MCU worked reliably at a higher frequency, then ST would be selling them as higher frequency chips.
Note also that you don’t need a programmable oscillator to “overclock” the chip. Just configure the PLL the way you like through software, and you can get whatever frequency you want to attempt. And lots of crashes, malfunctions, and instability, most likely.
You’d have to change a bunch of things on the Cerberus/Cerb40 board to be able to use that specific programmable oscillator, I believe. It’s not a drop-in replacement for a quartz crystal. There are specific requirements on the input clock source that you can find in the datasheet and reference manual.
Note that by changing the HSE (High Speed External) clock source without “informing” the MCU, all sorts of things would start working incorrectly. For example, the moment it changed (if the MCU didn’t crash and burn immediately), USB would stop working, because the USB frequency MUST NOT change. Your I2C interface would suddenly be at the wrong frequency, and SPI and UART would as well. If you overclock by too much, the MCU would fail to read the flash memory, as the configured flash wait states would be insufficient. If you had (and you’d want to have, if you were doing something like this) a hardware debugger (JTAG/SWD), it might stop working if you change the frequency.
In short, it’s probably an exercise in futility. It certainly would be frustrating.
Additionally, any gain you could hope to get would be extremely tiny compared to the speed increases you’d see by programming in native code. EXTREMELY tiny. Even if you could overclock by 100% (and you couldn’t, not in a million years), that would only be twice as fast. Native code could be a hundred times as fast, or even more, depending on what you’re doing.
Keep in mind I’m not an EE, nor am I an expert. This is information gleaned from working with the STM32 in native code and poring over datasheets and reference manuals.
@ godefroi, Thanks, I understand.
And did I miss something, was the source posted somewhere?
Interestingly enough, here’s someone that overclocked some STM32 hardware (F1 version, not our F4 monster) from 72 MHz to 128 MHz: http://forums.leaflabs.com/topic.php?id=31
Impressive, but he notes problems with a lot of the things I cite. Notably, he says:
Still, I wouldn’t try it.
@ ransomhall, did you just guess through Cpu.Pin numbers until you found one that worked? Do you have some sort of mapping (or even one, so I can make an LED blink)?
Probably just measured the pins after powering Cerb and just hooked up a led.
Architect is a good guesser 
No pin mapping yet.
It seems that Cpu.Pin.GPIO_Pin0 is PA0.
Why are there only 16 pins in the Cpu.Pin enumeration?
You guys just reminded me! We need to add a pin enumerator DLL. Should be very easy.