Hi guys,
As a first approach, I want to compile the firmware made by GHI, by myself. I mean, build the source code of the firmware for Cerberus generating Config.hex and Firmware.hex.
In the wiki page is the link to http://www.tinyclr.com/forum/topic?id=4691
I already read this post but I can’t understand if is possible to compile firmware or not.
If someone could compile the Cerberus firmware and download it to the stm32, please write a simple tutorial for me and the community.
Thanks.
You are probably using GCC so you should take a look here http://www.tinyclr.com/forum/topic?id=10015
Hi GUS,
I’m sorry. I forgot to say that all of my projects, until now, are based on PK 4.2 QFE2. If there is a chance, I prefer to finish this project on 4.2.
We are very happy to work with GHI components, so, in the way of follow your releases, my next project will be programmed on VB2012 with PK 4.3.
What compiler are you going to use? free GCC or $$$$ ARM tools?
First, Sourcery G++ (Beginners guide)
then, Yagarto (http://wiki.tinyclr.com/index.php?title=FEZ_Hydra_-_Custom_Firmware_Build)
finally, one called “gcc-arm-none-eabi-4_6-2012q4-20121016”
All the compilers returns errors.
Just follow the instructions in the codeshare that mentioned in Gus’s link:
Thanks for your help!
Now I have to go. Last try and…
So close, just 9 errors. That is the closest I ever was. However it is still failing.
Monday morning I will try to follow your instructions step by step again.
If we don´t meet, marry Christmas for you both.
Merry Christmas!
Back to work.
Following instructions, I reinstall PK 4.2 QFE2. Using the compiler “gcc-arm-none-eabi-4_6-2012q4-20121016.exe” as recommended, I got the first print screen, with 233 errors. Massive fail!!! So, I downloaded the folder of NicolasG called Version 2 and overwrote the location of PK4.2. Compiling again, I got just 6 errors (print screen 2), but still failing.
No firmware was generated.
@ crespi - I have not done this myself but I believe the code from @ Nicolas_G is for PK 4.3, so there might be more that needs to be done to make PK 4.2 work.
I know, I am just covering all the possibilities.
At this moment I am a little bit confused because it looks like nothing works for me but, the firmware for cerberus exists and it was compiled in some way.
The Cerberus port is compiled using commercial compilers either MDK or RVDS, the 4.2 port does not have the build environment configuration for GCC. I assume this is the work the @ Nicholas_G has done for the 4.3 version.
I haven’t looked at 4.3 yet, but the 4.2 GCC scatterfile for the STM32F4 port was just plain wrong, last time I looked at it. But that doesn’t really matter, since you won’t be able to compile the port with GCC anyway; the 4.2 PK doesn’t have support for recent-enough GCC versions for the Cortex M4 processor. You cannot build FEZ Cerberus (STM32F4) using the 4.2 PK using GCC. You need MDK to build the Cerberus 4.2 firmware.
I’m not sure why you think you can copy NicholasG’s modified 4.3 port ontop of a 4.2 porting kit and expect it to work – you need to get rid of the 4.2 PK and install the 4.3 PK. Then copy over NicholasG’s codeshare on top of your new 4.3 PK .
Make sure to build it in release mode. I can’t fit Cerberus’s firmware on the device if it’s built in debug mode, so that may be the source of the problems.
I find the PK to be extremely verbose; if you actually read the error messages, you’ll probably be able to figure out what’s wrong. If not, post the errors here and we’ll help you. It’s fun to see your progress, but you posted this topic as a question. We’ll be able to help you much better if you give us more information.
[title]Another thing to think about:[/title]
You never specified – what are you trying to accomplish? Is there a feature that’s missing from NicolasG’s work that you need implemented? His codeshare has ready-to-roll firmware files you can load on your device without having to compile it yourself.
I don’t mean to rain on your parade, but unless you have a really good reason to build the firmware,[em] you’re probably just wasting your time[/em]. Building the firmware from source with GCC will result in bloated, slow code that won’t run as fast as GHI’s firmware, which is compiled using MDK.
In my mind, there are really only three reasons to build the firmware:
[ol]Fix an important/really annoying bug immediately without having to wait around for someone else to do it for you.
Add features that haven’t been implemented yet (like the TFT LCD controller found in the large STM32F4 microcontrollers).
Improving the performance of your application by moving certain modules into native code.[/ol]
Basically, if you don’t have any reason to modify the firmware source code, you definitely don’t have a reason to build it. And #3 is debatable; seems like most people use RLP-Lite to do time-sensitive stuff.
Just my two cents!
An interesting quote from NicolasG (who compiled 4.3 for Cerberus with GCC):
[quote=“NicolasG”]The result is not as large and slow that the rumor said.
In fact, the result is smaller and to some extend faster than the official firmware. It is entirely the result of using the FPU instruction set.
For a simple managed loop, calculation with float is almost two times faster, calculation with double is surprisingly the same.[/quote]
(Emphasis mine)
@ jay - I think you missed an important reason to want to build the firmware, sometimes as a hobbyist the goal might just be to learn and sometimes just for the challenge. I have been actively tinkering with the firmware for this and only this reason.
Jay, you should expand your horizons a little… There are MANY modules in .NET MF that are excluded in the GHI build. HTTPS and Timzezone support immediately come to mind. Also, people may want to store data to the extra/unused STM32 flash. A change to the scatterfile and rebuild of the firmware combined with some code already in codeshare would let you do that. Not to mention, there are plenty of bugs and being able to compile the firmware with a possible fix is huge. Over a year ago, I used a 30-day trial of RVDS to find the bug in .NET MF that prevented UDP Broadcast from working. I submitted the ticket with Microsoft and it got fixed. If I didn’t have a compiler, that bug might still be there. But, when RVDS expired, I could only guess at what was wrong. Also, there is an alternate 1-wire implementation written by CW2 that I really like, which I can now use. Or, I could take the networking improvements in mIP (like local naming) and integrate them into LWIP and make it part of the firmware. Or, I can expose a few methods to control the integrated ethernet in the Mountaineer board to support mIP with a new driver.
There are TONS of reasons to do this and given the increased flash size of the STM32F4, a slightly larger firmware size is no big deal. In fact, if it is a little too big, we can easily remove components that we wouldn’t use anyway… I fully expect to see a variety of firmware versions start popping up with different groupings of features.
Two cents…
@ crespi - I took some time last night and was able to get the 4.2 Cerb firmware building with GCC. I used the ARM GCC Tool Chain. Since I based the work off of NicolasG’s efforts, I am awaiting his approval and I will release this.
Here is the tool chain that I currently use for the Hydra Firmware and now for the Cerb
https://launchpad.net/gcc-arm-embedded/4.6/4.6-2012-q2-update
@ crespi - Have you solved the problem of the assembly?
I could not. Too many errors going on.
I need those;
platform_selector.h file (C: \ MicroFrameworkPK_v4_2 \ Solutions \ FEZCerberus in it) I’m doing the changes.
But it fails to compile.
: (
I saw him. successful and beautiful work.
settings, but ten were as follows;
#define TOTAL_USART_PORT 3
#define TOTAL_GPIO_PORT 4 // PA - PD
who need it;
#define TOTAL_USART_PORT 6
#define TOTAL_GPIO_PORT 5 // PA - PE