I have a curious question about the difference between .net and .netmf.
I understand the reasoning for creating the .netmf so as to make a compact edition of .net. yet on the same token it seems to me they might have striped out a bit to much. why at the very least could they have given the option to use some things in the .net framework if we have the memory to use it. Let US determine if the class or method we want to use is to memory hungry or not.
There is a proposed feature for NETMF that would allow the framework to be broken down into much smaller assemblies and thus do what you are suggesting to some point. The problem now is that you have to deploy at a minimum the full assemblies that you reference. So, even if you only need one class out of the assembly the whole thing gets deployed to the device. Additionally, it’s not just a matter of copying stuff from the full framework and pasting it into NETMF. It all has to be basically re-written to NETMF capabilities. If this is a feature you’re especially interested in it, I’d suggest you go to netmf.com and vote for it.
thank you, have you found it to be somewhat limiting ?
the reason i ask is that i was watching the thread on PARSE TO FLOAT, when i looked up the classes on the .net there were many options for doing all kinds of things in that area. when i looked it up for the .netmf it was minimal. i was like wow, why did that strip out so much of that useful stuff out of there.
But now i see your point of [quote]The problem now is that you have to deploy at a minimum the full assemblies that you reference. So, even if you only need one class out of the assembly the whole thing gets deployed to the device[/quote]
Why they took out what they took out is simple: they took out everything that they didn’t need when they were doing the original SPOT projects. They took out everything they needed to in order to allow the framework to fit into tiny little flash memories.
There is actually a .NET framework that fits between the full desktop framework and the .NETMF, which is called the “compact framework”. That framework runs on PDA-class hardware with multi-hundred MHz processors and tens to hundreds of megs of memory.
On the FEZ hardware, flash memory is hardly an issue. There’s plenty for pretty much any set of reference assemblies you’d need to deploy.
Seems to me that when i see .nermf being ported to some very high power ARM9 that have a great amount of ram and flash it wont be long before ARMX comes out that this shrunken down .netmf might not make much sense. Unless of course it whole main gear point is to just taylor to the very low end arm platform of chips.
The good thing is that is is easy to add missing functionality. There are plenty of “extensions” that add stripped down functionality to netmf.
you mush excuse my naivete in all of this. Climbing this vert sttp hill for VS2010, C#, OOP and .netmf has been quite the hill climb. The one burning question that i just cannot seem to figure out is why am i only hearing about it now?
There are plenty of other embedded Ethernet devices out there with and w/o lcd’s. though i will admit most of them are basically a cobble stone arrangement of this this and that C compiler, with this and that TCP/IP stack. along with This and that LCD driver, and not to forget this or that RTOS. .
That to me has been the norm for me my whole career. When i stumbled onto this .netmf its takes away so many headaches from that norm that i just dont get why its not more popular than it is.
ARM9 and friends are the domain of the big brother to the NETMF, the NETCF, or the “.NET Compact Framework”. This is the version that runs on XBOX360, PDAs, Windows Mobile phones and other devices, and things like that.
I know it’s a bit confusing with all the different frameworks and environments, but hey, at least it’s only one programming language 
But the ChipworkX is ARM9 and runs .netmf.
Remember that the porting kit exists so that anyone can take the NETMF and apply it to any chip they’re interested in; so in theory if you wanted to pull out an old Pentium processor and port netmf to it, you could.
What that means is that there’s no “right” answer here. There will likely be an overlap in platforms that run NETMF and NETCF, neither is wrong. The emphasis of NETMF has been to fill the area where you have a low power embedded system with the most restrictive hardware, and to make that easy.
Personally what I see is NETMF is the ideal platform for someone who wants to have a great platform to develop embedded systems with, when you may have come from a desktop .Net programming background, or when you are coming from the 8-bit micro world and want to do more and do it simpler. The speed at which you can figure out how to set up a serial IO connection for instance in comparison to the way you do it on an ATMEGA processor is freakisly fast, there’s no gory detail about the serial registers you need to handle and scratch your head about why you can’t get it to work, it just works quick and simple. That’s a huge boon; I spent days trying to calculate settings when I went back to an old Atmel uC project and wanted to alter the baud rate. In C# on netmf, change the open statement, BAM and you’re done.
ChipworX is an extremely powerful NETMF device. It’s quite capable of running the CF, but while the NETMF runs on “bare-metal”, the CF runs on top of an operating system, typically Windows Mobile or Symbian.
Yea, I think JDAL is a little spoiled 
JDAL, you should start out with a Panda-II with 62K RAM to fully appreciate the sacrifices NETMF makes.
spoiled possibly
I think maybe i just did not make my point clear and /or i just dont understand the enough about .net.
My curiosity about .net and .netmf was that if i am using the Panda II, .netmf was striped down to be able to be used in by processors with limited Flash / Ram. which is fine.
However, if i then jump to the ChipworkX platform with 64MB, then i feel .netmf should have at least given an option to use the main features of the larger .net classes.
Kinda like a “override” feature, so that when we move to uP’s with more flash / ram where using one of the larger classes would not be a big deal to use them.
I understand and agree that would be the Holy Grail of NETMF development. Hopefully someday.
ya me too. I just viewed it like my C compilers. if i want to use printf without formatting for constrained processors then i just pull in the minimal lib for that. On the flip side, when i go to a processor with larger resources, i can then include the full lib and be able to use it. To me that just makes sense. I just assumed that .netmf would have done the same.
I am getting a clearer understanding…