Reasons for choosing NETMF and against , Help for decision and processor selection nedded

Archive
1

Hello;

while it is an interesting feature integrating native , pre compiled C/C++ code by using RPL i am wondering about about the great speed diference between NETMF and RPL integrated code.

So i nedd some commen’t from the more experienced users here:

What was the main reason for developing with NetMF instead of C/C++ on a specific controller base.

Besides the speed discussion:
What are the main advantages of NetMF (may be in combination with RPL) ?
Which functions NetMF has i can`t do (ore in a more more compicated / complex) way
in C/CF++

Example:

The Cerberus µC has ~1MB flash you can use for “bare metal projects”.
Wiht NetMF footprint ~30% are left for one code, ~70% is for NETMF.

So :

  1. There are processors better suited for using NETMF than the cerberus.
  2. Even with “only” 30% Space for own code left it makes sense because …

Thanks for your comments in advance

2

My primary reason is the development environment! 100% managed code, no pointers or memory management bugs. A full symbolic debugger. A fully integrated seamless tool chain. A visual designer. Standardized cabling and pin assignments.

3

The biggest reason to go with NETMF is the development speed. You’ve got the best IDE that exists, intergrated debugger in every chip, multithreading, events, RAM manager, lambda functions and what not. Besides, it’s all in C# (or visual basic), so if you are a C# (or Visual Basic) programmer, you get going immediately. There’s no barrier between MCU and PC programming: you can use the same IDE, same plugins, I even use the same exact code for dlls (dlls still have to be compiled separately).

However, for all that development speed one has to pay by execution speed. NETMF is very slow, compared to bare metal ARM. So, if your program calculates something sophisticated, and does that all the time, you’d better not choose NETMF. If your program needs calculations from time to time only (well, lets say heavy calculations takes <10% of time), then RLP+NETMF is a very convenient choice: relaying intense processing to the RLP is not easy, but once it’s done, it’s used as a simple function and you can forget it.

Flash and RAM is not an issue I think, there’s plenty of chips with external storages around. Besides, some chips already have 2MB of flash, so that really leaves pleeeenty of space. Even 300k that’s left on Cerberus is a huge amount for embedded application, isn’t it?

Oh, and another tricky thing. In NETMF world, every programmer is heavily dependent on code that is written somewhere else and is closed-sourced. So if you encounter a bug, you cannot fix it (sure, digging TCP stack for a bug is not something everybody does, even though the code is available), even theoretically. And sometimes, support for some features are simply dropped (GHI did that for application protection, TCP debugging, PPP in 4.2. Although they are going to reintroduce some features soon, that doesn’t change the fact that it happened). So, be prepared :slight_smile:

4

NETMF’s advantage is in its development environment, meaning, Visual Studio. The IDE, the debugger, the easy code downloads, that’s the big win.

Everything else is pretty much a con, or a wash. For example, Gadgeteer sockets aren’t a feature of NETMF, they’re a feature of someone’s effort to lay out a socket standard, and could just as easily be used by non-NETMF code, such as on the Medusa.

The thing is, the development environment is SUCH a big “pro” that it’s worth overlooking just about every possible “con” in favor of it.

Unless you need the raw hardware speed, that is.

5

Apart from what others already mentioned about the advantages of C#, Visual Studio, fast development and easy debugging, what also made me like using boards like Cerberus under Gadgeteer is the fact that the GHI website is also a big source of information. Most of the modules have tidy examples and there are plenty of codeshare examples to work through. I find very usefull that the source code and circuit diagrams and examples are all available on a single website in a manner that I can quickly reference anything. It saves me from documenting these things myself. I also like standardization that gadgeteer sockets bring to the table. I find that these days I the 10 pin standard as per Gadgeteer modules for even non NETMF related stuff as well. It just makes sense because I do not even need to document it. I already know the interrupt pin is on pin 3 etc…