.NET Micro Framework on top of another OS


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


 


 


 


Comments (18)

  1. Tom says:

    I could think of a lot of applications for the MF if you were to overcome the limitation of it not being real-time.

    Make MF real-time, and then we could leverage the benefits of .NET, C#/VB, and Visual Studio into the underbelly of the embedded world, the one that is currently dominated by large players peddling expensive suites of 25-year old technology which are absolute productivity killers.

    By making MF real-time, and then marketing it appropriately, you could go from MF being an interesting niche technology to changing the embedded world.

  2. Another approach I see is to provide a "sandboxed" version of the .NET runtime.

    I work mostly on Windows CE and sometimes you may need to add some programming features to a device. Currently you can provide an SDK for native or managed development (using the compact framework), but in this way you may add features to the standard libraries and classes but not remove them. If you allow an application to run on your device (to provide a custom UI, for example), it will be able to access the filesystem, devices, CPU time etc. and also to call almost any OS API using interop.

    If you want to provide only limited programming features (like you have with MIDLets in Java) inside a "sandbox", to allow development of custom UIs or "plugins", the Microframework may be a suitable solution. In this way the developers can use a familiar programming language and environment and the device manufacturer can control what third party applications can or can’t do in a more granular way.

  3. FPGA User says:

    Does porting onto an operating system allow MF to execute on a processor not currently in the list of target architectures including ARM, Xscale, and Blackfin.  I’ve come to learn that the MF porting kit is limited in this regard when targeting a bare metal port (endianess issues, compiler support, … ), however after reading this article I’m curious (confused) if an OS port is more flexible.  For example, would it be possible to host MF on VXWorks executing on a PowerPC 440 processor.  If not, then statements like "This kind of port is fully supported in the Micro Framework" may be misinterpreted though I believe that such support will eventually materialize.  Until then the Porting Kit should probably be referred to as an Extension API.

  4. Colin says:

    I hear you on real-time.  While there are a number of applications that dont need real-time, it will be a problem for many others.  All that I can say at present is that we have some thougths on the subject.  In the mean time, a nubmer of our customers are looking at MF on an RTOS as a solution.  

  5. Colin says:

    Interesting suggestion.  My question back is: do you want to be able to block APIs at the application level that you are using at the lower levels?  

    In the porting kit, the Solutions Wizard allows for pulling some unnecessary funcitonality out of the image.  This is primarily to reduce the footprint but could be used to limit the interfaces available to the application.  

  6. Colin says:

    Re: the extensiblity of the porting kit.  Yes – there are two kinds of porting tasks.  With the porting kit itself, you are resticted to the supported toolchains.   We recognize that this is not enough for everyone and we are working with a nubmer of silicon vendors on extending our reach. There is also a general solution to this in the works.  

  7. Colin says:

    RE – sandboxing

    Someone on the team pointed out that I probably misinterpreted your comment – That your idea was to run MF on CE to support a more controlled access to underlying funcitonality.  That is in deed an interesting idea and something that could be done with today if there is a need.  

  8. Eric says:

    I’m seeing it as an interesting way to run .Net code within linux-based RFID readers, where MONO may not be suitable.

  9. FPGA User says:

    RE – the extensibility of the porting kit

    I am really curious about what will be involved in the "general solution" to get around the toolchain restrictions of the Porting Kit.  I am at an intersection of deciding to integrate an ARM based processor into my current platform or porting MF to an OS that will execute on an embedded PowerPC that already exists in my current platform (latter being preferred).  If you have any info about when the "general solution" will be available and what it involves beyond the existing porting tasks please let me know.  

  10. I understand that you can remove some functions, like you can do in CE using Platform Builder, but my idea of "sandboxing" is to allow some features but limit their usage. For example you can use the filesystem, but you can access only a specific subtree, or you can draw on the display but only inside a limited area, etc.

    Hosting the MF inside an application (or at the OS level) may allow this kind of implementations and the MF could be used as a sort of "super-scripting engine" inside application, allowing them to be customized using .NET instead of traditional scripting languages but still keeping the scripting features limited to prevent stability/security issues.

    Currently you can build the MF in a way that is compatible with CE own binaries? I supposed that using other toolchains would prevent that.

  11. Petr says:

    I am wondering – does anybody know where there exists port of the .NET micro framework for Windows CE?

  12. quinoa says:

    Are there are any updates regarding previous questions pertaining to running Micro Frameworks on top of VxWorks using a PowerPC processor? I would like to understand the suitability of the current MS porting kit to this task, and a rough delineation of the major tasks involved. If there are companies that want to collaborate in this area I would be interested in starting some exploratory dialog. My objective is to leverage the realtime capabilities of VxWorks and our legacy code including TCP/IP, HTTP(s) while adding managed code applications and web services capabilities through Micro Frameworks.

  13. Quinoa,

    If your PowerPC chip supports Little endian mode AND your VxWorks build does as well, you should be able to do that port with the V4.0 porting kit. If not, you will need to wait.

    OK, "need" is a bit strong, you could modify the source to support big-endian systems, but that would be a massive amount of work and the .NET MF team has already said they are working on that so why not let them get it done for you!

    Once Big-endian support is included in the core it should be possible to port to any 32 bit processor.

  14. Auto says:

    Please, can you privide us a step by step guide on how to port the .NET Micro Framework on top of Linux for ARM ? Thanks.

  15. NETMF Team Bloggers says:

    Hi Auto,

       I can't take you through a port step by step in this forum but there is a chapter on porting to an OS in the porting kit documentation.  Look for "Porting onto an Operating System".

  16. Aidan Browne says:

    Hello,

    Is there a list anywhere of OS's that .NET Micro framework has been ported to ?

    Thanks

  17. 大石头 says:

       MF全称Microsoft® .NET Micro Framework,是微软推出的一个微型.Net框架,微型到什么程度呢?它自身就可以是一个操作系统OS,它编译出来的程序,就可以直接跑在硬件上,当然,也可以在别的嵌入式系统(如UCOS)上用它,MCU才不管什么操作系统呢,找到第一条指令就开始执行,到哪算哪。有了它,我们就可以直接用VisualStudio C#写嵌入式程序。不过也有几点不足:性能上据说中等,跑图形界面时需要较大内存(MCU内SRAM比较小,一般64K~512K,可以外扩4M),只能用.Net的很少的一部分类库

       MF的核心原理就是通过特殊的C#编译器把你写的代码编译成为ARM指令集。它的类库里面可能看不到方法实现,因为那不重要了,反正都是为了编译成为ARM调用指令。

       MF也算是一个中间件,跨在C#和硬件之间,所以微软MF团队必须为不同的MCU写不同的MF类库实现,可以看做是Windows上的驱动程序。尽管都是ARM架构,但是ARM也有各种子架构,然后不同公司实现的MCU产品,内部包含的东西也不尽相同,所以得分门别类的实现。这个过程叫做Porting(我们一般说把MF给Port到STM32上去)。

       从v4.0开始,微软就把MF开源了(http://netmf.codeplex.com/)。不过默认并不支持STM32,那么就得自己Port了。那可是一项非常庞大的工程。现在最新版本是MF v4.2,里面带有一个STM32的Porting模板,有兴趣的同学可以逐步尝试。

       因为.Net Micro Framework功能强大,并且能从C#.Net的PC开发快速进入,它几乎适用于所有嵌入式场合。支持.Net Micro Framework的产品成本,可以低到30元,甚至更低。

       经过实际测试发现,.Net Micro Framework固件最小可以达到250k左右,那么在512k的单片机MCU上完全没有问题。比如STM32F103ZET6和VET6就有512k Flash和64k RAM,除了可以烧入.Net Micro Framework固件,还可以写入较复杂的.Net Micro Framework应用程序,而这两种芯片零售价仅20元左右。

    Microsoft® .NET Micro Framework简介

    newlifex.com/showtopic-53.aspx

  18. 老邱 says:

    可以低到30元(RMB不是US)