You’re right but, the price is something between $3 - $16 per device. This would mean you get the nk.bin image from the supplier and only do registry/file tweaks on it.
If you want to build your own image you’ll have to pay something near $1000 I guess. But if the supplied image is fine, you don’t need that.
In WEC7 they have Silverlight with managed C++. On most CE devices we deliver to our clients, the CE directly loads the program instead of the explorer shell. The CE UI is completly hidden to the user.
this is the reason why .netmf is a worthy port over CE.
Then use linux with Qt and you get hardware accelerated graphics for free!
Remember that NETMF doesn’t know anything about hardware accelerated graphics, good luck porting that 
Funny you should mention that. I looked at Embedded Linux 3 weeks ago.
when i bought my beaglebone board.
All i can say is that embedded linux has a LONG, LONG, LONG way to go in teaching anyone how to get stated. if a person who at least knows C# can start from scratch learning .netmf and become very effective with it in a few hours. No way in hell is anyone going to do that with Linux.
Those learning have no need for a 1Ghz board. I mean, imagine running NETMF on a 1.2Ghz dual core tegra 2. How long will it take before you want to browse the web on it, or do 3D simulations or a video overlay? I think those CPU’s are ment for a total different market here…
I like NETMF a lot, to bad I don’t have enough time to play some more with it. But in NETMF you have to build a lot of things that other operating systems already have included for more then 10yrs. If you really like C# and want to program on a 1Ghz CPU, go for something like CE. Note that MS uses a shared success formula, you don’t need to pay them anything as long as you don’t sell devices.
And what about android? I didn’t know anything about it, but when you follow the tutorial on how to install eclipse and all the required packages, your first app is running in about 2hrs
Wouter,
just playing devils advocate.
True, but with CE you pay for every product, who wants to do that ?
even if little mom and pop shop wants to start selling something that CE cut will hurt.
Linux, the learning curve is to steep and information about how to do things is not that easy to uncover.
These may be around 10+ years, but you give .netmf 2 years and it will be the pro dominant empire for embedded. There are just to many positives in using .netmf compared to any other.
Wow,
I did not realise I was opening such a big can of WORMS! I thought the can I reached for was almost out. Guess I can go do some more fishing now!
Still, I hope GHI does a port. It would be very nice.
Thanks Anyway,
Brian
It would be really nice to see a 1GHz + FEZ! with huge amounts of memory, and a fast graphics interface I could then try my hand porting or using opencv!
Dave.
If you’re talking about this sort of thing, why not just use an SBC and run Linux? You’re WAY WAY out of the microcontroller world, then. You’re deep into Compact Framework and full-fledged framework territory there.
The Hydra is already much more capable than the platforms the Compact Framework was designed to run on (originally).
If I had to pick, I would defiantly go with netmf on a 1ghz board.
Seconded.
NETMF would be great on a 1Ghz board, but really only if the IO were there. Without the low level GPIO/SPI/I2C/CAN, etc that NETMF supports, NETMF won’t really serve much purpose on a board like that.
I don’t get it. The whole point of NETMF is to be an easy-to-use framework for tiny, low-powered, low-memory devices. Once you get into the much more capable devices, there are BETTER frameworks that are MUCH MORE capable (and even easier!) that you can use…
@ godefroi: finally someone who understands the power of linux/qt ce/compact framework 8) I think, starting from 1ghz, these frameworks are more attractive than what netmf will ever accomplish.
Very true, .netmf it was first designed to fit that purpose. However there is nothing to stop it from being placed on more powerful platforms.
I do see your point though. But here is why me and others would like to see it on faster platforms.
Take a handful of people here who have been doing the .netmf for a year or so. They probably have built themselves up a good class library by now that they reuse often. They surly know their way around the tool set and how to put their ideas into code rather well.
They are handed a project that requires a cpu to be say >600 mhz. They are now screwed. There are only a few options at this point.
#1) subcontract the project out to someone who knows Linux, CE or other.
#2) Learn Linux themselves (which will push the project date way to far out)
#3) Learn CE, (which will push the project date way to far out) & cost money per board.
So this is why we want .netmf ported to a faster system. It all about using what you already know.
There is nothing to prevent .netmf from running on faster platforms.
Will some say “you have a 1Ghz board why in the world didn’t you use Linux or CE on that instead ?” A response could be. "Because I know .netmf and this 1Ghz board has a port for it. so instead of taking weeks to complete it with Linux or CE i finished the project over the weekend because coding in .netmf is far faster to get thing done.
At the end of the day all that matters is does the project work and work well. Was it completed with a reasonable amount of time. No one really cares if it was coded in Basic, Assembler, C/C++, VB, Python or any of the other vast languages out there.
I think we are comparing apples and oranges. There is no “managed way” to do SPI, I2C, GPIO, etc. on compact framework. It does have more features from the full framework.
We do have access to SPI and I2C from managed compact framework code, just by DllImport’ing a function from the DLL supplied by the board manufacturer. Other arguments please 
@ Jdal: I hope your client nevers asks you why you can’t play high resolution video or browse webpages on a 1Ghz CPU
I’m kidding, this discussion leads to nothing.
@ Wouter
Not so fast trigger! 
Exactly my point. What if there is no dll from manufacturer. If I develop a product I have to make PInvoke wrapper for every manufacturer’s dll, again if it exists. With MF I’ll just use built in support and don’t have to worry about different hardware it might run on.