In an ideal world i agree with your points you have made here, i really do.
However, there is no good reason i can see why .netmf should not be used on a faster platform.
Its just code, if we can make it run faster it just gets better / more responsive.
Isn’t they why we keep producing faster and faster PC’s ?
The OS is still the same, i can run Win7 on a 1Ghz PC or a quad core 3.2GHz.
i know i am beating this to death, but imagine this. I have an EMX board @ 72MHZ. I want to make a VoIP telephone with touch screen display, web cam & web interface to show live information and to do other things. That 72 Mhz is just not going to cut it. However if say when i got this project i could simply go to GHI’s site and then order the FEZ Night Stalker @ 1Ghz. THen all i would need to do is change a few lines of code that deal with specific pins i was using and download the code to it and i am done. This is the beauty of .netmf. What other platform is going to allow such a change so quickly ?
Linux, CE ? I dont think so. Not to mention vender product retirement. IF a company i was buying a board from stooped selling it, typically your screwed. Not so with .netmf. just grab another board with comparable speed and peripherals, change a few lines of code and connectors and you back in business again.
But you have to port NETMF to all your different hardware. You can define your SPI/I2C interface yourself and write a driver for WinCE if the manufacutere didn’t do it for you (which would be lame, if he sold you a board with external SPI/I2C…). Drivers (aka RLP) in WinCE are really simple (Open/Read/Write/Close/Ioctl), you can compare it to the linux everything is a file concept… And what’s more, you can debug your driver.
Porting an operating system to different hardware will cost you more time than rewriting your application for another framework and in another language. (f.e. object C for iXXX, Java for Android, C++/C# on WinCE, Qt on Linux, etc…). Just select the most mature operating system and framework for the selected hardware. Or select other hardware F.e. if you really want to build software for linux, then you need to carefully select all of your hardware components. Otherwise you will loose months or years trying to port that damn graphics or USB host controller driver, and your product might just fail at the end.
I hope you dont take what i am saying as picking on you or beating on you. Not what i was doing but rather just talking points out from one to another.
This is what i was talking about. If we can get more ports to faster boards. then when we have a larger project that demands more speed we just buy that board that already has the port for it.
Here’s the thing though. If you wrote native code for that EMX, then suddenly it’s MASSIVE overkill for your VoIP telephone.
Your 1 GHz NETMF board would be slower than the EMX running native code. The NETMF interpreter hurts you that much. If you’re going to bother with a 1 GHz system, and all the expense, complexity (there aren’t any GHz processors that are QFP that I know of…), and power use, then you wouldn’t want to waste it all on the NETMF interpreter.
Certainly it would be neat to have an OSS port of NETMF to the Raspberry Pi, but it’s not useful to me at all, as a hobbyist. All the purposes I have involve small, inexpensive, low-power (meaning electricity) systems.
I suppose for me the major attraction in .netmf is portability and very minimal code changes from platform to platform and the simplicity of it all.
I am not getting any younger, and i have grown tired of trying to keep up with this compiler, that compiler, this rev that rev. the programming tool sets for all the different chips and their firmware. Remembering all the specific nuances of all the different compilers and tools that i have. Its gotten old for me over all these years.
.nermf seems a good way to eliminate all this headache and just keeping it simple.
This is why i push for the faster boards. If the 72mhz wont cut it, maybe the 400, or 600 will.
Certainly, and I agree. What we need is for NETCF to be open-source so we can build a community around that.
Or, finally implement the JIT compiler for NETMF (or just native code generation from the get-go), and then we’ll all be happy on the “slower” boards for a long time yet
Note that over in Netduino land, there was some work done involving native code generation directly from C#. Think of it as RLP-in-C# (for some simple things).
I don’t get the arguments against a faster board??
If a faster board is not needed or desired, then why do we love the Hydra, Cerberus, and Cerb40?
Why do we need a Cobra or ChipworkX board?
Why isn’t a Panda II enough for all of our needs?
I’m developing a complicated home automation system. So far it fits on a Cobra and runs fast enough, but as I add more drivers and capability I may have to go to a Hydra or even something faster with more memory. I don’t want to have to start over again with a new operating system and framework just to move up to a bigger faster controller.
The argument isn’t against Hydra, Cerberus, and Cerb40. There’s not even an “argument”. There are two completely different classes of hardware here: the “M” class (I’m including ARM7TDMI here, which is USBizi), and the “A” class (this is the class that powers your smartphone, your iPad, etc.).
The current “M” class hardware comes cheap (as little as $5 in large volumes), consumes very little power, is available with built-in flash and RAM, and comes in “hobbyist-friendly” 64-pin to 176-pin QFP packages.
“A” class hardware can come with peripherals like SATA and PCI-Express, consumes more power, (usually) requires external flash and RAM, and comes in BGA packages with 400, 500, or 600 balls. Forget about hand-soldering these without an expensive reflow machine, and hopefully an X-Ray machine in case you need to check your solder joints.
There is certainly room for both classes of hardware, and I think GHI’s excellent NETMF ports would be great on the “A” class hardware, but “A” class hardware is usually used for vastly different things than “M” class hardware is used for. Even if you need “A” class hardware for a home automation controller, you wouldn’t use that GHz/16MB/16MB hardware for each sensor node.
I agreee with everything you said, except that those things don’t concern me as a hobbyist.
If I were developing a commercial application, the cost of the hardware would be very important.
If I were developing my own boards, the cost and ease of use of the hardware would be very important.
As a hobbyist, I am primarily concerned with software development, the difference in cost between a $150 Cobra board and a $300 1GHz board are not important to me. What is important is what capabilities that board has, and what software services it provides to me (e.g., support for SqlLite, support for higher resolution touch screens, ability to manipulate large byte arrays and strings, etc).
Where I need lower cost and lower power is at the sensor nodes, and the GHI lower level products serve me well there.
I’m just saying that there is definitely a need and desire for more powerful boards that run NETMF.
We should write all our Windows code in native too since it’s faster. Throwing quad core processors at NETMF is just silly. I mean run everything in native and it’ll be so much faster.
Hope you got that was laughing and not derisive sarcasm.
More power is pretty much always a good thing. Why throw more power at NETMF? Look at what I do for example. I create software that allows entry to mid-level people jump in and start making things without having to put tons of effort into learning every little in and out or recreating the wheel.
Pyxis, Gadgetos, Game Slate, would all benefit from having more power. And since they’re all open source if a user got to the point where they said, hey let’s go ahead and make this blazingly fast by putting it into native code, they’ve got a great place to start. They can see what needs to be done and then simply need to convert that into native.
In fact, you do, even if you’re writing C#. Under the .NET framework, EVERYTHING is JIT-compiled to native code. That’s why it’s competitive speed-wise.
The .NET Compact Framework (runs on Windows Mobile) also does JIT.
The .NET Micro Framework does NOT do JIT. NETMF code is orders of magnitude slower than native code.
JIT / AOT - some of these decisions were made byt the founding NETMF team
[quote]The reason is rather simple and surprising - performance! “Huh, what? an interpreter for performance!?” - you might ask. Well, here’s the deal… We actually had a JIT and it turned out that with resource constrained devices that the system was discarding native code and running the JIT EXTREMELY often. This ended up eating up any advantage of running the code natively. With the interpreter there is no JIT, discard, re-JIT overhead. So why not Ahead Of Time (AOT) Compile? Well that comes down to space, IL code is usually significantly smaller than corresponding Native code and we continue to get requests for ever smaller footprints (I’ve seen requests to fit on microcontrollers with as low as 64K of RAM!). Over time processor capabilities and costs may change the scene to where one or both JIT or AOT could become more viable options. Only time will tell.
[/quote]
F.e. if you really want to build software for linux, then you need to carefully select all of your hardware components. Otherwise you will loose months or years trying to port that damn graphics or USB host controller driver, and your product might just fail at the end.
