The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
The alpha version of Netduino Go firmware source code that can be built with GCC-based toolchains is now available in my NetduinoGoFirmware repository on BitBucket. Please keep in mind this is still in early development stage and not recommended for general use. A few important notes:
The GCC-related code is in dev-gcc branch, you can grab the source directly via "zip" link in "get source" menu on the web page,
This is stripped-down version of the .NET MF 4.2 QFE1 + Netduino Go 4.2.0.0 source, there are no other solutions, no OpenSSL, LWIP, RTIP and a few other things,
The primary toolchain is Yagarto 20111119 (GCC 4.6.2), other supported toolchains are Sourcery CodeBench Lite (2011.09-69 compiles, binaries have not been tested on hardware) and devkitARM (r36 links with a few undefined reference errors),
The setenv_gcc.cmd has been enhanced to detect the compiler version automatically and uses proper runtime libraries for Cortex-M4 core,
The build system now supports side-by-side builds, in case multiple GCC toolchains are used the output will be in a specific folder (e.g. BuildOutput\THUMB2\GCC-Yagarto-4.6.2\le..., BuildOutput\THUMB2\GCC-Sourcery-4.6.1\le... etc.),
The Cortex-M4 hardware floating point unit is not enabled yet - it compiles when the VFP options are set, but there is missing code that actually switches the unit on at startup,
To run the firmware on STM32F4 DISCOVERY board only three values has to be changed to match different oscillator frequency (8 MHz vs. 25 MHz on Netduino Go), as described in Joel Kunze's post.
EDIT: I have discovered a bug in the scatterfile that causes incorrect ER_FLASH to be generated, so the DFU update process (using ST DfuSe tools) cannot be used right now, because the ER_FLASH is horribly big. Flashing tinyclr.axf directly works fine.
EDIT 2012-04-17: The bug has been fixed [hopefully].
I will post more detailed information on the repository wiki. And of course, I am looking for help - any contributions are welcome and will be greatly appreciated. The plan is to merge the changes into Secret Labs official repository when it is available; and possibly into .NET MF codebase (but only after they start accepting my patches : )
Hi CW2,
This is awesome!
One of the big things that has been needed for NETMF Cortex boards is the ability to compile with a free GCC compiler.
BTW, when you say "alpha" you mean that the GCC compilation is pre-release, correct? But that it's based on the release 4.2.0.0 firmware for Netduino Go...
Keep up the fantastic work!
Chris
P.S. I really look forward to integrating this into the Netduino source tree once the GCC build hits "release" stage. It will be wonderful to empower everyone with the freedom to compile their own firmware (with a free compiler).
Netduino Go firmware source code that can be built with GCC-based toolchains...
Awesome, can't wait to play! Downloading Yagarto right now!!
This is stripped-down version of the .NET MF 4.2 QFE1 + Netduino Go 4.2.0.0 source, there are no other solutions, no OpenSSL, LWIP, RTIP and a few other things...
So, why is it stripped down, I was hoping that the ST chip would give us plenty of room for extra features... How big is the resulting firmware file from the GCC compiler, when compared to RVDS? Will it not fit in memory without removing these features, or are they removed for other reasons?
So, why is it stripped down, I was hoping that the ST chip would give us plenty of room for extra features... How big is the resulting firmware file from the GCC compiler, when compared to RVDS? Will it not fit in memory without removing these features, or are they removed for other reasons?
I'll let CW2 fill you in on the details, but I believe that this is a temporary thing...to make sure that the core works well before enabling each feature. CW2 (and KodeDaemon as well) have done quite a bit of work to work both Cortex-M3 supports into NETMF+GCC and to enable NETMF's build process to work with the newer versions of GCC.
There's lots of flash and RAM on the STM32F405 used on Netduino Go. One of our main design goals was to enable GCC-compiled firmware with all features included.
Congratulations to everyone involved in it, I really hope you manage to make this port flexible for everyone...
BTW, here goes another gcc toolchain https://launchpad.net/gcc-arm-embedded , which seems to be updated frequently and supported by ARM(couldn't find any references to support their claim...).
So, why is it stripped down, I was hoping that the ST chip would give us plenty of room for extra features... How big is the resulting firmware file from the GCC compiler, when compared to RVDS? Will it not fit in memory without removing these features, or are they removed for other reasons?
The source code is not included to keep the codebase small (*), no features were removed from the NetduinoGo solution. The code generated by GCC fits into the flash using the same layout as for RVCT. Neither networking nor SSL is used in the current Netduino Go implementation, it will be added back eventually (perhaps someone is getting interested in adding and testing the networking support?) You can also copy the code over an existing .NET MF PK installation and you'll have everything in place...
(*) This is one of my bad habits: I don't like having unused code in the repository, and as I mentioned in the first post, this is code for the Netduino Go only.Thousands of source files makes it harder for me to search for things, check the differences and perform integration.
Freaking Awesome News !!!
As soon as payday lands im ordering a GO with the intent of getting SSL going as it would be a killer feature for an upcoming project at work...
The alpha version of Netduino Go firmware source code that can be built with GCC-based toolchains is now available in my NetduinoGoFirmware repository on BitBucket. Please keep in mind this is still in early development stage and not recommended for general use. A few important notes:
As everyone else is expressing, I think this is great.
Thank you and KodeDaemon for all your efforts, especially at getting this to compile with GCC.
I hope to spend some time working with/on this, but at the rate everyone is moving (compared to me) I'll likely be always behind and just get the benefit of your efforts
Can you give some guidance on how to flash a .axf file? I have not had much luck when using google to get answers and the ST-Link Utility does not consider it a valid hex file for me.
Can you give some guidance on how to flash a .axf file?
I use non-GCC toolchain IDE to flash the .axf file, at this moment I work only with the GCC compiler+linker, no IDE nor debugger (GDB) is supported yet. However, it appears that I managed to fix the scatterfile bug yesterday, so the produced binaries in .bin or .hex folders are correct now. I just need to perform some more tests, then I'll update the first post and write down the guides.
I have your firmware compiled with GCC running on a STM32F4 Discovery (before your most recent scatter file change I was only successful with RVDS on SecretLabs firmware).
I hope you don't mind, I have made a pull request for you, and it is possible I will be making some more minor changes with more pull requests.
What are your plans for the future, will the official NetduinoGo firmware be getting your GCC changes, or will your firmware always be hosted on bitbucket (with official changes merged)?
Thanks!
I am a complete newbie to compiling firmware - just used VS10 to write c# programs under .netmf 4.1
How do I compile the gcc version of the Netduinogo for a STM32F4 Discovery board with the 8Mhz crystal as delivered?
I was looking to use the GNU Tools for ARM Embedded Processor 4.6
If someone had a download or link to suitable .hex or .dfu that would be handy as well.
Thanks in advance
Stephen
What are your plans for the future, will the official NetduinoGo firmware be getting your GCC changes, or will your firmware always be hosted on bitbucket (with official changes merged)?
Once it's ready, the goal is to integrate the GCC compiler support into the official Netduino Go firmware source tree.
I was looking to use the GNU Tools for ARM Embedded Processor 4.6
The build system is now being updated to support this toolchain, it should be finished in a few days or so. It will most likely become the primary toolchain, as it has newlib with long long support (unlike Yagarto) and hardware FPU (unlike free Sourcery).
The plan is to merge the changes into Secret Labs official repository when it is available; and possibly into .NET MF codebase (but only after they start accepting my patches : )
Are most of these changes hardware-independent? We hope that via Microsoft, portable changes will come back to our NETMF for STM32 (F4 Edition) over time.
One of our contributors has made experimental changes for GCC to our port, but the resulting code size and speed were very disappointing. Nevertheless, it would be good to be able to use GCC for projects where it does not make sense to pay several thousand dollars for a compiler first.
One of our contributors has made experimental changes for GCC to our port, but the resulting code size and speed were very disappointing.
According to my experiments, the latest GCC toolchains produce firmware which is only about 10% bigger than RVCT output. However, some of them require C runtime (newlib) to be recompiled with different configuration to enable significantly smaller images than the default. I have not performed any speed measurements yet - the assembly code emitted by GCC seems to be less optimal than RVCT in certain cases, so it can add up for worse performance. It does not 'feel' significantly slower, but I'd need some numbers first; and there is still a lot of options left for tweaking the output...
Are most of these changes hardware-independent? We hope that via Microsoft, portable changes will come back to our NETMF for STM32 (F4 Edition) over time.
There is actually very little code changes required to enable GCC build, most of them are in the build system, it should not require much work to integrated them into your codebase, as it is very similar to Netduino Go. Based on my previous experience with the Microsoft team, I am very skeptical here, perhaps Oberon Microsystems and/or Secret Labs will have more luck with getting the changes back into .NET MF.
The build system is now being updated to support this toolchain, it should be finished in a few days or so. It will most likely become the primary toolchain, as it has newlib with long long support (unlike Yagarto) and hardware FPU (unlike free Sourcery).
Thanks.
AS a newbie is there an example anywhere explaining the process. For example what command is needed to make firmware?
