Experiences programming with the .NET Micro Framework

Question

A company I consult for is looking, at my urging, to switch to devices powered by the .NET Micro Framework, so that we can bring devices to the market faster. The idea, in theory at least, is that coding in C# rather than C or assembly will be much faster and less bug prone. Like I said, this all theory, as I've never programmed an embedded device.

My questions are as follows:

1. Is the .NET Micro Framework up to the task?
2. What are some of the things the .NET Micro Framework cannot do?
3. What are some of the gotchas?
4. Is there a viable 3rd party marketplace for plugin devices? I didn't see a whole lot on Microsoft's site.
5. Can someone point to a commercial device that has been developed with the MF Framework.

Thanks.

Answer 1

The .Net Micro Framework is very simple to work with compared to many of the other embedded platforms I have worked with. But it does currently have several draw backs such as the lack of real-time support. Also some of the SDK kits have problems due to hardware contention of all the add-on devices using the same busses. If you need tons of devices hanging off your controller I would look at the Windows CE platform instead. The current selection of hardware for the Micro Framework is just very limited.

Great platform and for small projects it would be great. But when you try to get into near-real-time requirements you might start to run into bumps.

Like so much else in this industry it depends. But for the fact your can get a development kit for under $100 dollars it might be worth checking into.

---

I used the Tahoe-II from DeviceSolutions.Net with .Net Micro Framework 2.0/3.0 and C#. Threading was very simple but the framework is currently very limited. I had to create my own HTTP parser and create crude RESTful webservies. There is a Device Web Service model but I wanted pure HTTP. I also had to create my own SNTP and SMTP protocol layers. A new version (4.0) should be release shortly and it may fill in some of these short falls.

Answer 2

Without knowing your application and the current capability of the embedded device it will be hard for me to give a definitive opinion if .NET MF is up to the task. If the embedded device is a low power 8-bit CPU with 2K of RAM and 32K of ROM then the .NET MF would not be suitable for that design.

In a large number of cases the move to .NET MF would involve hardware changes to a chipset favoured by many vendors that typically target ARM7 or ARM9 cores. The main reason for this is to leverage the work already done in porting the HAL and cross-compiling the PAL & TinyCLR to the native code for the processor in question. Then, if you application fits the .NET MF model, you only need to develop managed code.

A comparison of development boards might help you to select a platform for a new design. The advantage of the GHI products is that you can purchase the bare chipsets with the firmware that they have developed to integrate with your hardware design.

Answer to Question 1: Is the .NET Micro Framework up to the task?

Sorry, I cannot answer this about your application without more information.

Answer to Question 2: What are some of the things the .NET Micro Framework cannot do?

The micro-framework is not realtime like so many of the competing products. The scheduler is fairly simple and not optimised for systems that require deterministic timing.
The TinyCLR interprets the IL from the next waiting "thread" for a 20ms. Threads can yield their allotted time slice by calling Thread.Sleep(0). ONLY between each thread time slice will the Runtime Interpreter check flags from the hardware and dispatch events to managed code or waking up threads if they are blocked waiting for hardware. As far as I understand, there is no way for a thread to be unblocked from native code interrupt service routines (ISR) or for a higher priority thread pre-emptively interrupting a lower priority thread.

Answer to Question 3: What are some of the gotchas?

Everything seems to be working, you've understood the how the runtime interperter loop works (the scheduling of threads and reacting to hardware events) and then you forget about GARBAGE COLLECTION!!
Best to minimise the amount of thrashing of memory (review carefully each time you new an object). Instead of creating and destroying commonly used objects, consider holding a pool of objects usually GC'd and recycle them when needed again.

Answer to Question 4: Is there a viable 3rd party marketplace for plugin devices?

The third party involvement is mainly in the development boards and reference designs on the hardware side of things. From a software point of view, this code-share link might be of interest. As a side issue, don't forget that most of the VS2008 development tools also work on .NET MF (e.g. Resharper and VisualSVN)

Sorry, don't have an answer to question 5 as I do not follow this type of thing. The landing page for .NET MF on Microsoft does seem to have a images of commercial devices but I've never followed the links.