One unique thing about the .NET Micro Framework is that it is a .NET virtual machine that runs directly on the metal.  We did this so that it could be as small and performant as possible for the current architecture.   However, there are a number of users who have elected not to run MF on the metal but rather to port it onto another operating system or kernel.  This kind of port is fully supported in the Micro Framework.  In fact, there are two porting layers in the architecture.  One is the low level Hardware Abstraction Layer (HAL) layer that supports drivers to the hardware.  For example, this is where you would plug the Micro Framework directly into the Serial Controller on your board.  There is also a higher level of porting interfaces that calls into the HAL.  This is the Platform Abstraction Layer (PAL).  To continue our previous example, if you want to run the Micro Framework on an OS, you write an interface to the serial interfaces in the OS or kernel rather than directly to the Serial Controller.   architecture

Currently, a significant number of the ports that are done are placing the Micro Framework on another operation system.  Why would you do that?  Here are a couple of potential reasons.

  • Support for existing libraries or other OS features:   Perhaps you have some features in your OS that you are dependent on or there is some piece of code that is already integrated with your existing operating environment which you can’t or don’t want to re-implement in managed code.  With the Interop features that were added to MF, you don’t need to rewrite everything in managed code.  You can integrate the native code implementations into your managed code applications.   In fact, I really like our Interop feature implementation.  The native code seamlessly becomes like a part of the existing Namespaces and you call into it like you would any managed code function. 

Another example is real-time support.  As you know, the .NET Micro Framework is not real-time.  Frequently, the real-time requirements of an application are very isolated.  By porting MF onto a small kernel or RTOS, you can run your real-time code in that environment and still have the .NET Micro Framework as a highly productive application environment for the rest.

  • Migration strategy:  You may actually plan to migrate all your code to managed code but do you need to do everything today?  What if you added the Micro Framework as a process on the existing platform and wrote you managed code over time taking advantage of that code already running on the existing OS?  No problem. 

I’ve seen both of these cases.  They both take advantage of the flexibility of the porting experience in MF.  Tell me about your reasons for porting to an OS or conversely for porting MF onto the metal?  That way we can understand what might be missing from the platform that we should have on our roadmap.

 

Colin Miller

Product Unit Manager