Cerberus firmware on STM32F407 144 pin

Do you plan to release a Cerberus firmware for the LQFP 144 package of the STM32F407?

The firmware would be the same. The parts are all compatible (which is why the 64-pin Cerberus’ firmware runs on the 100-pin part on the Discovery board).

Correct, all will be 100% the same on any STM32F4, if any, minor changes.

Not realy true :slight_smile: Reference STM32F407 board use 8MHz oscilator but Cerberus use 12MHz so you must make hardware modification. But will original examples work after modification? I think no.

Joel Kunze is in this thread:
http://www.tinyclr.com/forum/12/6734/#/1/msg65257
Write instructions how to build Netduino Go 4.2 FW on Discovery board without any hardware modifications and this looks better option for me, because Im order it to learn native programming…
I think I will get answer that in this case I need to buy Cerb board but for me as customer it is to buggy device which can be used only for testing new NETMF4.2 and can’t be used in real applications… I think that EMX is still best product which came from GHI and ChipworkX will be if it will not use DIMM socket which can’t be used in automotive and outside applications…

P.S. I only hope that GHI will not stop producing “Premium” devices which use GHI special library… It would be fine some day get EMX module on steroids:
~200MHz
64MB RAM
4xUART
2xCAN
Color TFT Display Controller(1024x768)
DATABASE SUPPORT
USB Host&USB Client
Piracy Protection
In-Field Update(FULL)
Operating range: -40° to +85°

That doesn’t change the peripheral drivers really. It is an update to set the PLL for the 8Mhz or swapping it with 12Mhz.

No, it’s true. The oscillator is a choice by the board designer. Any of the parts can use a wide variety of oscillators. As long as you’re using the same one that the Cerberus is using (12 MHz), the firmware will be compatible.

godefroi: You don’t understand what Im want to say. Many users already own Discovery board(more than Cerb* or Netduino Go boards) and will be happy to test .NETMF on unmodified board. I know that if I replace oscillator to 12MHz I can run Cerberus FW on it, but because FW is in very early state is not worth modify board to try it… Also if Im right see Netduino Go shematic they use 25MHz oscillator so If I replace original 8MHz with 25Mhz I think I can also run Netduino Go FW on it(without rebuilding it for right oscillator).

Gus: Im not hardware guy and also Im never do anything special with microcontroler in native code(Only little modify Discovery board examples…) Can you simply explain me what efect have 8MHz, 12MHz & 25MHz oscillator to MCU if it do not effect peripheral drivers(code changes, speed, stability…)? If do not effect then best will be that all will use 8MHz and users will benefit because can use GHI, Netduino go or some other FW… I don’t understand open source if everyone do different things and normal users without expirience to modify FW do not benefit anything :slight_smile:

P.S. If Im understand you right I only change XTAL value in project to new 12MHz and I can use original examples(without modify code) on modified board(replace 8MHz with 12MHz)?

The processor has several clocks, and a PLL (Phase Locked Loop) that is driven from one of the clocks. Essentially, the external oscillator is multiplied and divided a few times to run the main clock. The main clock should always run at the same speed (168 MHz, in all these boards, that’s the maximum).

When the processor starts up, code is run that sets up the multipliers and dividers to get the main clock running at the desired speed. Once that happens, the peripheral drivers need only know the main clock speed, not how that speed was achieved.

If you’d like more detail on how this happens, grab ST’s clock configuration tool (it’s an Excel spreadsheet) and play around with it.

As to why particular implementers choose specific crystal speeds, I couldn’t say.

No matter what you use, internally there is a PLL that outputs 168mhz for the processor to run. You only need to set few registers to configure the input.

Gus&godefroi: Thanks for answers. I will look more in datasheets and tutorials for native developing when I will have some free time :slight_smile: Now I spend my free time with “learning” and “researching” power of .NETMF :slight_smile: