I agree with this especially going forward to future versions.
@ kiwi_stu - Thanks 
Man what a blog post. Very nice work. I hope I can put the knowledge to work.
TPSpencer
1 Like
@ terrence - Thanks I hope so as well. But most important: To learn more about the inner workings of NetMF 
@ AWSOMEDEVSIGNER Itās a great work
Iād like to share with you on GHI forum what I already wrote on official netmf CodePlex web site ā¦
Last year when no people was interested in .Net Micro Framework I invested my free time to build source code from platform kit (other than develop using the framework and C#).
I compiled Netduino and Netduino Plus (first generation) for .Net Micro Framework 4.1 and 4.2 using GCC. I was able to add a sample native function in the original firmware and call it from C# managed code.
After the great work of @ AWSOMEDEVSIGNER I got my old work and this morning started from scratch to compile 4.3 RTM (QFE1) source code.
Today I was able to compile iMXS solution using GCC with some little changes on the new BitConverter cpp native class.
After this I switched to try to compile source code of Netduino 2 and Netduino Plus 2 but I have to check some errors due to different architectures (Neduino first generation was based on ARM7 but the second generation is based on Cortex-M3 and M4 with Thumb support).
I think that Microsoft, like Secret Labs, compiled the firmware using legacy ARM toolchain RVDS that today is replaced by MDK Keil toolchain (owned by ARM).
These compilers arenāt free as GCC (about $5000 and more) but they are able to produce better machine code (in speed and space).
Paolo
3 Likes
@ ppatierno - how can we jugde on the compiler if it spitting out a small enough binary. Is there some kind of benchmark on some standard code to measure against.
Iām using VisualGDB, itās integrated in VS and is very small money but do not know if the outcome is acceptable ?
1 Like
Thank you Paolo 
And great too see that huge progress on your side! Looking forward to more informationās like this.
Ilija
@ PiWi - Usually if you take scatter layout that comes with PK for non GCC compiler and try to use that layout with GCC you will get an error that generated code doesnāt fit into allocated sections. Not by a lot if I remember right. But on device with limited resources every free byte counts.
1 Like
@ Architect - what Iām looking for is a kind of benchmark in generated size. Something like I have a source and if I generate the binary with Keil I get the size of letās say 100k and I can then take the same kind of source compile it with my compiler, generate the binaries and see if I am Way out and need to change or am some what not far away from what keil has in size. This is just a sanity check to see if a compiler is worth using or can be put into the bin and another one has to be chosen.
The source mentioned above does not need to be netmf it is just checking the compiler effectiveness against what it generates in size.
@ PiWi - I think there so many variables involved, so the only way to check is to actually compile on different compilers.
Enlightening post thread over there. I disagree 100%, though, because if the code (with all its problems) were hosted and developed on GitHub, then you, CW2, and Paolo could submit your improvements as a PR and get us that much closer to a sane and working build system.
As it stands, NETMF isnāt an open source project, itās a source-shared-sometimes-maybe-with-missing-files project.
3 Likes
@ godefroi - CW2 made his code public now. With all of the changes and improvements he made. Going through his changes as well and helping to document those changes in any way possible. Letās see what we can do next.
1 Like
[quote=āPiWiā]@ Architect - what Iām looking for is a kind of benchmark in generated size. Something like I have a source and if I generate the binary with Keil I get the size of letās say 100k and I can then take the same kind of source compile it with my compiler
[/quote]
Well I have done that a few times. Unfortunately, I cannot provide exact numbers, because I could not find the results, but in general, GCC produces code that is of comparable size to Keil MDK (formerly ARM RVDS) [1], the difference is in single percents [2] based on particular optimization settings - in certain cases, Keil MDK emits slightly better optimized code.
The biggest difference comes from C runtime libraries - unfortunately, most free GCC-based toolchains come with newlib, which is very bloated and not really suitable for embedded development [3]. Keil MDK has its own C runtime libraries, not based on newlib and highly optimized - the size difference is in range of hundred KB, which translates to tens of percents of the reference project size. Although there are a few settings that can be altered to reduce newlib size, it is not possible to make is as small as its Keil MDK counterpart.
In December 2012, GCC Tools for ARM Embedded Processors version 4.7 [4] was released with newlib-nano - written from scratch and code-size optimized newlib replacement. With newlib-nano, GCC built firmware has basically the same size as Keil MDK output, in certain cases it is even a litte bit smaller (depending on the GCC compiler version and optimization settings, occasionally it varies from release to release).
The only hrudle was that newlib-nano 1.0 came without support for 64-bit integers and long floats, which is required by NETMF (otherwise there is wrong output of long.ToString() and double.ToString() and other formatting used internally in native code). This was added in newlib-nano 2.0 (?). So, it has been possible to build working NETMF firmware with GCC since then, although it meant a custom toolchain had to be built first (enable long-long and long-double newlib-nano options in one configuration script and a few hours wait, the process is rather straightforward and well documented).
Hope this helps
[1] Both toolchains had almost the same quality of code generation, but come with different libraries and there are a few minor differences in command line parameters. After ARM acquired Keil, the RVDS compiler was physically merged with Keil MDK into one exectuable, which executes MDK or RVDS part based on an existence of Keil configuration file (basically if(exists(ātools.iniā)) CompileMDK() else CompileRVDS();).
[2] Reference project STM32F4 firmware
[3] There are commercial GCC-based toolchains that often have own C runtime libraries, usually claimed to be optimized for embedded development. I have not tried any.
6 Likes
@ CW2 - Thank you for the explanation !!
It sure helps in understanding the why ā¦
Do you know why it wouldnāt work for VS2013 since you mentioned 2010 or 2012 is required ?
You mean building NETMF PK? Visual Studio 2013 can be used for build, but due to the changes introduced by MSBuild 12.0 and/or issue with one of the Visual Studio 2013 SDK assemblies there has to be something fixed later in the process - unfortunately, I donāt exactly remember what, sorry.
Also, IIRC the native projects are in VS 2010 format and VS 2013 can only open them if 2010 is installed.
3 Likes
Ok, I have checked the CodePlex project history and the issue with Visual Studio 2013 SDK assembly was fixed in the last public release. Iāll have a look at how much work would it be to accommodate the recent changesā¦ (since summer 2014).
3 Likes
@ CW2 - Awesome !!!
@ CW2 - I think the problem are the setenv_vs.cmd scripts. Those have been outdated until now as well. There is only support up to VS2012.
Yes, you are right (but that is easy to fix). Iāve run the build with Visual Studio 2013 Community and there is an issue with assembly reference version mismatch in CorDebug project - this was fixed in the latest release, there are now three separate projects for different VS versions. I have added the source code to my Bitbucket repo, so I can integrate the changesā¦
2 Likes