For the last few months I have been lucky enough to have the chance to play with both Oberons Mountaineer Prime Firmware 4.3 and also their latest NETMF for STM32 4.3 port and solution for the STM32F429I-DISCOVERY board which includes 8mb of external ram
Both of these ports have been running extremely well and I have used their Prime Firmware as a base for the attached mikroBUS board and also in a commercial industrial controller board that is currently in Beta testing.
It has been a pleasure to work with Oberon over the last few months and I have convinced Cuno to allow me to produce a Gadgeteer carrier board for the STM32F429I-DISCOVERY board and bundle their 4.3 firmware.
As a thank you to Cuno, Beat and the rest of the Oberon team for all their hard work on the STM ports I want to offer the first run of Gadgeteer carrier boards on a donation basis and after my costs the rest will go to Oberon. So the more you donate the more we can keep Cuno and Beat in sweets and pastries to keep up their excellent work.
So if you have any comments about if the carrier board should be just a straight board with Gadgeteer sockets or include some LED indicators, user buttons etc please comment.
If you would like to make a donation and receive a first run board me email me: justin@ ingenuitymicro.com
An open source effort requires a few people in front, and lots of sweets, lets support those guys. Furthermore can someone explain what the QFE is that Oberon is waiting for?
Concerning the LED and buttons, doesn’t discovery board has those?
If I understand correctly, I could buy Discovery board, plug your carrier board and have a full featured Gadgeteer mainboard with a LCD screen without soldering anything?
Great news ! Love your work @ Justin and @ Cuno and the whole @ Oberon team ! My STM32F429 board arrived yesterday so I will be waiting with baited breath for more info here !! Pity we can’t make the 8Mhz/12Mhz crystal upgrade “easy” for those who want more speed (why oh why ST, do you only use an 8Mhz on a demo board like this?)
From what I know, 8MHz will not allow the processor to run at it’s maximum speed - I’m not sure how the PLL multiplier works, but I think this maxxes out the processor speed at or under 168MHz when it can be used up to 180MHz. But Cuno/Justin will have more knowledge of the detail there I expect.
Like the Cerb firmware, the firmware needs to be compiled to match the hardware, so the timers and other timing dependent functions were correct in the firmware) and if this was configured for 8MHz that may reduce it’s usefulness for someone who wanted to leverage this firmware on an own-design device but leverage higher speed crystals. Yep, basically the same problem using the Cerb firmware on the original STM32F407 Discovery board, except the timers may be “off” in the opposite direction
I’m pretty sure you can hit 168 on the 8mHz crystal, but I’m on the road and can’t run the clock calculation tool at the moment to see if you can hit 180.
With everything that’s already on the Discovery board, I don’t know what else the carrier really needs besides Gadgeteer sockets. Perhaps an onboard CC3000 chip option or pads for later placement?
Looks like the clock configuration tool still doesn’t allow 180mHz, so I can’t prove it without doing the math, but I’m very confident that it’s possible with just about any crystal. Even the reference manual hasn’t been updated to reflect that 180mHz is possible.
Either way, the HSE is run through a divider before being input into the PLL to generate all the other clocks, and that divider seems to be generally set to whatever the crystal is, in order to send 1mHz into the PLL.
You could hit 180mHz with a 4mHz crystal… the only thing that changes is the PLL_M divider when you’re changing the HSE frequency.
